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

[Luca Olivetti]

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)

TMyThread.Constructor(astring:string);
begin
   FString:=astring;
   FNum:=StrToInt(FString);
   inherited create(false);
end;


instead of

TMyThread.Constructor(astring:string);
begin
   FNum:=StrToInt(astring);
   inherited create(false);
end;


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 ;-)

Bye
-- 
Luca