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.

In the program I could narrow the problem down to line 117 in parser.pp. If that one was removed it ran fine

Of course, because removing that line causes nothing to be parsed (it's the first top level production that deals with something from the input) ;)

Sorry, I was referring to the new code. Yes, that line adds class instance to TFPGObjectList.

Maybe it should use "constref" instead of "const". There's indeed no guarantee whatsoever that a "const" parameter will be passed by reference, and hence @item will indeed result in a stack address in many cases.

Jonas

Ah yes. Michael is correct. TFPSList copies FItemSize bytes from that pointer. But it would probably be a very good idea to use constref instead of const anyway

I've tried changing const to constref and recompile fgl unit, no effect :(

Update: this is something really really weird, if AStream.Free (last statement) in linguc.lpr is removed, then the error's totally GONE!