<div dir="ltr"><div><div><div>Thanks Jonas, that confirms what I suspected. Next time I trap an instance of this (rare) fault I will inspect exactly which CPU instruction raised the SEGV inside fpc_AnsiStr_Decr_Ref in search of a source of memory corruption.<br>
<br></div></div></div><div><br></div>Bruce.<br></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Wed, May 8, 2013 at 11:49 PM, Jonas Maebe <span dir="ltr"><<a href="mailto:jonas.maebe@elis.ugent.be" target="_blank">jonas.maebe@elis.ugent.be</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im"><br>
On 08 May 2013, at 08:13, Bruce Tulloch wrote:<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
After a random but very long period of time (i.e. very many successful<br>
calls) I get a SEGV in the built-in function fpc_AnsiStr_Decr_Ref.<br>
<br>
GDB reports the argument to fpc_AnsiStr_Decr_Ref (the string who's<br>
reference is to be decremented) is nil (i.e. 0x0).<br>
<br>
Prima facie, that's the reason for the SEGV, but how is it possible that<br>
the compiler would pass a nil pointer to this function the first place?<br>
</blockquote>
<br></div>
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.<br>
<br>
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.<div class="im"><br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
To put this into context, I'm running FPC 2.6.2 on a 32 bit Linux system<br>
executing in a multi-threaded application (which uses python threads and<br>
fpc threads). I have not found obvious evidence of memory corruption from<br>
other execution contexts or shared memory handling problems.<br>
</blockquote>
<br></div>
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).<br>

<br>
<br>
Jonas<br>
______________________________<u></u>_________________<br>
fpc-pascal maillist  -  <a href="mailto:fpc-pascal@lists.freepascal.org" target="_blank">fpc-pascal@lists.freepascal.<u></u>org</a><br>
<a href="http://lists.freepascal.org/mailman/listinfo/fpc-pascal" target="_blank">http://lists.freepascal.org/<u></u>mailman/listinfo/fpc-pascal</a><br>
</blockquote></div><br></div>