[fpc-pascal] FPC 2.6.2 throws SEGV in fpc_AnsiStr_Decr_Ref(). How is this possible?

[Bruce Tulloch]

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 <pascal at 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.maebe at 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 at lists.freepascal.**org<fpc-pascal at lists.freepascal.org>
>> http://lists.freepascal.org/**mailman/listinfo/fpc-pascal<http://lists.freepascal.org/mailman/listinfo/fpc-pascal>
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freepascal.org/pipermail/fpc-pascal/attachments/20130509/2c95fbde/attachment.html>