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. _______________________________________________ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
