[Pkg-pascal-devel] Castle Game Engine build failure on armel.

Wed Nov 10 18:11:35 GMT 2021

Today I've tried to reproduce the issue and it was gone (did not even re-
compile)

(gdb) r --suite=TTestCastleResource                             
Starting program: /home/mazen/castle-game-engine-7.0~alpha.1+dfsg/tests/test_castle_game_engine --suite=TTestCastleResource
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/arm-linux-gnueabi/libthread_db.so.1".
No tests selected.
Heap dump by heaptrc unit of /home/mazen/castle-game-engine-7.0~alpha.1+dfsg/tests/test_castle_game_engine
4588 memory blocks allocated : 1543328/1551744
4588 memory blocks freed     : 1543328/1551744
0 unfreed memory blocks : 0
True heap size : 229376
True free heap : 229376
[Inferior 1 (process 15436) exited normally]
(gdb) 

I'm a bit lost, but seems like un-initialized variable somewhere.
-- 
Cheers,
Abou Al Montacir

On Mon, 2021-11-08 at 08:39 +0100, Abou Al Montacir wrote:
> Hi Michalis,
> 
> On Sun, 2021-11-07 at 01:41 +0100, Michalis Kamburelis wrote:
> I see it fails at
> 
>   TTestGame Time:00.136 N:1 E:1 F:0 I:0
>     00.028  TestGameData  Error: EAssertionFailed
>       Exception:   Assertion failed (castledebugtransform.pas, line 504)
>       at   $00CB1A14  TDEBUGTRANSFORMBOX__DESTROY,  line 454 of
> /<<PKGBUILDDIR>>/src/game/castledebugtransform.pas
> 
> The referenced assertion is at
> https://github.com/castle-engine/castle-engine/blob/631ecfe85ccb4f6b05e8a5da8a93bdb06ed36fea/src/game/castledebugtransform.pas#L504
> .
> 
> Unfortunately I have no idea what is the culprit. This same assertion,
> I did some debug on a porter box to try to find the root cause.
> and the whole testcase, works on the systems where I test (including
> Linux/x86_64, Linux/i386, Linux/Arm -- the latter on Raspberry Pi). It
> Sometimes, some bugs appear only on some targets. On others they may be hidden
> or show in a very weird manner.
> is tempting to suspect that this is FPC bug, although that's weak when
> I didn't do any investigation.
> You may be right according to the below debugging trial. 
> (gdb) r --suite=TTestCastleResources
> Starting program: /home/mazen/castle-game-engine-7.0~alpha.1+dfsg/tests/test_castle_game_engine --suite=TTestCastleResources
> 
> [Thread debugging using libthread_db enabled]
> Using host libthread_db library "/lib/arm-linux-gnueabi/libthread_db.so.1".
> 
> Breakpoint 1, TCREATURE__CREATE (AOWNER=0xb5912dc0, AMAXLIFE=100, vmt=<incomplete type>, this=0xb4aa0740)
>     at /home/mazen/castle-game-engine-7.0~alpha.1+dfsg/src/game/castlecreatures.pas:1463
> 1463	  FDebugTransform := TDebugTransform.Create(Self);
> (gdb) c
> Continuing.
> 
> Breakpoint 2, TDEBUGTRANSFORMBOX__CREATE (AOWNER=0xb4aa0740, vmt=<incomplete type>, this=0x127869c)
>     at /home/mazen/castle-game-engine-7.0~alpha.1+dfsg/src/game/castledebugtransform.pas:446
> 446	begin
> (gdb) n
> 447	  inherited Create(AOwner);
> (gdb) p AOwner
> $2 = (^TCOMPONENT) 0xb4aa0740
> (gdb) n
> 448	  FBoxColor := Gray;
> (gdb) p Self.FParent
> warning: can't find linker symbol for virtual table for `TDEBUGTRANSFORMBOX' value
> $3 = (^TCASTLETRANSFORM) 0x0
> (gdb) 
> 
> If my knowledge is good, Tcompopnent.Create should set parent to AOwner, which
> is not the case here.
> 
> The latest CGE master has this assertion (and this testcase) too, so
> it likely still fails. The old CGE 6.4 had a very different
> castledebugtransform.pas unit, so it likely avoided the problem by
> accident.
> 
> My simplest suggestion would be to remove armel from supported
> architectures.
> I would have a trial to fix the issue before, maybe this can be fixed easily.
> Or if it shows FPC compiler issue, the definitely this is important, even if
> CGE is never used by anyone.
>  I do not have access to Linux/armel machine, so I do
> not regularly test CGE on it. I could get access to it (I recall
> Debian gave me temporary access to such machine in the past, for the
> purpose of testing CGE).
> This we can arrange ;-)
>  But
> 
> - Due to lack of regular testing, in a few months I could break something
> again.
> 
> - I do not want this to block CGE from migrating to Debian testing on
> more popular architectures.
> Valid point.
> 
> I do not think that CGE, combined with armel, is popular enough to
> make it matter. (Though I'm eager to hear from some CGE user on armel
> to say that I'm wrong :) ).
> I don't think anyone is going to use CGE on armel, but it is a good way to
> test the compiler itself as I stated above.
> So this maybe worth I spend some time on it.
> _______________________________________________
> Pkg-pascal-devel mailing list
> Pkg-pascal-devel at alioth-lists.debian.net
> https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-pascal-devel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://alioth-lists.debian.net/pipermail/pkg-pascal-devel/attachments/20211110/8c90735b/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: face-wink.png
Type: image/png
Size: 856 bytes
Desc: not available
URL: <http://alioth-lists.debian.net/pipermail/pkg-pascal-devel/attachments/20211110/8c90735b/attachment.png>
-------------- 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/20211110/8c90735b/attachment.sig>