[fpc-pascal] GDB help needed please

Bernd K. prof7bit at gmail.com
Fri Aug 31 12:56:09 CEST 2012

On 30.08.2012 00:13, Graeme Geldenhuys wrote:

> Signal received. Signal: SIGSEGV, Segmentation fault.
> #1  01FB8D3C :0 ??()
> #2  0040C51A :0 fpc_finalize()
> #3  00000001 :0 ??()
> #5  00520D80 :0 $MDLEXERCISE$_Ld37()
> #6  00000001 :0 ??()
> #7  01F0D888 :0 ??()
> #8  00000000 :0 ??()
> -------------------------------

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.

More information about the fpc-pascal mailing list