On 08 May 2013, at 08:13, Bruce Tulloch 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?
The first thing fpc_AnsiStr_Decr_Ref does is check whether its
parameter is nil, and if so it immediately exists. It can be nil in
case the ansistring contains an empty string.
That routine itself also sets its argument to nil in case this was not
the case initially (it's a var-parameter), and I assume your crash
happens after this has been done.
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.
It's nevertheless most likely memory corruption. You can try compiling
with -gv and running your program under valgrind to see whether it
finds anything (you will probably get some false positives about
certain RTL pchar routines such as strscan and strlen, but you can
ignore those).
Jonas
_______________________________________________
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
