<div dir="ltr"> After a random but very long period of time (i.e. very many successful calls) I get a SEGV in the built-in function fpc_AnsiStr_Decr_Ref.<br><div><div><br>GDB reports the argument to fpc_AnsiStr_Decr_Ref (the string who's reference is to be decremented) is nil (i.e. 0x0).<br>
<br></div><div>Prima facie, that's the reason for the SEGV, but how is it possible that the compiler would pass a nil pointer to this function the first place?<br></div><div><br></div><div>To put this into context, I'm running FPC 2.6.2 on a 32 bit Linux system executing in a multi-threaded application (which uses python threads and fpc threads). I have not found obvious evidence of memory corruption from other execution contexts or shared memory handling problems.<br>
<br><div><div>The SEGV occurs when called from a function, let's call it foo, that looks like this:<br></div><div><br><div style="margin-left:40px">function foo : AnsiString;<br>begin<br>  Result := '';<br> <other stuff><br>
end;<br></div></div></div><div><br></div>The AnsiString pointer that fpc_AnsiStr_Decr_Ref throws a SEGV is Result, at the first line of the function foo.<br><br></div><div>It appears the compiler is passing Result to fpc_AnsiStr_Decr_Ref even though Result (at this point in the function) must be nil (having only just come into scope).<br>
<br></div><div>How is is possible that fpc_AnsiStr_Decr_Ref is being called at all?<br><br> Any/all advice gratefully received.<br><br></div><div>Cheers, Bruce.<br></div></div></div>