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

Luca Olivetti luca at ventoso.org
Wed Jun 27 12:48:00 CEST 2007

En/na Vinzent Hoefler ha escrit:
> 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?

yes and no: the synchronize should assure that TButlerPhone.Receive is 
called from the main thread, and TStatusThread will wait until 
completion of the call.

> If that's the case try 
> using shortstrings or make a local copy of the parameter

I'll try that (though I think it shouldn't be necessary)

>. And *DO NOT* 
> pass them to a C-library in any way!

Not even surrounded by PChar()?
(now that I think of it, it could well be that the library is storing 
the pointer and using it later when it is no longer valid, let me 
check....no, it doesn't).

> 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.

Do you mean like (absurd example, I know)

   inherited create(false);

instead of

   inherited create(false);

again, I don't think it should be necessary if you're only going to use 
astring in the constructor.

> 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.

thanks, I'll give it a try, though the last time I used assembly 
language was with a Z80 when it was new ;-)


More information about the fpc-pascal mailing list