[Pkg-pascal-devel] CGE tests on armel

[Michalis Kamburelis]

> 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
.

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
).

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).

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).

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.

Sorry I cannot tell more,
Regards,
Michalis