[fpc-pascal] How to analyze a core dump?
JeLlyFish.software at gmx.net
Wed Jun 27 08:13:20 CEST 2007
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? 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
More information about the fpc-pascal