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

[Martin]

On 05/06/2010 18:16, Jonas Maebe wrote:
> On 05 Jun 2010, at 19:13, Martin wrote:
>
>    
>> Interesting too. The RTL was not modified between the builds =>  so the crash depended solely on the flags used to build lazarus/LCL
>>      
> I'm not aware of any potential problems caused by combining -O2 and -gt.
>
>    

Well the interesting thing is, it only happens under trunk, and in this 
combination.

so either -gt was improved to catch something it didn't catch before, or 
-O2 / -gt degraded to conflict with each other....




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

#3 READPROPERTY(0xd529588, 0xdc97a60) at ..\objpas\classes\reader.inc:1235
   looking at the frame of this procedure, both the variable passed in 
to [#2] are *not* nil


#4 READDATA(0xd529588, 0xdc97a60) at ..\objpas\classes\reader.inc:963
#5 READSTATE(0x0, 0x0) at ..\objpas\classes\compon.inc:317
#6 READSTATE(0xdc97a60, 0xd529588) at include\control.inc:3163
#7 READCOMPONENT(0xd529588, 0x0) at ..\objpas\classes\reader.inc:927
#8 READDATA(0xd529588, 0xdc976b0) at ..\objpas\classes\reader.inc:976
#9 READSTATE(0x0, 0x0) at ..\objpas\classes\compon.inc:317
#10 READSTATE(0xdc976b0, 0xd529588) at include\control.inc:3163
#11 READCOMPONENT(0xd529588, 0x0) at ..\objpas\classes\reader.inc:927
#12 READDATA(0xd529588, 0xdc88170) at ..\objpas\classes\reader.inc:976
#13 READSTATE(0x0, 0x0) at ..\objpas\classes\compon.inc:317
#14 READSTATE(0xdc88170, 0xd529588) at include\control.inc:3163
#15 READROOTCOMPONENT(0xd529588, 0xdc88170) at 
..\objpas\classes\reader.inc:1433
#16 INITCOMPONENT(0xa3dfdb8, 0xd169bc) at lresources.pp:3043
#17 INITLAZRESOURCECOMPONENT(0xdc88170, 0xadaba8) at lresources.pp:3063
#18 ?? at :0
#19 $FORMS$_Ld121 at :0
#20 $FINDREPLACEDIALOG$_Ld3 at :0
#21 INITRESOURCECOMPONENT(0x0, 0x0) at lresources.pp:760
#22 CREATE(0xdc88170, 0x0, 0x0) at include\customform.inc:1854
#23 CREATE(0x0, 0xa3df740, 0xb96af8) at include\customform.inc:2749
#24 CREATE(0xb96af8, 0xa3df740, 0xd529588) at findreplacedialog.pp:138
#25 CREATEOFTENUSEDFORMS(0xa3df740) at main.pp:1477
#26 main at lazarus.pp:103

----------------
within 2, I single stepped it
     tkEnumeration:
       begin
         Value := GetEnumValue(PropType, ReadIdent);
         if Value = -1 then
           raise EReadError.Create(SInvalidPropertyValue);
         SetOrdProp(Instance, PropInfo, Value);
       end;

it sets the property on the instance
property "Kind" on a TBitBtn

I single steped all through TBitBtn.SetKind without any sign of an 
exception there (yet I would expect something must have been changed 
there, as this is code that is affected by the compiler flags)

and reaches the procedure's "end" statement => and that's where the 
xecptio happens, or becomes note-able
(it goes into various fpc_AnsiStr_Decr_Ref and then ends up in fpc_ReRaise)


I have absolutely no idea.
I know it's possibl;e that it's a bug in the LCL, that is only revealed 
by the set of options, and only in trunk..

If you ask me about likelihoods, I would say it's a bug caused by the 
optimization (since 2.4.0 with the same settigns is fine.

As far as debugging goes from my site => that's the best I can do, 
withou any significant feedback from someone who knows more.

If someone can point out any revision in fpc trunk that had significant 
changes to -O2 or -gt => I can test them.
But please don't excpect me to test a dozend of them.
(It takes ages to recompile, and my computer will be busy enough during 
this time to prevent me from doing anything.)


Martin