[fpc-devel] about bug 0016668 (-gt -O2)

[Martin]

On 09/06/2010 17:02, Jonas Maebe wrote:
> On 08 Jun 2010, at 16:35, Martin wrote:
>
>    
>> Yes, trashing with 0 does not corrupt the code =>  I am aware of that.
>>
>> But as I pointed out, something else does (that something else may be Lazarus or FPC). So far I have no idea what this something else could be.
>>
>> There is a slight change, that correct trashing, may change the location of the error in a way that will allow it, to track the problem. Of course, it may not, it's ju7st a hope.
>>      
> In case the problem is triggered by initialising with 0: you can make the compiler trash all local variables etc with 0 instead of with $55555555 by compiling with -gtttt instead of with -gt (and then you can try without -O2/-Ooregvar, which will make debugging easier). For completeness: -gtt uses $AAAAAAAA and -gttt uses $EFEFEFEF. Using more t's will just wrap around.
>    

Thanks, unfortunately, it didn't change much to the other problem....

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?