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