On 09.05.2013 14:39, Bruce Tulloch wrote:
Thanks José, I can see that might cause a problem given bar passes
result by reference to foo without initializing result first. My
question to Jonas or others more knowledgeable than me about what the
compiler does, is whether result (in your example and my own case) is
guaranteed to be initialized to nil when it first appears in scope (i.e.
before it's been assigned any value in our code). If it is initialized
to nil, then foo would receive a reference to bar's result variable (via
para) and the value of that variable would be nil (and all would be
okay). If it isn't initialized to nil, the same rule applies but the
value of result (as seen by foo via para) would likely be invalid and
would probably blow up in foo when dereferenced (as a string).
My problem is similar except that I know it's not nil when passed in
(because the initial test in fpc_AnsiStr_Decr_Ref looking for nil
passes) but that it becomes nil very soon afterward (because the SEGV
arises as an indirect result of it being nil, as I explained in my reply
to Ludo just now).
I'm pretty sure I have a shared memory problem somewhere between threads
in my code but I can't understand how this could be given the
"erroneously shared" variable appears to be an automatic variable (i.e.
Result) that has just been created on the stack in the function foo that
calls fpc_AnsiStr_Decr_Ref where the SEGV occurs.
I'll keep looking :-) Bruce.
Do you play around with pointers anywhere? I once had it that I
overwrote something in a parent stackframe, so maybe you could by
accident access the memory location of the Result variable...
Regards,
Sven
_______________________________________________
fpc-pascal maillist - [email protected]
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
