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

Wed Nov 10 20:03:07 GMT 2021

About the FParent:

It should be initialized to nil (zero) when the TDebugTransformBox is
constructed (all fields are initialized then to zero automatically) and
then later it is modified by "TDebugTransformBox.SetParent" (which is the
property setter, so it happens whenever something does "Parent := xxx").

During normal program workflow, it is set to non-nil by outside code doing
"xxx.Parent := ...". It is set to nil by "TDebugTransformBox.Notification",
if the value set as "Parent" is being freed before the TDebugTransformBox
is freed (this is done using the TComponent ownership mechanism, which is
maintained by calling RemoveFreeNotification / FreeNotification in
SetParent, see
https://castle-engine.io/modern_pascal_introduction.html#_free_notification
). It can also be set to nil by something doing "xxx.Parent :=nil".

Note: the value set as "TDebugTransformBox.Parent" is not necessarily the
same value set as "TDebugTransformBox.Owner". "Parent" is the visual
parent, "Owner" is the component that frees the child when owner is freed.
These are independent things -- sometimes they may point to the same thing,
but in general are supposed to be independent. In CGE, we always keep them
independent (i.e. we never assume that "Parent" is equal "Owner"), just
like e.g. LCL keeps them independent too. (Some Pascal libraries force the
"visual parent" (whatever it means in their case) to be equal to "Owner",
but CGE never does force this.) See "What is the difference between Owner
and Parent in CGE?" question on
https://github.com/castle-engine/castle-engine/wiki/Castle-Game-Engine-for-Unity-developers#what-is-the-difference-between-owner-and-parent-in-cge
.

None of this explains the problem we see on Armel -- I'm just providing
various related information, in the hope it will help you debug the problem
:)

Regards,
Michalis

śr., 10 lis 2021 o 19:11 Abou Al Montacir <abou.almontacir at sfr.fr>
napisał(a):

> 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 [image: ;-)]
>  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
>
> _______________________________________________
> 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/d71f3e84/attachment-0001.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/d71f3e84/attachment-0001.png>