Hi,

I hope somebody knows more about GDB that I. I'm trying to debug an error in one of our Master Maths projects. This error only occurs under Windows, where it bombs out at random times (in a specific section of our product) with a "Segmentation Fault" error. GDB pauses the program at that point, and the stack trace gives me the follow information (shown below).

That output unfortunately doesn't tell me much at all. :-(

Any idea how I can get more information from GDB? I have enabled the following FPC compiler options: -l -Mobjfpc -Sch -g -gl -gw -O- -godwarfsets

My fpc.cfg file is also set to NOT strip debug information (just in case).

I'm using FPC 2.6.0 (32-bit) released version to make sure I'm on a stable FPC (I recently had issues with 2.6.1).

I've also tried various GDB versions (6.8, 7.2 & 7.4) under Windows, thinking that newer versions might give me more information, but in all versions the crash output is exactly the same.

-------------------------------
Signal received. Signal: SIGSEGV, Segmentation fault.

#0 0040E1BB :0 SYSTEM_WAITFREE_FIXED$PMEMCHUNK_FIXED$POSCHUNK() #1 01FB8D3C :0 ??()
#2 0040C51A :0 fpc_finalize()
#3 00000001 :0 ??()
#4 0040AD2A :0 SYSTEM_TOBJECT_$__CLEANUPINSTANCE() #5 00520D80 :0 $MDLEXERCISE$_Ld37()
#6 00000001 :0 ??()
#7 01F0D888 :0 ??()
#8 00000000 :0 ??()
-------------------------------

I've spent two days on this already and about to loose my mind. :-/ From the stacktrace above the only thing I can recognise, is the 'mdlexercise' text, which is a unit in our project. But without any line numbers it is like looking for a needle in a very large haystack.

Any GDB tips somebody can share, that could help me get GDB to reveal more debug information?

Regards,
- Graeme -

GDB can't give you a proper stack trace because memory has been corrupted (as evidenced by the crash in SYSTEM_WAITFREE_FIXED), and/or because the release RTL has been compiled with -O2 and that setting includes stack frame omissions (and FPC does not include stack frame layout information on i386). There's no line number information for the $MDLEXERCISE$_Ld37 symbol because that's a data label, not a code address, and hence there is simply no line number information for it.

The first thing you can try is to compile with -gh, hoping that it will abort in a place closer to the cause of the problem. -CRr is also a very useful debugging switch. If that doesn't help, you try running the program under Dr Memory (http://www.drmemory.org/ ) and/or recompiling the FPC 2.6.0 rtl from source without optimizations, optionally also with debug information.

Jonas

Jonas Maebe wrote

The first thing you can try is to compile with -gh, hoping that it will abort in a place closer to the cause of the problem. -CRr is also a very useful debugging switch.

Thanks for the detailed information. The bug is not fixed yet, but I did eventually get GDB to give me a more detailed backtrace. :)

Regards,
- Graeme -

I recently had a similarly strange error with almost exactly the same stack trace. After using a compiler and RTL that was compioled with full debug info and -O- it turned out that it happened during freeing of reference counted variables at the end of a procedure.

Maybe the following might ring a bell:

In my specific case my fault was to fill a dynamic array of PChar with pointers that pointed into a TStringList and then I passed a pointer to the first element of that array to a GTK function. Although this external function was supposed to make a deep copy of all my strings before it returns for some reason (and I still don't understand exactly why) passing these pointers to gtk (it was a drag-drop operation to the *same* application) was somehow able to corrupt FPC's memory and it crashed exactly at the moment when FPC heap manager tried to clean up some strings and dynamic arrays at the end.

Interestingly (and this is the part I do not yet fully understand) while my misuse of these fragile PChar() was on the sending side of that drag/drop it actually crashed on the receiving side where the sent strings came out of GTK again (in the same application) in the LCL code when it tried to free a dynamic array of the *received* strings)

Explicitly allocating some dedicated memory for my strings, making a copy and manually freeing it afterwards and not messing around with (and relying on) pointers deep into FPC managed reference counted memory solved this problem.