discuss-gnustep
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: crash in FlexiSheet


From: Riccardo Mottola
Subject: Re: crash in FlexiSheet
Date: Tue, 07 Feb 2012 00:02:41 +0100
User-agent: Mozilla/5.0 (X11; Linux i686; rv:8.0) Gecko/20120104 Icedove/8.0

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.

Riccardo



reply via email to

[Prev in Thread] Current Thread [Next in Thread]