[fpc-pascal] How to analyze a core dump?

[Vinzent Hoefler]

On Tuesday 26 June 2007 17:26, Luca Olivetti wrote:

> procedure TButlerPhone.Receive(s: string);
>
> so s is a parameter.
> This procedure is called exclusively from
>
> procedure TStatusThread.Receive;
> begin
>    FOwner.Receive(FData)
> end;
>
> (FOwner is a TButlerPhone)
>
> which in turn is called only here:
>
>            FData:=copy(buffer,i+2,L-1);
>            if buffer[i+L+1]=checksum(FData) then
>            begin
>             if not terminated then synchronize(@Receive);
>            end else

Are you passing AnsiString types between threads? If that's the case try 
using shortstrings or make a local copy of the parameter. And *DO NOT* 
pass them to a C-library in any way!

I had several problems doing that too (and I don't mean the obvious case 
if the string is changed in one thread while it's still accessed in the 
other). There also seemed to be some issues with the reference 
counting: if I passed a local AnsiString to a thread constructor as 
argument and left the routine then, this seemed to confuse the thread 
throwing SIGSEGVs occasionally. Making a copy of the string (means: 
assigning it to a field in the thread instance before and using this 
field from now on) inside the constructor solved this problem.

BTW, using the "disassemble" function of gdb sometimes reveals where the 
unnamed routine really is, so for the

> #3  0x08059bec in ?? ()
> No symbol table info available.

"disassemble 0x8059bec" *might* help you invastigating the source of the 
problem further.


HTH,

Vinzent.