[fpc-pascal] Segmentation fault gone if compiled with -glh

[michael.vancanneyt at wisa.be]

On Mon, 10 Jan 2011, Jeppe Johansen wrote:

> Den 10-01-2011 02:36, leledumbo skrev:
>> Compile the attached project (really difficult to trim it down) using two
>> different options. First, using -glh, then using -g. The first one raises
>> nothing (program runs fine), while the second raises segmentation fault.
>> When debugged deeper using gdb, the second gives this backtrace:
>> 
>> Program received signal SIGSEGV, Segmentation fault.
>> 0x004091da in SYSTEM_REMOVE_FREED_FIXED_CHUNKS$POSCHUNK ()
>> (gdb) bt
>> #0 0x004091da in SYSTEM_REMOVE_FREED_FIXED_CHUNKS$POSCHUNK ()
>> 0000001 0x00000010 in ?? ()
>> 0000002 0x000651c4 in ?? ()
>> 0000003 0x00408898 in SYSTEM_FINALIZEUNITS ()
>> 0000004 0x00065a38 in ?? ()
>> 0000005 0x0040c0e1 in SYSTEM_EXE_ENTRY$TENTRYINFORMATION ()
>> 
>> Jonas told me to discuss it here due to unclearness whether this is a bug 
>> in
>> my program or in fgl or wherever else.
>> 
>> The source code:
>> http://free-pascal-general.1045716.n5.nabble.com/file/n3334353/src.zip
>> src.zip
> For me the program results in an endless list of unhandled exceptions 
> somewhere in the rtl
> In the program I could narrow the problem down to line 117 in parser.pp. If 
> that one was removed it ran fine
>
> Doesn't the problem lie in that TFPGObjectList uses @ on the incoming 
> parameters?
>
> function TFPGObjectList.Add(const Item: T): Integer;
> begin
>  Result := inherited Add(@Item);
> end;
>
> Unless there's some magic going on, won't it then point to the stack, instead 
> of the instance, in most cases?

As far as I remember, the add will use the address+size of T to Move()  the
contents of item. In effect, it will move the Item pointer.

Michael.