[fpc-devel] Re: FPC, overrides random memory / example to reproduce

[Martin]

compile the below code with -gt -O2 -al

and you get
# Var StockID located in register edx
# Var Image located in register ecx
# Var Mask located in register eax
# Var $self located in register eax
# Var $result located in register al
     movl    8(%ebp),%eax
.Ll2:
     movb    $85,%al
     movl    $1431655765,(%ecx)
     movl    $1431655765,(%eax)



program project1;

{$mode objfpc}{$H+}

uses
   {$IFDEF UNIX}{$IFDEF UseCThreads}
   cthreads,
   {$ENDIF}{$ENDIF}
   Classes
   { you can add units after this };

{$R *.res}

type
TBar = class
   function foo(StockID: LongInt; out Image, Mask: Longint): Boolean;
end;

function TBar.foo(StockID: LongInt; out Image, Mask: Longint): Boolean;
begin
   Result := False;
end;

var a,b: Integer;
x:TBar;
begin
x.foo(0,a,b);
end.


On 18/06/2010 16:14, Martin wrote:
> Ok, unfortunately I haven't got instruction for reproductions.
>
> The bug does no longer happen in todays lazarus svn code. => I'll try 
> to work out a revision where it happens. (likely laz svn 25937)
>
> I found the fo9llowing assembler (disassembled by gdb) was generated for
>
> mov    $0x55,%al
> movl   $0x55555555,(%ecx)
> movl   $0x55555555,(%eax)
>
> function TThemeServices.GetStockImage(StockID: LongInt; out Image, 
> Mask: HBitmap): Boolean;
> var
>   img : TBitmap;
> begin
>
> if lazarus was compiled with
>  -gh   -g  -gl  -gw -godwarfsets    -CX -XX -Xs  -gt -O2   -OpPENTIUMM
>
>
> since "al" is trashed first, and then the content of the address 
> pointed to by eax => eax is no longer correct => some random memory is 
> trashed.
>
> al seems to be the result, eax must be one of the params
>
> svn rev 15398
>
>
> Martin
>
>
>
> On 09/06/2010 18:44, Martin wrote:
>> On 09/06/2010 18:42, Martin wrote:
>>>
>>> I am one tiny step forward..
>>>
>>> The SigSegV happens in fpc_ReRaise; => but the actual error must 
>>> have been introduced further up.
>>>
>>> Procedure fpc_ReRaise;[Public, Alias : 'FPC_RERAISE']; compilerproc;
>>> var
>>>   _ExceptAddrStack : PExceptAddr;
>>> begin
>>> {$ifdef excdebug}
>>>   writeln ('In reraise');
>>> {$endif}
>>>   _ExceptAddrStack:=ExceptAddrStack;
>>>   If _ExceptAddrStack=Nil then
>>>     DoUnHandledException;
>>>   ExceptObjectStack^.refcount := 0; // <<<<<<<<<<<<<<<<<
>>>   longjmp(_ExceptAddrStack^.Buf^,FPC_Exception);
>>> end;
>>>
>>>
>>> This is RTL (and compiled with -O1 => it doesn't use regvar), so I 
>>> should be able to trust variables here. (I also checked the 
>>> assembler view, and memory/registers...)
>>>
>>> - ExceptObjectStack is nil => So the line marked raises a SigSegV.
>>> - ExceptAddrStack is not nil => so DoUnHandledException was not called
>>>
>>> The question is, any hints where to concentrate looking, in order to 
>>> find out, how this can end up with a nil pointer there?
>>
>> The content of ExceptAddrStack
>>
>> record TEXCEPTADDR {
>>   BUF = $a3ef728,
>>   NEXT = $a3ef768,
>>   FRAMETYPE = 1}
>> _______________________________________________
>> fpc-devel maillist  -  fpc-devel at lists.freepascal.org
>> http://lists.freepascal.org/mailman/listinfo/fpc-devel
>
> _______________________________________________
> fpc-devel maillist  -  fpc-devel at lists.freepascal.org
> http://lists.freepascal.org/mailman/listinfo/fpc-devel