[fpc-devel] Stack dump with possible segfault

[Johann Glaser]

Hi again!

Am Montag, den 12.05.2014, 23:33 +0200 schrieb Johann Glaser:
> Hi!
> 
> I'm working on a project with an external library (libtcl, it is written
> in C) which creates some problems with back traces for exceptions.
> 
> If a custom TCL command raises an exception, I catch it and use the
> function DumpExceptionBackTrace to print the back trace. This function
> uses RaiseList which returns the ExceptObjectStack pointer. The stack
> frame information is filled by fpc_PushExceptObj in except.inc using the
> functions get_frame, get_caller_addr and get_caller_frame.
> 
> These three functions are also used by dump_stack which can be used at
> any point in the code (outside of exceptions).
> 
> These three functions assume, that the stack frame is stored in the RBP
> register (x86_64 architecture) and that every function call starts with
> these two assembler instructions
>   push   %rbp
>   mov    %rsp,%rbp
> which leads to the stack layout of the return address (pushed by the
> "call" instruction) followed by the RBP value.
> 
> As this is true for FreePascal code (I guess), this doesn't necessarily
> hold for external libraries as the TCL library mentioned above.

News on that front: Today I investigated a duplicate key exception in
FGL.TFPSMaps.Add(AKey: Pointer): Integer. In the current Debian package
fp-units-rtl-2.6.4 2.6.4+dfsg-2 this seems to be compiled with looots of
optimization and without stack frame:

0000000000001918 <FGL_TFPSMAP_$__ADD$POINTER$$LONGINT>:
    1918:       48 81 ec 18 01 00 00    sub    $0x118,%rsp
    191f:       48 89 9c 24 08 01 00    mov    %rbx,0x108(%rsp)
    1926:       00 
    1927:       4c 89 a4 24 10 01 00    mov    %r12,0x110(%rsp)
    192e:       00 
    192f:       48 89 fb                mov    %rdi,%rbx
    1932:       49 89 f4                mov    %rsi,%r12

Even GDB couldn't trace back the stack there. :-O

Bye
  Hansi