I should clarify, foo is a virtual method of an object, not a regular function. -b
On Wed, May 8, 2013 at 4:13 PM, Bruce Tulloch <pas...@causal.com> wrote: > 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. > > GDB reports the argument to fpc_AnsiStr_Decr_Ref (the string who's > reference is to be decremented) is nil (i.e. 0x0). > > 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? > > 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. > > The SEGV occurs when called from a function, let's call it foo, that looks > like this: > > function foo : AnsiString; > begin > Result := ''; > <other stuff> > end; > > The AnsiString pointer that fpc_AnsiStr_Decr_Ref throws a SEGV is Result, > at the first line of the function foo. > > 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). > > How is is possible that fpc_AnsiStr_Decr_Ref is being called at all? > > Any/all advice gratefully received. > > Cheers, Bruce. >
_______________________________________________ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
