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

Fri Nov 12 19:04:11 GMT 2021

Below are more debug messages:

On Fri, 2021-11-12 at 19:58 +0100, Abou Al Montacir wrote:
> Hi Michalis,
> 
> Thank you for the patch. I failed to test it as I need first to fix pasdoc on
> sparc64.
> For this, I've installed a QEMU VM which took me two days, but now I'm able to
> debug it.
> 
> The issue with pasdoc, looks very similar with the issue of CGE with Armel.
> Not sure it is the very same, but I feel there is a regression in FPC 3.2.2
> compared with 3.2.0. This makes me more convinced that we need to keep CGE on
> all these platforms as it give a good test for the compiler, even if not used
> at all.
> 
> Below is the results of my investigation:
> (gdb) r
> Starting program: /home/user/pasdoc-0.16.0/bin/pasdoc --format html --exclude-generator --implementation-comments=join --output=/tmp/pasdoc.log testcases/ok_helpinsight_comments.pas
> 
> Breakpoint 3, EXECUTE (this=0x0) at source/component/PasDoc_Base.pas:608
> 608	  ParseFiles;
> (gdb) s
> PARSEFILES (this=0x0) at source/component/PasDoc_Base.pas:472
> 472	begin
> (gdb) 
> 473	  FUnits.clear;
> (gdb) n
> 475	  DoMessage(1, pmtInformation, 'Starting Source File Parsing ...', []);
> (gdb) n
> Info[1]:    Starting Source File Parsing ...
> 476	  if FSourceFileNames.IsEmpty then Exit;
> (gdb) 
> 478	  InputStream := nil;
> (gdb) 
> PARSEFILES (this=0x0) at source/component/PasDoc_Base.pas:479
> 479	  Count := 0;
> (gdb) 
> PARSEFILES (this=0x0) at source/component/PasDoc_Base.pas:480
> 480	  for i := 0 to FSourceFileNames.Count - 1 do
> (gdb) 
> 482	    p := FSourceFileNames[i];
> (gdb) 
> 483	    try
> (gdb) 
> Info[2]:    Now parsing file testcases/ok_helpinsight_comments.pas...
> 
> Program received signal SIGBUS, Bus error.
> 0x000000000025ae50 in REGEXPR$_$TREGEXPR_$__$$_EMITINT$LONGINT ()
> (gdb) d
> Delete all breakpoints? (y or n) y
> (gdb) b PasDoc_Base.pas:483
> Breakpoint 4 at 0x13ed5c: file source/component/PasDoc_Base.pas, line 483.
> (gdb) r
> The program being debugged has been started already.
> Start it from the beginning? (y or n) y
> Starting program: /home/user/pasdoc-0.16.0/bin/pasdoc --format html --exclude-generator --implementation-comments=join --output=/tmp/pasdoc.log testcases/ok_helpinsight_comments.pas
> Info[1]:    Starting Source File Parsing ...
> 
> Breakpoint 4, PARSEFILES (this=0x0) at source/component/PasDoc_Base.pas:483
> 483	    try
> (gdb) s
> 490	      InputStream := TFileStream.Create(p, fmOpenRead or fmShareDenyWrite);
> (gdb) p p
> $1 = 0x0
> (gdb) p i
> $2 = 0
> (gdb) p FSourceFileNames[i]
> Cannot access memory at address 0xa0
> (gdb) p FSourceFileNames
> Cannot access memory at address 0xa0
> (gdb) p Self
> $3 = 0x0
> (gdb) bt
> #0  PARSEFILES (this=0x0) at source/component/PasDoc_Base.pas:490
> #1  0x000007fefffea5d8 in ?? ()
> Backtrace stopped: previous frame identical to this frame (corrupt stack?)
> (gdb) 
> 
> As you can see the Self (this pointer in GDB stack trace) is nil (0x0).
> This is probably related to a bug in the stack as suggested by GEB warning.
> 
> I think I need to raise a ticket upstream. What do you think?
> Can you help in suggesting a minimal code to reproduce the issue?

(gdb) b PasDoc_Main.pas:681
Breakpoint 5 at 0x13d5d4: file source/console/PasDoc_Main.pas, line 681.
(gdb) r
Starting program: /home/user/pasdoc-0.16.0/bin/pasdoc --format html --exclude-generator --implementation-comments=join --output=/tmp/pasdoc.log testcases/ok_helpinsight_comments.pas

Breakpoint 5, EXECUTE (this=0x0) at source/console/PasDoc_Main.pas:681
681	    PasDoc := TPasDoc.Create(nil);
(gdb) n
682	    try
(gdb) p PasDoc
$4 = 0x0
(gdb) k
Kill the program being debugged? (y or n) y
[Inferior 1 (process 810) killed]
(gdb) r
Starting program: /home/user/pasdoc-0.16.0/bin/pasdoc --format html --exclude-generator --implementation-comments=join --output=/tmp/pasdoc.log testcases/ok_helpinsight_comments.pas

Breakpoint 5, EXECUTE (this=0x0) at source/console/PasDoc_Main.pas:681
681	    PasDoc := TPasDoc.Create(nil);
(gdb) s
CREATE (this=0x0, vmt=0x0, AOWNER=0x0) at source/component/PasDoc_Base.pas:248
248	begin
(gdb) n
249	  inherited;
(gdb) p Self
$5 = 0x0
(gdb) s
0x00000000001f3cd0 in CLASSES$_$TCOMPONENT_$__$$_CREATE$TCOMPONENT$$TCOMPONENT ()
(gdb) n
Single stepping until exit from function CLASSES$_$TCOMPONENT_$__$$_CREATE$TCOMPONENT$$TCOMPONENT,
which has no line number information.
0x000000000011d9c0 in fpc_pushexceptaddr ()
(gdb) 
Single stepping until exit from function fpc_pushexceptaddr,
which has no line number information.
0x00000000001f3d2c in CLASSES$_$TCOMPONENT_$__$$_CREATE$TCOMPONENT$$TCOMPONENT ()
(gdb) 
Single stepping until exit from function CLASSES$_$TCOMPONENT_$__$$_CREATE$TCOMPONENT$$TCOMPONENT,
which has no line number information.
CREATE (this=0x0, vmt=0x0, AOWNER=0x0) at source/component/PasDoc_Gen.pas:2786
2786	  FClassHierarchy := nil;
(gdb) 

It looks like the compiler fails to allocate any instance of any class, but
strange as it managed to cycle itself.
-- 
Cheers,
Abou Al Montacir
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://alioth-lists.debian.net/pipermail/pkg-pascal-devel/attachments/20211112/60450b66/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/20211112/60450b66/attachment-0001.sig>