[fpc-pascal] FPC 2.6.2 throws SEGV in fpc_AnsiStr_Decr_Ref(). How is this possible?
pascaldragon at googlemail.com
Thu May 9 18:18:55 CEST 2013
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...
More information about the fpc-pascal