Re: crash in FlexiSheet

[Wolfgang Lux]

Riccardo Mottola wrote:

> Hi,
>> Again, as long as you are the only one with the back trace, there is nothing 
>> I can do to help you. Are you sure you don't have any local changes to 
>> FlexiSheet on that machine?
>> 
>> The line 407, where your back trace reports the problem looks like this:
>>                    if ((x >= visible.origin.x) && (x <= maxX)) {
>> 
>> visible has been accessed already. What you could try to do is to clear the 
>> memory used by _colWidths and _rowHeights in [FSMatrix -initWithFrame:] by 
>> calling memset() and also in the various places where they get reallocated. 
>> If these variables get used without proper initialisation then the program 
>> may go astray as in your back trace.
>> 
>> But this definitely is an application bug. We may as well look into this 
>> after the release.
> 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.

Wolfgang