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
_______________________________________________
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
