[bug #42782] Crash when loading a gorm file

[Yavor Doganov]

Follow-up Comment #14, bug #42782 (project gnustep):

I was wrong, cannot reproduce with GCC 4.8.3.  Gorm opens the file just fine. 
Vindaloo crashes at -[CenteringClipView constrainScrollPoint:] which could be
a bug in Vindaloo as it opens the PDF file if I modify it to use plain
NSClipView. The backtrace shows a corrupt stack again:

Program received signal SIGSEGV, Segmentation fault.
0x0804bb34 in -[CenteringClipView constrainScrollPoint:] (self=0xbffff088, 
    _cmd=0x83e7600, proposedNewOrigin=...) at CenteringClipView.m:82
82         return newScrollPoint;
(gdb) bt
#0  0x0804bb34 in -[CenteringClipView constrainScrollPoint:] (self=0xbffff088,

    _cmd=0x83e7600, proposedNewOrigin=...) at CenteringClipView.m:82
#1  0xbffff0b8 in ?? ()
Backtrace stopped: previous frame inner to this frame (corrupt stack?)


Two interesting things:

* In -[GSWindowTemplate initWithCoder:] there's no _object as well but no
crash either.  The execution continues.

* -[CenteringClipView setFrame:] just calls the super class implementation,
which in turn calls [self setBoundsOrigin: [self constrainScrollPoint:
_bounds.origin]]; _bounds is undefined at this point.  This method is actually
overriden with Vindaloo's own -constrainScrollPoint: where the crash happens. 
proposedNewOrigin is optimized there, it might be just garbage and not a valid
NSPoint.

    _______________________________________________________

Reply to this item at:

  <http://savannah.gnu.org/bugs/?42782>

_______________________________________________
  Message sent via/by Savannah
  http://savannah.gnu.org/