<div dir="ltr"><div>About the FParent:</div><div><br></div><div>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").</div><div><br></div><div>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 <a href="https://castle-engine.io/modern_pascal_introduction.html#_free_notification" target="_blank">https://castle-engine.io/modern_pascal_introduction.html#_free_notification</a> ). It can also be set to nil by something doing "xxx.Parent :=nil".</div><div><br></div><div>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 <a href="https://github.com/castle-engine/castle-engine/wiki/Castle-Game-Engine-for-Unity-developers#what-is-the-difference-between-owner-and-parent-in-cge" target="_blank">https://github.com/castle-engine/castle-engine/wiki/Castle-Game-Engine-for-Unity-developers#what-is-the-difference-between-owner-and-parent-in-cge</a> .</div><div><br></div><div>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 :)<br></div><div><br></div><div>Regards,</div><div>Michalis<br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">śr., 10 lis 2021 o 19:11 Abou Al Montacir <<a href="mailto:abou.almontacir@sfr.fr" target="_blank">abou.almontacir@sfr.fr</a>> napisał(a):<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div><div>Today I've tried to reproduce the issue and it was gone (did not even re-compile)</div><div><br></div><pre>(gdb) r --suite=TTestCastleResource </pre><pre>Starting program: /home/mazen/castle-game-engine-7.0~alpha.1+dfsg/tests/test_castle_game_engine --suite=TTestCastleResource</pre><pre>[Thread debugging using libthread_db enabled]</pre><pre>Using host libthread_db library "/lib/arm-linux-gnueabi/libthread_db.so.1".</pre><pre>No tests selected.</pre><pre>Heap dump by heaptrc unit of /home/mazen/castle-game-engine-7.0~alpha.1+dfsg/tests/test_castle_game_engine</pre><pre>4588 memory blocks allocated : 1543328/1551744</pre><pre>4588 memory blocks freed : 1543328/1551744</pre><pre>0 unfreed memory blocks : 0</pre><pre>True heap size : 229376</pre><pre>True free heap : 229376</pre><pre>[Inferior 1 (process 15436) exited normally]</pre><pre>(gdb) </pre><div><br></div><div>I'm a bit lost, but seems like un-initialized variable somewhere.</div><div><span><pre>-- <br></pre><pre>Cheers,
Abou Al Montacir
</pre></span></div><div><br></div><div>On Mon, 2021-11-08 at 08:39 +0100, Abou Al Montacir wrote:</div><blockquote type="cite" style="margin:0px 0px 0px 0.8ex;border-left:2px solid rgb(114,159,207);padding-left:1ex"><div>Hi Michalis,</div><div><br></div><div><span><pre>On Sun, 2021-11-07 at 01:41 +0100, Michalis Kamburelis wrote:</pre></span></div><div>I see it fails at<br></div><div><br></div><div> TTestGame Time:00.136 N:1 E:1 F:0 I:0<br></div><div> 00.028 TestGameData Error: EAssertionFailed<br></div><div> Exception: Assertion failed (castledebugtransform.pas, line 504)<br></div><div> at $00CB1A14 TDEBUGTRANSFORMBOX__DESTROY, line 454 of<br></div><div>/<<PKGBUILDDIR>>/src/game/castledebugtransform.pas<br></div><div><br></div><div>The referenced assertion is at<br></div><div><a href="https://github.com/castle-engine/castle-engine/blob/631ecfe85ccb4f6b05e8a5da8a93bdb06ed36fea/src/game/castledebugtransform.pas#L504" target="_blank">https://github.com/castle-engine/castle-engine/blob/631ecfe85ccb4f6b05e8a5da8a93bdb06ed36fea/src/game/castledebugtransform.pas#L504</a><br></div><div>.<br></div><div><br></div><div>Unfortunately I have no idea what is the culprit. This same assertion,<br></div><div>I did some debug on a porter box to try to find the root cause.</div><div>and the whole testcase, works on the systems where I test (including<br></div><div>Linux/x86_64, Linux/i386, Linux/Arm -- the latter on Raspberry Pi). It<br></div><div>Sometimes, some bugs appear only on some targets. On others they may be hidden or show in a very weird manner.</div><div>is tempting to suspect that this is FPC bug, although that's weak when<br></div><div>I didn't do any investigation.<br></div><div>You may be right according to the below debugging trial. </div><pre>(gdb) r --suite=TTestCastleResources</pre><pre>Starting program: /home/mazen/castle-game-engine-7.0~alpha.1+dfsg/tests/test_castle_game_engine --suite=TTestCastleResources</pre><pre><br></pre><pre>[Thread debugging using libthread_db enabled]</pre><pre>Using host libthread_db library "/lib/arm-linux-gnueabi/libthread_db.so.1".</pre><pre><br></pre><pre>Breakpoint 1, TCREATURE__CREATE (AOWNER=0xb5912dc0, AMAXLIFE=100, vmt=<incomplete type>, this=0xb4aa0740)</pre><pre> at /home/mazen/castle-game-engine-7.0~alpha.1+dfsg/src/game/castlecreatures.pas:1463</pre><pre>1463 FDebugTransform := TDebugTransform.Create(Self);</pre><pre>(gdb) c</pre><pre>Continuing.</pre><pre><br></pre><pre>Breakpoint 2, TDEBUGTRANSFORMBOX__CREATE (AOWNER=0xb4aa0740, vmt=<incomplete type>, this=0x127869c)</pre><pre> at /home/mazen/castle-game-engine-7.0~alpha.1+dfsg/src/game/castledebugtransform.pas:446</pre><pre>446 begin</pre><pre><b>(gdb) n</b></pre><pre><b>447 inherited Create(AOwner);</b></pre><pre><b>(gdb) p AOwner</b></pre><pre><b>$2 = (^TCOMPONENT) 0xb4aa0740</b></pre><pre>(gdb) n</pre><pre>448 FBoxColor := Gray;</pre><pre><b>(gdb) p Self.FParent</b></pre><pre><b>warning: can't find linker symbol for virtual table for `TDEBUGTRANSFORMBOX' value</b></pre><pre><b>$3 = (^TCASTLETRANSFORM) 0x0</b></pre><pre>(gdb) </pre><div><br></div><div>If my knowledge is good, Tcompopnent.Create should set parent to AOwner, which is not the case here.</div><div><br></div><div>The latest CGE master has this assertion (and this testcase) too, so<br></div><div>it likely still fails. The old CGE 6.4 had a very different<br></div><div>castledebugtransform.pas unit, so it likely avoided the problem by<br></div><div>accident.<br></div><div><br></div><div>My simplest suggestion would be to remove armel from supported<br></div><div>architectures.</div><div>I would have a trial to fix the issue before, maybe this can be fixed easily.</div><div>Or if it shows FPC compiler issue, the definitely this is important, even if CGE is never used by anyone.</div><div> I do not have access to Linux/armel machine, so I do<br></div><div>not regularly test CGE on it. I could get access to it (I recall<br></div><div>Debian gave me temporary access to such machine in the past, for the<br></div><div>purpose of testing CGE).</div><div>This we can arrange <img src="cid:17d0b64b68fb5c0313a1" alt=";-)" width="16px" height="16px"></div><div> But<br></div><div><br></div><div>- Due to lack of regular testing, in a few months I could break something again.<br></div><div><br></div><div>- I do not want this to block CGE from migrating to Debian testing on<br></div><div>more popular architectures.<br></div><div>Valid point.</div><div><br></div><div>I do not think that CGE, combined with armel, is popular enough to<br></div><div>make it matter. (Though I'm eager to hear from some CGE user on armel<br></div><div>to say that I'm wrong :) ).</div><div>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.</div><div>So this maybe worth I spend some time on it.</div><pre><div>_______________________________________________<br></div></pre><pre><div>Pkg-pascal-devel mailing list<br></div></pre><pre><div><a href="mailto:Pkg-pascal-devel@alioth-lists.debian.net" target="_blank">Pkg-pascal-devel@alioth-lists.debian.net</a><br></div></pre><pre><div><a href="https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-pascal-devel" target="_blank">https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-pascal-devel</a><br></div></pre><pre></pre></blockquote></div>
_______________________________________________<br>
Pkg-pascal-devel mailing list<br>
<a href="mailto:Pkg-pascal-devel@alioth-lists.debian.net" target="_blank">Pkg-pascal-devel@alioth-lists.debian.net</a><br>
<a href="https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-pascal-devel" rel="noreferrer" target="_blank">https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-pascal-devel</a><br>
</blockquote></div>