[fpc-pascal] How to analyze a core dump?
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;
>> (FOwner is a TButlerPhone)
>> which in turn is called only here:
>> if buffer[i+L+1]=checksum(FData) then
>> 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)
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