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


_______________________________________________
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Reply via email to