I've not managed to trap it again, but based on the information I have from the last time it occurred I can say the error happened here:
--- a/rtl/i386/i386.inc +++ b/rtl/i386/i386.inc @@ -1523,7 +1523,7 @@ movl (%eax),%edx subl $8,%edx // [102] If l^<0 then exit; cmpl $0,(%edx) <-- SEGV OCCURS HERE jl .Lj3596 .Lj3603: // [104] If declocked(l^) then That is, when testing the string length, the address of the length variable appears to be duff. I don't know what %edx was pointing to at the time (I hope to know next time I trap it) but it was obviously wrong. -b On Thu, May 9, 2013 at 9:33 AM, Bruce Tulloch <pas...@causal.com> wrote: > 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. > > > Bruce. > > > On Wed, May 8, 2013 at 11:49 PM, Jonas Maebe <jonas.ma...@elis.ugent.be>wrote: > >> >> 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<fpc-pascal@lists.freepascal.org> >> http://lists.freepascal.org/**mailman/listinfo/fpc-pascal<http://lists.freepascal.org/mailman/listinfo/fpc-pascal> >> > >
_______________________________________________ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal