[fpc-devel] crash with -gt -O2 in trunk

[Martin]

On 05/06/2010 19:57, Jonas Maebe wrote:
> On 05 Jun 2010, at 20:25, Martin wrote:
>
>    
>> Ok, I caught it in the debugger:
>> Only problem is I don't know how reliable the values are, since -O2 isn't debugger friendly
>>
>>
>> #0 fpc_reraise at ..\inc\except.inc:305
>> #1 ?? at :0
>> #2 READPROPVALUE(0xd529588, 0x0, 0x0) at ..\objpas\classes\reader.inc:1379
>>      procedure TReader.ReadPropValue(Instance: TPersistent; PropInfo: Pointer);
>>   The location of the crash is shown as inside the "end;" of the procedure =>  but that may be the debugger not coping with the optimization level
>>
>>   Interstingly, at the time of crash, if looking at the stackframe, the debugger believes that the variable "Instance" is nil; now that would aco8unt for a crash.
>>   The variable is not modified by the procedure (not as far as I can see)
>>   See comment below: it would appear it was none nil to start with. If it is indeed nil at the time of the crash =>  then where was it set to nil?
>>
>>   Same for PropInfo
>>      
> The values of variables shown in the debugger cannot be relied upon when using -O2.
>    
I know, but for those that did have a value, I can make a reasonable 
assumption that, if the value had properties like Fname => which pointed 
to the correct name-string, then that variable probably held the correct 
value...

As for them being nil => I don't thing that's the cause => that is 
simply what happens in the procedures "end" statement.
As I said I single stepped through the method, and the called code => 
and there was no problem during that single stepping (unless it would 
have been an exception that gdb does not notice)


>> If someone can point out any revision in fpc trunk that had significant changes to -O2 or -gt =>  I can test them.
>>      
> One thing that was added is the node level CSE optimiser. You can disable it with the -Oonocse command line option (put it in the command line after -O2). There are no changes to -gt that I remember.
>    

Unfortunately no luck.
   -gh -g -gt -gl  -gw -godwarfsets    -CX -XX -Xs   -O2   -Oonocse

I noted that if I compile with -Cr (range checks), then it fails earlier 
(ButtonPanel.Create) => but that is also shortly after bitbtn.kind 
(bitbtn.create) code. It also fails with a SigSegV, not with a range-check.

BitBtn.kind loads glyphs from resources... So there could be something 
there.  Only it must be something that doesn't crash straight ahead. => 
like accessing random mem => or messng around with the stack a few 
frames above it's own stack (since I guess a sigsegv inside a procedures 
"end" means that the current stackframe got corrupted?)

Martin