Re: crash in FlexiSheet

[Eric Wasylishen]

On 2012-02-06, at 4:02 PM, Riccardo Mottola wrote:

> Hi,
>>> I agree. I did the memset and reshuffled some other initializations and 
>>> still get the crash, here:
>>> 
>>> (gdb) up
>>> #1  0x080acc39 in -[FSVarioMatrix resetCursorRects] (self=0xb7dd098c,
>>>    _cmd=0x863bb04) at FSVarioMatrix.m:418
>>> 418                             cr = [datasrc matrix:self 
>>> columnRangeForCell:cell];
>>> (gdb) p cell
>>> $1 = {row = 135341688, column = 0, dx =<optimized out>, dy =<optimized out>}
>>> 
>>> I suppose the rownumber is quite bogus here, but I can't see how it happens 
>>> to. the type seem to be of type "int" and consisntent, FSMakeCell is an 
>>> inline function...
>> While the value of row looks indeed bogus, this may be just a consequence of 
>> the fact that you compile the code with optimization turned on (as witnessed 
>> by the fact that dx and dy are optimized out). I'd suggest you recompile 
>> FlexiSheet without optimization turned on. This will make understanding the 
>> code in gdb much easier.
> The stupid thing is that if I build with debug=yes, the bug doesn't appear 
> and the application works. A hint more there is something fishy with memory 
> somewhere.
> 
> However, do you really think optimization can change tye type and thus make a 
> debug output meaning less? One thing is optimizing out, one thing is changing 
> the content of a struct. If it can indeed, then of course reading it out 
> "wrongly" could lead to display bogus stuff.


Is datasrc nil? Could be the message-returning-struct sent to nil bug.

Eric