<html><head></head><body><div>Hi Michalis,</div><div><br></div><div>On Thu, 2025-02-13 at 09:56 +0100, Michalis Kamburelis wrote:</div><blockquote type="cite" style="margin:0 0 0 .8ex; border-left:2px #729fcf solid;padding-left:1ex"><blockquote type="cite" style="margin:0 0 0 .8ex; border-left:2px #729fcf solid;padding-left:1ex"><div>Since enabling hardening on CGE, some tests did fail on armel architecture.<br></div><div>Here is a link for the test suite results.<br></div><div><br></div><div>Can you please help assessing what is going wrong? I don't see an obvious issue, but maybe it is just a compiler bugs as this test used to work well.<br></div><div>Please note that even if FPC RTL and CGE units are compiled with -Cg and -XD, the test itself is not linked with -fpie and so it remains statically linked.<br></div></blockquote><div><br></div><div>Looking at the test log, the test fails with Access Violation here<br></div><div><a href="https://ci.debian.net/packages/c/castle-game-engine/testing/armel/57608075/#L2423">https://ci.debian.net/packages/c/castle-game-engine/testing/armel/57608075/#L2423</a><br></div><div>. Access Violation means SEGFAULT, it can mean many things,<br></div><div><a href="https://github.com/michaliskambi/modern-pascal-introduction/wiki/How-to-solve-EAccessViolation-error-in-Pascal">https://github.com/michaliskambi/modern-pascal-introduction/wiki/How-to-solve-EAccessViolation-error-in-Pascal</a><br></div><div>.<br></div></blockquote><div>Yes, probably a buffer overflow. As this happen after enabling PIE, it can be that this issue was already there but we were lucky that even if we read/write outside the buffer, we were still accessing inside process allocated memory, but this is no more true with PIE.</div><blockquote type="cite" style="margin:0 0 0 .8ex; border-left:2px #729fcf solid;padding-left:1ex"><div><br></div><div>The line it points to is<br></div><div>"Scene.Load('castle-data:/sprite-sheets/cocos2d_wolf/wolf.plist');", .<br></div><div>( Consulting the line 586 from the affected file at 7.0-alpha.3<br></div><div>release, <a href="https://github.com/castle-engine/castle-engine/blob/bad2f0ce3ea06f2894955325a710661f52debc2b/tests/code/testcases/testcastlescenecore.pas#L586">https://github.com/castle-engine/castle-engine/blob/bad2f0ce3ea06f2894955325a710661f52debc2b/tests/code/testcases/testcastlescenecore.pas#L586</a><br></div><div>).</div></blockquote><div>This does not only happen there.</div><div><br></div><div>I played a bit with this test today and all three sub tests fail. So there is definitely an issue with the loader code.</div><div><br></div><blockquote type="cite" style="margin:0 0 0 .8ex; border-left:2px #729fcf solid;padding-left:1ex"><div>I'm guessing that there's some issue in Cocos loader,<br></div><div>X3DLoadInternalCocos2d ( src/scene/load/x3dloadinternalcocos2d.pas )<br></div><div>but I am not able to guess more. The backtrace from the testsuite<br></div><div>unfortunately doesn't contain more details. Cocos2d spritesheet is a<br></div><div>text-based format (so there should not be an endianess difference,<br></div><div>which is my usual first guess if some file loader fails on an uncommon<br></div><div>CPU).<br></div></blockquote><div>That was also my guess.</div><blockquote type="cite" style="margin:0 0 0 .8ex; border-left:2px #729fcf solid;padding-left:1ex"><div><br></div><div>I'm afraid I cannot guess more... I would need access to the machine<br></div><div>with armel to "drill down" and find the exact line of the error.<br></div><div>Without more investigation, it is tempting to claim it's an FPC<br></div><div>problem, esp. as this worked before. I had an access to a test machine<br></div><div>in Debian infrastructure in the past for a similar purpose, maybe it's<br></div><div>time to renew it. Alternatively, if someone knows a reliable way to<br></div><div>setup a VM with armel, please throw me a link (I did try in the past<br></div><div>to setup a VM using QEMU with armel guest, with regular Linux/x86_64<br></div><div>as a host, but I gave up -- weird things were failing, I could not get<br></div><div>the VM to boot from what I recall).<br></div></blockquote><div>I may try to setup an armel VM if needed. It will be a nice thing. I'll see if I can do something for that if I have time.</div><div><br></div><blockquote type="cite" style="margin:0 0 0 .8ex; border-left:2px #729fcf solid;padding-left:1ex"><div>As an immediate solution, you can disable the TTestSceneCore.TestCocos</div><div>test (place sthg like "{$ifdef ARMEL} Exit; {$endif}" at the beginning<br></div><div>of TTestSceneCore.TestCocos, but I don't know what is the right FPC<br></div><div>symbol name, I'm just guessing ARMEL here). If everything else, except<br></div><div>for Cocos, works -> it is at least a confirmation that problem is<br></div><div>local to X3DLoadInternalCocos2d.</div></blockquote><div>I've already did that. Please check <a href="https://salsa.debian.org/pascal-team/castle-game-engine/-/blob/master/debian/patches/Disable-broken-test-on-armel.patch?ref_type=heads">here</a>.</div><div><br></div><blockquote type="cite" style="margin:0 0 0 .8ex; border-left:2px #729fcf solid;padding-left:1ex"><div>Sorry I cannot tell more,</div></blockquote><div>If any upstream will help as much as you, packagers life will be easy!</div><blockquote type="cite" style="margin:0 0 0 .8ex; border-left:2px #729fcf solid;padding-left:1ex"></blockquote><div style="font-size: 14.666667px;"><span><pre>-- <br></pre><pre>Cheers,
Abou Al Montacir
</pre><div><br></div></span></div></body></html>