[Pkg-pascal-devel] CGE tests on armel

[Abou Al Montacir]

Hi Michalis,

On Thu, 2025-02-13 at 09:56 +0100, Michalis Kamburelis wrote:
> > Since enabling hardening on CGE, some tests did fail on armel architecture.
> > Here is a link for the test suite results.
> > 
> > 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.
> > 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.
> 
> Looking at the test log, the test fails with Access Violation here
> https://ci.debian.net/packages/c/castle-game-engine/testing/armel/57608075/#L2423
> .  Access Violation means SEGFAULT, it can mean many things,
> https://github.com/michaliskambi/modern-pascal-introduction/wiki/How-to-solve-EAccessViolation-error-in-Pascal
> .
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.
> 
> The line it points to is
> "Scene.Load('castle-data:/sprite-sheets/cocos2d_wolf/wolf.plist');", .
> ( Consulting the line 586 from the affected file at 7.0-alpha.3
> release,
> https://github.com/castle-engine/castle-engine/blob/bad2f0ce3ea06f2894955325a710661f52debc2b/tests/code/testcases/testcastlescenecore.pas#L586
> ).
This does not only happen there.

I played a bit with this test today and all three sub tests fail. So there is
definitely an issue with the loader code.

> I'm guessing that there's some issue in Cocos loader,
> X3DLoadInternalCocos2d ( src/scene/load/x3dloadinternalcocos2d.pas )
> but I am not able to guess more. The backtrace from the testsuite
> unfortunately doesn't contain more details. Cocos2d spritesheet is a
> text-based format (so there should not be an endianess difference,
> which is my usual first guess if some file loader fails on an uncommon
> CPU).
That was also my guess.
> 
> I'm afraid I cannot guess more... I would need access to the machine
> with armel to "drill down" and find the exact line of the error.
> Without more investigation, it is tempting to claim it's an FPC
> problem, esp. as this worked before. I had an access to a test machine
> in Debian infrastructure in the past for a similar purpose, maybe it's
> time to renew it. Alternatively, if someone knows a reliable way to
> setup a VM with armel, please throw me a link (I did try in the past
> to setup a VM using QEMU with armel guest, with regular Linux/x86_64
> as a host, but I gave up -- weird things were failing, I could not get
> the VM to boot from what I recall).
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.

> As an immediate solution, you can disable the TTestSceneCore.TestCocos
> test (place sthg like "{$ifdef ARMEL} Exit; {$endif}" at the beginning
> of TTestSceneCore.TestCocos, but I don't know what is the right FPC
> symbol name, I'm just guessing ARMEL here). If everything else, except
> for Cocos, works -> it is at least a confirmation that problem is
> local to X3DLoadInternalCocos2d.
I've already did that. Please check here.

> Sorry I cannot tell more,
If any upstream will help as much as you, packagers life will be easy!

-- 
Cheers,
Abou Al Montacir

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://alioth-lists.debian.net/pipermail/pkg-pascal-devel/attachments/20250213/48926d77/attachment-0001.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 228 bytes
Desc: This is a digitally signed message part
URL: <http://alioth-lists.debian.net/pipermail/pkg-pascal-devel/attachments/20250213/48926d77/attachment-0001.sig>