bugGNUstep - Bugs: bug #42782, Crash when loading a gorm file

Group
 
 

bug #42782: Crash when loading a gorm file

Submitter:  Yavor Doganov <yavor>
Submitted:  Wed 16 Jul 2014 12:22:11 PM UTC
   
 
Category:  Gorm Severity:  3 - Normal
Item Group:  Bug Status:  Fixed
Privacy:  Public Assigned to:  FredKiefer
Open/Closed:  Closed
* Mandatory Fields

Add a New Comment Rich Markup
   

Jump to the original submission

Mon 10 Nov 2014 08:40:01 PM UTC, comment #22: 

Closed on request of original author.

Fred Kiefer <FredKiefer>
Group Member
Sat 01 Nov 2014 08:17:47 PM UTC, comment #21: 


> The issues comes from the fact that there is a file called
> data.info that contains metadata needed for editing. Since this > file has a .info extension and the GSImageMagickImageRep
> reports that it can load .info files, Gorm attempts to load
> this as an image and, naturally, fails.


Yes, this was precisely the problem, thanks for fixing it.  I thought it was clear from comment #6 onwards, but...

> Looking at the history it is hard to follow and I believe it
> mixes two separate problems.


Sorry about that, it is very confusing indeed.  There are three different issues, actually:

 - The GSGormLoader bug that Fred fixed in GUI
 - The Gorm bug that you have fixed
 - The Vindaloo bug in its CenteringClipView implementation exposed by GCC 4.9 (I've fixed that in Debian at least)

You can close this bug; nothing to do here.

Yavor Doganov <yavor>
Tue 28 Oct 2014 07:08:17 AM UTC, comment #20: 

Guys, I have found the problem with Gorm/ImageMagick.  The issue steps from the fact that the GSImageMagickImageRep class reports back that it can load a file which has the extension of .info and that during the loading stages of the .gorm file it loads all images in the .gorm bundle so that it can resolve any images in the .gorm file during editing.

The issues comes from the fact that there is a file called data.info that contains metadata needed for editing.  Since this file has a .info extension and the GSImageMagickImageRep reports that it can load .info files, Gorm attempts to load this as an image and, naturally, fails.  This is why you're seeing this:

2014-07-25 12:51:42.026 Gorm[2165] Tiff Error (GSTiffReadData) Not a TIFF or MDI file, bad magic number 20039 (0x4e47)

I am adding code to Gorm to cause it to skip any image file called data.info.  I'm doing it this way so that we can still use files which are images with a .info extension, but just not one named data.info. ;)

Hopefully this solves part of the problem.   Looking at the history it is hard to follow and I believe it mixes two separate problems.   I believe Fred was correct in that a separate issue should be opened for the Vindaloo issue.

GC

Gregory John Casamento <gcasa>
Group administrator
Fri 25 Jul 2014 09:57:52 AM UTC, comment #19: 

Sorry for mixing the two issues.  You are right about Vindaloo. 

Unfortunately the Gorm backtrace is unlikely to be of any use:

Starting program: /usr/bin/Gorm /usr/lib/GNUstep/Applications/Ink.app/Resources/Document.gorm/
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/i386-linux-gnu/i686/cmov/libthread_db.so.1".
2014-07-25 12:51:42.026 Gorm[2165] Tiff Error (GSTiffReadData) Not a TIFF or MDI file, bad magic number 20039 (0x4e47)
2014-07-25 12:51:42.057 Gorm[2165] Tiff Error (GSTiffReadData) Not a TIFF or MDI file, bad magic number 20039 (0x4e47)

Program received signal SIGSEGV, Segmentation fault.
0x09ae01d1 in ?? ()
(gdb) bt
Python Exception <class 'gdb.MemoryError'> Cannot access memory at address 0x5:
#0  0x09ae01d1 in ?? ()
Cannot access memory at address 0x5


With your recent Gorm change I observe the behavior described in comment #6.

Yavor Doganov <yavor>
Fri 25 Jul 2014 08:26:34 AM UTC, comment #18: 

We should keep the Vindaloo bug separate from the Gorm image problem. The later one consists of the following:

- when the Imagemagick NSImageBitmap extension is installed info files get regarded as images
- each gorm directory contains one such file
- the Gorm loader tries to convert such a file into a GSGormImage
-  something goes wrong there

This is the bug we should be investigating here and for this I would need another stack trace that shows it. With that in place we should put the bug back in the open state.

The problem with GSWindowTemplate seems to be resolved and for the GSWindowTemplate you should open a new bug report.  I think this bug is caused by the Vindaloo code using documentView without checking whether it is nil. Have a look at the corresponding code in NSClipView, there we check for this case. Now most likely there is a subview of the CenteringClipView encoded in the gorm file. The question is, why it doesn't get used as the document view. But please use a new bug report otherwise I will loose the insight what has been resolved and what is still open.

Fred Kiefer <FredKiefer>
Group Member
Fri 25 Jul 2014 07:40:32 AM UTC, comment #17: 

Valgrind output:

==5323== Command: ./ViewPDF.app/ViewPDF /home/yavor/scratch/ba.pdf
==5323==
2014-07-25 10:35:51.324 ViewPDF[5323] added font n022003l.pfb
2014-07-25 10:35:51.916 ViewPDF[5323] added font n022004l.pfb
2014-07-25 10:35:51.944 ViewPDF[5323] added font n022024l.pfb
2014-07-25 10:35:51.970 ViewPDF[5323] added font n022023l.pfb
2014-07-25 10:35:51.996 ViewPDF[5323] added font n019003l.pfb
2014-07-25 10:35:52.022 ViewPDF[5323] added font n019004l.pfb
2014-07-25 10:35:52.048 ViewPDF[5323] added font n019024l.pfb
2014-07-25 10:35:52.074 ViewPDF[5323] added font n019023l.pfb
2014-07-25 10:35:52.099 ViewPDF[5323] added font s050000l.pfb
2014-07-25 10:35:52.126 ViewPDF[5323] added font n021004l.pfb
2014-07-25 10:35:52.151 ViewPDF[5323] added font n021024l.pfb
2014-07-25 10:35:52.177 ViewPDF[5323] added font n021023l.pfb
2014-07-25 10:35:52.203 ViewPDF[5323] added font n021003l.pfb
2014-07-25 10:35:52.229 ViewPDF[5323] added font d050000l.pfb
using default fontconfig configuration
registered application font /usr/lib/GNUstep/Frameworks/PopplerKit.framework/Versions/1.0/Resources/n022003l.pfb
registered application font /usr/lib/GNUstep/Frameworks/PopplerKit.framework/Versions/1.0/Resources/n022004l.pfb
registered application font /usr/lib/GNUstep/Frameworks/PopplerKit.framework/Versions/1.0/Resources/n022024l.pfb
registered application font /usr/lib/GNUstep/Frameworks/PopplerKit.framework/Versions/1.0/Resources/n022023l.pfb
registered application font /usr/lib/GNUstep/Frameworks/PopplerKit.framework/Versions/1.0/Resources/n019003l.pfb
registered application font /usr/lib/GNUstep/Frameworks/PopplerKit.framework/Versions/1.0/Resources/n019004l.pfb
registered application font /usr/lib/GNUstep/Frameworks/PopplerKit.framework/Versions/1.0/Resources/n019024l.pfb
registered application font /usr/lib/GNUstep/Frameworks/PopplerKit.framework/Versions/1.0/Resources/n019023l.pfb
registered application font /usr/lib/GNUstep/Frameworks/PopplerKit.framework/Versions/1.0/Resources/s050000l.pfb
registered application font /usr/lib/GNUstep/Frameworks/PopplerKit.framework/Versions/1.0/Resources/n021004l.pfb
registered application font /usr/lib/GNUstep/Frameworks/PopplerKit.framework/Versions/1.0/Resources/n021024l.pfb
registered application font /usr/lib/GNUstep/Frameworks/PopplerKit.framework/Versions/1.0/Resources/n021023l.pfb
registered application font /usr/lib/GNUstep/Frameworks/PopplerKit.framework/Versions/1.0/Resources/n021003l.pfb
registered application font /usr/lib/GNUstep/Frameworks/PopplerKit.framework/Versions/1.0/Resources/d050000l.pfb
poppler library initialized
2014-07-25 10:36:03.531 ViewPDF[5323] PopplerKit Initialization SUCCEEDED
2014-07-25 10:36:09.114 ViewPDF[5323] use generic splash rendering
==5323== Conditional jump or move depends on uninitialised value(s)
==5323==    at 0x8049CBF: _i_CenteringClipView__constrainScrollPoint_ (CenteringClipView.m:64)
==5323==    by 0x44CD417: ??? (in /usr/lib/libgnustep-gui.so.0.24.0)
==5323==
==5323== Conditional jump or move depends on uninitialised value(s)
==5323==    at 0x8049D41: _i_CenteringClipView__constrainScrollPoint_ (CenteringClipView.m:70)
==5323==    by 0x44CD417: ??? (in /usr/lib/libgnustep-gui.so.0.24.0)
==5323==
==5323== Conditional jump or move depends on uninitialised value(s)
==5323==    at 0x8049D4D: _i_CenteringClipView__constrainScrollPoint_ (CenteringClipView.m:70)
==5323==    by 0x44CD417: ??? (in /usr/lib/libgnustep-gui.so.0.24.0)
==5323==
==5323== Conditional jump or move depends on uninitialised value(s)
==5323==    at 0x8049D54: _i_CenteringClipView__constrainScrollPoint_ (CenteringClipView.m:70)
==5323==    by 0x44CD417: ??? (in /usr/lib/libgnustep-gui.so.0.24.0)
==5323==
==5323== Conditional jump or move depends on uninitialised value(s)
==5323==    at 0x8049CF7: _i_CenteringClipView__constrainScrollPoint_ (CenteringClipView.m:74)
==5323==    by 0x44CD417: ??? (in /usr/lib/libgnustep-gui.so.0.24.0)
==5323==
==5323== Conditional jump or move depends on uninitialised value(s)
==5323==    at 0x8049D04: _i_CenteringClipView__constrainScrollPoint_ (CenteringClipView.m:80)
==5323==    by 0x44CD417: ??? (in /usr/lib/libgnustep-gui.so.0.24.0)
==5323==
==5323== Conditional jump or move depends on uninitialised value(s)
==5323==    at 0x8049D17: _i_CenteringClipView__constrainScrollPoint_ (CenteringClipView.m:80)
==5323==    by 0x44CD417: ??? (in /usr/lib/libgnustep-gui.so.0.24.0)
==5323==
==5323==
==5323== Process terminating with default action of signal 11 (SIGSEGV)
==5323==  Bad permissions for mapped region at address 0x4171AFB
==5323==    at 0x8049D24: _i_CenteringClipView__constrainScrollPoint_ (CenteringClipView.m:83)
==5323==    by 0x44CD417: ??? (in /usr/lib/libgnustep-gui.so.0.24.0)
==5323==


Yavor Doganov <yavor>
Fri 25 Jul 2014 07:15:17 AM UTC, comment #16: 

Now even older versions of Gorm open the file, but only if GUI is built with --disable-imagemagick.  With --enable-imagemagick, Gorm crashes and with your latest Gorm change shows an alert panel and doesn't open the file.  This happens with any gorm file, not just Document.gorm.  I believe this is a separate issue and related to the fact that all gorm files have .info files inside them.

Vindaloo crashes at a later stage and the backtrace is much more palatable:

Program received signal SIGSEGV, Segmentation fault.
0x08049d24 in -[CenteringClipView constrainScrollPoint:] (self=0xbffff0b8,
    _cmd=0x83960f8, proposedNewOrigin=...) at CenteringClipView.m:83
83           return newScrollPoint;
(gdb) bt
#0  0x08049d24 in -[CenteringClipView constrainScrollPoint:] (self=0xbffff0b8,
    _cmd=0x83960f8, proposedNewOrigin=...) at CenteringClipView.m:83
#1  0xb7ec5418 in _OBJC_SELECTOR_TABLE () from /usr/lib/libgnustep-gui.so.0.24
#2  0xb7b69afb in -[NSClipView setFrame:] (self=0x83960f8,
    _cmd=0x805c978 <_OBJC_SELECTOR_TABLE+888>, rect=...) at NSClipView.m:569
#3  0x08049efd in -[CenteringClipView setFrame:] (self=0x83960f8,
    _cmd=0xb7f2b3a8 <_OBJC_SELECTOR_TABLE+1320>, aFrame=...)
    at CenteringClipView.m:100
#4  0xb7c2a8b7 in -[NSScrollView tile] (self=0x82f9b68,
    _cmd=0xb7f2b220 <_OBJC_SELECTOR_TABLE+928>) at NSScrollView.m:1275
#5  0xb7c28275 in -[NSScrollView setContentView:] (self=0x82f9b68,
    _cmd=0x805e318 <_OBJC_SELECTOR_TABLE+1432>,
    aView=0xb7f2b220 <_OBJC_SELECTOR_TABLE+928>) at NSScrollView.m:278
#6  0x0804b31d in -[Controller(Private) _setupScrollView] (self=0x83778e0,
    _cmd=0x805e0e8 <_OBJC_SELECTOR_TABLE+872>) at Controller.m:359
#7  0x0804a1cf in -[Controller windowDidLoad] (self=0x83778e0,
    _cmd=0xb7f68270 <_OBJC_SELECTOR_TABLE+496>) at Controller.m:72
#8  0xb7ca851f in -[NSWindowController _windowDidLoad] (self=0x83778e0,
    _cmd=0xb7f680c8 <_OBJC_SELECTOR_TABLE+72>) at NSWindowController.m:472
#9  0xb7ca8bf4 in -[NSWindowController window] (self=0x83778e0,
    _cmd=0xb7f68130 <_OBJC_SELECTOR_TABLE+176>) at NSWindowController.m:318
#10 0xb7ca8719 in -[NSWindowController showWindow:] (self=0x83778e0,
    _cmd=0xb7edb1f8 <_OBJC_SELECTOR_TABLE+504>, sender=0x81819e0)
    at NSWindowController.m:395
#11 0xb76c121a in -[NSObject performSelector:withObject:] (self=0x83778e0,
    _cmd=0xb79b9e20 <_OBJC_SELECTOR_TABLE+224>,
    aSelector=0xb7edb1f8 <_OBJC_SELECTOR_TABLE+504>, anObject=0x81819e0)
    at NSObject.m:2034
#12 0xb75b0f42 in -[GSArray makeObjectsPerformSelector:withObject:] (
    self=0x87dbf58, _cmd=0xb7edb200 <_OBJC_SELECTOR_TABLE+512>,
    aSelector=0xb7edb1f8 <_OBJC_SELECTOR_TABLE+504>, argument=0x81819e0)
    at GSArray.m:353
#13 0xb7b91332 in -[NSDocument showWindows] (self=0x81819e0,
    _cmd=0xb7edd868 <_OBJC_SELECTOR_TABLE+488>) at NSDocument.m:417
#14 0xb7b95885 in -[NSDocumentController openDocumentWithContentsOfURL:display:error:] (self=0xb7edd868 <_OBJC_SELECTOR_TABLE+488>,
    _cmd=0xb7f73688 <_OBJC_SELECTOR_TABLE+520>, url=0x8132130, flag=1 '\001',
    err=0xbffff4cc) at NSDocumentController.m:712
#15 0xb7cc066f in -[GSServicesManager application:openFile:] (self=0x81945d8,
    _cmd=0xb7f736b0 <_OBJC_SELECTOR_TABLE+560>, theApp=0x8201128,
    file=0x8126668) at GSServicesManager.m:589
#16 0xb7cc0534 in -[GSServicesManager application:openFiles:] (self=0x81945d8,
    _cmd=0xb7eac128 <_OBJC_SELECTOR_TABLE+1960>, theApp=0x8201128,
    files=0x8160818) at GSServicesManager.m:617
#17 0xb7b2dc31 in -[NSApplication finishLaunching] (self=0x8201128,
    _cmd=0xb7eac218 <_OBJC_SELECTOR_TABLE+2200>) at NSApplication.m:1126
#18 0xb7b3186d in -[NSApplication run] (self=0x8201128,
    _cmd=0xb7ea2408 <_OBJC_SELECTOR_TABLE+904>) at NSApplication.m:1538
#19 0xb7b139bb in NSApplicationMain (argc=2, argv=0xbffff6e4) at Functions.m:91
#20 0x08049857 in main (argc=2, argv=0xbffff6e4) at main.m:24


There's still something fishy.

(gdb) p proposedNewOrigin
$4 = <optimized out>
(gdb) p docRect
$5 = {origin = {x = 4.02598366e-34, y = 424}, size = {width = 471,
    height = 471}}
(gdb) p clipRect
$6 = {origin = {x = 0, y = 0}, size = {width = 471, height = 424}}
(gdb) p newScrollPoint
$7 = {x = <optimized out>, y = 0}
(gdb) fr 2
#2  0xb7b69afb in -[NSClipView setFrame:] (self=0x83960f8,
    _cmd=0x805c978 <_OBJC_SELECTOR_TABLE+888>, rect=...) at NSClipView.m:569
569          [self setBoundsOrigin: [self constrainScrollPoint: _bounds.origin]];
(gdb) po self
 h=-&- v=-&- <CenteringClipView: 0x83960f8> f={x = 0; y = 0; width = 471; height = 424} b={x = 0; y = 0; width = 471; height = 424}
(gdb) p _bounds.origin
No symbol "_bounds" in current context.


Yavor Doganov <yavor>
Thu 24 Jul 2014 09:18:04 PM UTC, comment #15: 

I think I fixed the original GSGormLoading.m bug. Could you please give this a try?

As for the gcc 4.8.3 bug in Vindaloo I did not quite understand the description there. Why do you think that _bounds is undefined in NSClipView setFrame:? I would expect the super call to have set it correctly. Is there something I am missing?


Fred Kiefer <FredKiefer>
Group Member
Thu 24 Jul 2014 10:18:11 AM UTC, comment #14: 

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.
Yavor Doganov <yavor>
Thu 24 Jul 2014 08:39:04 AM UTC, comment #13: 

I think this should be reproducible with GCC 4.8 as well, it's the architecture that matters.  As x86 is gradually being replaced with x86_64 it's not a big surprise that the majority of users do not encounter these bugs.  I'll try to reproduce with older compiler versions.

Yavor Doganov <yavor>
Thu 24 Jul 2014 07:50:37 AM UTC, comment #12: 

Thank you for digging so deep. We need to set up a way to analyze this problem on more machines. I have a look and see whether gcc 4.9 is in some way available for OpenSuse.

The specific issue you ran into seems to be the line in GSGormLoading.m where
_screenRect = [[_object screen] frame];

uses _object instead of obj. I hope to find time to verify and fix that later today or at least tomorrow. The downside is that even with this fixed there will be a next problem and then another. You shouldn't be doing all that hard work alone.

Fred Kiefer <FredKiefer>
Group Member
Thu 24 Jul 2014 12:00:29 AM UTC, comment #11: 

Yes, I used Gorm 1.2.20 + your latest changes.  Most probably it is not an issue with Gorm at all.

I'd really wish to provide more information...  Perhaps I could put breakpoints at some places and step through from there, this would at least give you some clue, as blurry as that may be.  As Gorm is a fairly complex program, I'm trying Vindaloo first.  I already figured out that Vindaloo crashes in -[Document -makeWindowControllers], right after [self addWindowController: ctrl]; ctrl is initalized properly with -initWithWindowNibName: with [self windowNibName] as argument (which returns @"Document").  Stepping from there:

(gdb) n
-[NSDocumentController openDocumentWithContentsOfURL:display:error:] (
    self=0x840c0a8, _cmd=0xb7f73648 <_OBJC_SELECTOR_TABLE+520>, url=0x840ae20,
    flag=1 '\001', err=0xbffff4cc) at NSDocumentController.m:708
708              [self noteNewRecentDocument: document];
(gdb) n
710              if (flag && [self shouldCreateUI])
(gdb) n
712                  [document showWindows];
(gdb)

Program received signal SIGSEGV, Segmentation fault.
0xbfffef8a in ?? ()


Putting breakpoints further:

Breakpoint 2, -[NSDocument showWindows] (self=0x82a1268,
    _cmd=0xb7edd828 <_OBJC_SELECTOR_TABLE+488>) at NSDocument.m:415
415        {
(gdb) po _window_controllers
("<Controller: 0x83e54f8>")
(gdb) n
417                                              withObject: self];
(gdb) n
416          [_window_controllers makeObjectsPerformSelector: @selector(showWindow:)
(gdb) n
417                                              withObject: self];
(gdb) n

Program received signal SIGSEGV, Segmentation fault.
0xbfffef8a in ?? ()
....
Breakpoint 3, -[NSWindowController showWindow:] (
    self=0xb7edb1b8 <_OBJC_SELECTOR_TABLE+504>,
    _cmd=0xb7edb1b8 <_OBJC_SELECTOR_TABLE+504>, sender=0x81fdb90)
    at NSWindowController.m:394
394        {
(gdb) n
395          NSWindow *window = [self window];
(gdb) po self
<Controller: 0x83e73e8>
(gdb) po [self window]

Program received signal SIGSEGV, Segmentation fault.
0xbfffef6a in ?? ()
....
Breakpoint 4, -[NSWindowController window] (self=0x83ea168,
    _cmd=0xb7f680f0 <_OBJC_SELECTOR_TABLE+176>) at NSWindowController.m:297
297        {
(gdb) n
298          if (_window == nil && ![self isWindowLoaded])
(gdb) n
308              [self windowWillLoad];
(gdb) p _window
$5 = (struct NSWindow *) 0x0
(gdb) n
309              if (_owner != self &&
(gdb) po self
<Controller: 0x83ea168>
(gdb) po _owner
<Controller: 0x83ea168>
(gdb) n
315              [self loadWindow];
(gdb) n

Program received signal SIGSEGV, Segmentation fault.
....
Breakpoint 5, -[NSWindowController loadWindow] (self=0x83e5340,
    _cmd=0xb7f68170 <_OBJC_SELECTOR_TABLE+304>) at NSWindowController.m:476
476        {
(gdb) n
479          if ([self isWindowLoaded])
(gdb) n
484          table = [NSDictionary dictionaryWithObject: _owner forKey: NSNibOwner];
(gdb) po table
value has been optimized out
(gdb) n
485          if ([NSBundle loadNibFile: [self windowNibPath]
(gdb) po self
<Controller: 0x83e5340>
(gdb) po [self windowNibPath]
/home/yavor/scratch/viewpdf.app-0.2dfsg1/ViewPDF.app/Resources/English.lproj/Document.gorm
(gdb) po _owner
<Controller: 0x83e5340>
(gdb) n
487                        withZone: [_owner zone]])
(gdb) n
485          if ([NSBundle loadNibFile: [self windowNibPath]
(gdb) n
487                        withZone: [_owner zone]])
(gdb) n

Program received signal SIGSEGV, Segmentation fault.
0xbfffef8a in ?? ()
....
Breakpoint 6, +[NSBundle(NSBundleAdditions) loadNibFile:externalNameTable:withZone:] (self=0xb79d43e0 <_OBJC_Class_NSBundle>,
    _cmd=0xb7f68250 <_OBJC_SELECTOR_TABLE+528>, fileName=0x8268c18,
    context=0x8267fe0, zone=0xb7a3f0c0 <default_zone>)
    at NSBundleAdditions.m:234
234        {
(gdb) n
235          NSNib *nib = [[NSNib alloc] initWithContentsOfURL: [NSURL fileURLWithPath: fileName]];
(gdb) po fileName
/home/yavor/scratch/viewpdf.app-0.2dfsg1/ViewPDF.app/Resources/English.lproj/Document.gorm
(gdb) po [NSURL fileURLWithPath: fileName]
file://localhost/home/yavor/scratch/viewpdf.app-0.2dfsg1/ViewPDF.app/Resources/English.lproj/Document.gorm/
(gdb) po context
{NSOwner = "<Controller: 0x83e5568>"; }
(gdb) n
237                                                        withZone: zone];
(gdb) po nib
value has been optimized out
(gdb) n
235          NSNib *nib = [[NSNib alloc] initWithContentsOfURL: [NSURL fileURLWithPath: fileName]];
(gdb) n
239          RELEASE(nib);
(gdb) n
235          NSNib *nib = [[NSNib alloc] initWithContentsOfURL: [NSURL fileURLWithPath: fileName]];
(gdb) n
237                                                        withZone: zone];
(gdb) n
236          BOOL loaded = [nib instantiateNibWithExternalNameTable: context
(gdb) n

Program received signal SIGSEGV, Segmentation fault.
0xbfffef8a in ?? ()
....
Breakpoint 7, -[NSNib instantiateNibWithExternalNameTable:withZone:] (
    self=0x8411090, _cmd=0xb7ebc0d0 <_OBJC_SELECTOR_TABLE+208>,
    externalNameTable=0x8410c28, zone=0xb7a3f0c0 <default_zone>) at NSNib.m:152
152        {
(gdb) n
155                          withZone: zone];
(gdb) po _loader
<GSGormLoader: 0x84116c0>
(gdb) po _nibData
<474e5573 74657020 61726368 69766530 30303032 6166393a 30303030 30303135 3a303030 30303032 303a3030 30303030 30303a30 01310100 0e47534e 6962436f 6e746169 6e657200 00000131 0200084e 534f626a 65637400 00000000 30023103 00134e53 4d757461 626c6544 69637469 6f6e6172 79000000 00310400 ...(skipped)>
(gdb) po externalNameTable
{NSOwner = "<Controller: 0x83e55c8>"; }
(gdb) n
153          return [_loader loadModelData: _nibData
(gdb) n
155                          withZone: zone];
(gdb) n
153          return [_loader loadModelData: _nibData
(gdb) n

Program received signal SIGSEGV, Segmentation fault.
0xbfffef8a in ?? ()
....
Breakpoint 8, -[GSGormLoader loadModelData:externalNameTable:withZone:] (
    self=0x83df480, _cmd=0xb7f09cb0 <_OBJC_SELECTOR_TABLE+112>,
    data=0x83dfbc8, context=0x83de9d0, zone=0xb7a3f0c0 <default_zone>)
    at GSGormLoader.m:98
98        {
(gdb) n
104              if (data != nil)
(gdb) n
106                  unarchiver = [[NSUnarchiver alloc]
(gdb) n
107                                 initForReadingWithData: data];
(gdb) n
106                  unarchiver = [[NSUnarchiver alloc]
(gdb) n
107                                 initForReadingWithData: data];
(gdb) n
106                  unarchiver = [[NSUnarchiver alloc]
(gdb)
108                  if (unarchiver != nil)
(gdb)
106                  unarchiver = [[NSUnarchiver alloc]
(gdb)
108                  if (unarchiver != nil)
108                  if (unarchiver != nil)
(gdb)
112                      NSDebugLog(@"Invoking unarchiver");
(gdb)
113                      [unarchiver setObjectZone: zone];
(gdb)
114                      obj = [unarchiver decodeObject];
(gdb)
113                      [unarchiver setObjectZone: zone];
(gdb)
114                      obj = [unarchiver decodeObject];
(gdb)

Program received signal SIGSEGV, Segmentation fault.
0xbfffef8a in ?? ()


I put a break on -[NSCoder decodeObject] here and there's a lot of stepping as all the objects get decoded.  Then,

-[GSWindowTemplate initWithCoder:] (self=0x83e7bc0,
    _cmd=0xb7a29268 <_OBJC_SELECTOR_TABLE+232>, coder=0x84118f8)
    at GSGormLoading.m:879
879          if (obj != nil)
(gdb)
878          id obj = [super initWithCoder: coder];
(gdb)
879          if (obj != nil)
(gdb)
881              int version = [coder versionForClassName: @"GSWindowTemplate"];
(gdb)
883              if (version == GSWINDOWT_VERSION)
(gdb)
890              else if (version == 0)
(gdb)
893                  [coder decodeValueOfObjCType: @encode(BOOL) at: &_deferFlag];
(gdb)
894                  _autoPositionMask = GSWindowAutoPositionNone;
(gdb)
895                  _screenRect = [[_object screen] frame];
(gdb)

Program received signal SIGSEGV, Segmentation fault.
0xbfffef8a in ?? ()


I restart the program putting another break here.  Trying to dereference _object results in "No symbol "_object" in current context" so sending a message to _object expectedly ends with a crash at runtime level.  FYI the value of obj there is "<DocumentWindow: 0x83e9ab8>Number: 6 Title: Window".

This is with GUI 0.24.0 + your change from bug #42717 cherry-picked; built with --disable-imagemagick and default optimization (-O2) on i386 (x86).  GCC 4.9.1, GCC runtime.

Yavor Doganov <yavor>
Wed 23 Jul 2014 08:44:26 PM UTC, comment #10: 

I would expect that this new crash comes from a different place then before. The question is how we could find out where, given that gdb and valgrind don't give meaningful results.

It would be great, if you had a bit more information.

BTW, did you update Gorm to get the change I made there?

Fred Kiefer <FredKiefer>
Group Member
Wed 23 Jul 2014 04:23:59 PM UTC, comment #9: 

FYI, the bug is reproducible if I rebuild GUI with --disable-imagemagick (the image file types are just "tiff, tif, pnm, ppm, gif, jpeg, jpg, png, icns" in that case).  The gdb backtrace is meaningless again and the valgrind output is:

==8543== Command: Gorm ./English.lproj/Document.gorm/
==8543==
vex x86->IR: unhandled instruction bytes: 0x6D 0x7 0x8 0xC7
==8543== Invalid write of size 1
==8543==    at 0xBEB7BF4A: ???
==8543==  Address 0x75b99204 is not stack'd, malloc'd or (recently) free'd
==8543==
==8543==
==8543== Process terminating with default action of signal 11 (SIGSEGV)
==8543==  Access not within mapped region at address 0x75B99204
==8543==    at 0xBEB7BF4A: ???


Yavor Doganov <yavor>
Wed 23 Jul 2014 03:52:49 PM UTC, comment #8: 

Yes, the "info" type is there and the array is quite large:

(gdb) po [NSImage imageFileTypes]
(tiff, tif, pnm, ppm, gif, jpeg, jpg, png, icns, 3fr, a, aai, ai, art, arw, avi, avs, b, bgr, bgra, bie, bmp, bmp2, bmp3, brf, c, cal, cals, canvas, caption, cin, cip, clip, cmyk, cmyka, cr2, crw, cur, cut, dcm, dcr, dcx, dds, dfont, djvu, dng, dot, dpx, epdf, epi, eps, eps2, eps3, epsf, epsi, ept, ept2, ept3, erf, exr, fax, fits, fractal, fts, g, g3, gif87, gradient, gray, group4, hald, hdr, histogram, hrz, htm, html, icb, ico, icon, info, inline, ipl, isobrl, j2c, j2k, jbg, jbig, jng, jp2, jpc, jpx, k, k25, kdc, label, m, m2v, m4v, mac, map, mat, matte, mef, miff, mng, mono, mov, mp4, mpc, mpeg, mpg, mrw, msl, msvg, mtv, mvg, nef, nrw, null, o, orf, otb, otf, pal, palm, pam, pango, pattern, pbm, pcd, pcds, pcl, pct, pcx, pdb, pdf, pdfa, pef, pes, pfa, pfb, pfm, pgm, pgx, picon, pict, pix, pjpeg, plasma, png24, png32, png8, preview, ps, ps2, ps3, psb, psd, ptif, pwp, r, "radial-gradient", raf, ras, rgb, rgba, rgbo, rla, rle, scr, sct, sfw, sgi, shtml, sr2, srf, stegano, sun, svg, svgz, text, tga, thumbnail, tiff64, tile, tim, ttc, ttf, txt, ubrl, uil, uyvy, vda, vicar, vid, viff, vst, wbmp, wmf, wmv, wmz, wpg, x, x3f, xbm, xc, xcf, xpm, xps, xv, xwd, y, ycbcr, ycbcra, yuv)


Apparently these extra types come from GSImageMagickImageRep; I get them on amd64 too.

Yavor Doganov <yavor>
Wed 23 Jul 2014 08:04:44 AM UTC, comment #7: 

I am no expert on Gorm, but this looks very strange to me. If I understand the code in GormWrapperLoader loadFileWrapper:withDocument:] correctly this tries to load everything in the .gorm directory that looks like an image with GormImage. Now why would it try to load the "data.info" file as an image? Could you please print out the value of [NSImage imageFileTypes] and if this includes "info" try to find out where this comes from?

I changed the category of this bug to Gorm to bring it to the attention of Gregory. We might need to change it back again when we find out more.

Fred Kiefer <FredKiefer>
Group Member
Mon 21 Jul 2014 08:03:36 AM UTC, comment #6: 

Gorm doesn't crash now but it doesn't load the file either.  An alert panel is shown with title "Alert" and "No information" as message.  The "image" file is, oddly enough, data.info.  Here's the backtrace when this method is reached:

Breakpoint 1, -[GormImage initWithData:withFileName:inWrapper:] (
    self=0x9010440, _cmd=0xb7fae9a0 <_OBJC_SELECTOR_TABLE+32>,
    aData=0x81a0498, aName=0x9028d60, flag=1 '\001') at GormImage.m:84
84                      [smallImage setSize: NSMakeSize(70, originalSize.height / ratioW)];
(gdb) po aName
data.info
(gdb) bt
#0  -[GormImage initWithData:withFileName:inWrapper:] (self=0x9010440,
    _cmd=0xb7fae9a0 <_OBJC_SELECTOR_TABLE+32>, aData=0x81a0498,
    aName=0x9028d60, flag=1 '\001') at GormImage.m:84
#1  0xb7f15136 in +[GormImage imageForData:withFileName:inWrapper:] (
    self=0xb7faea60 <_OBJC_Class_GormImage>,
    _cmd=0xb7fd9238 <_OBJC_SELECTOR_TABLE+952>, aData=0x81a0498,
    aName=0x9028d60, flag=1 '\001') at GormImage.m:56
#2  0xb7f46a2b in -[GormWrapperLoader loadFileWrapper:withDocument:] (
    self=0x8b1b310, _cmd=0xb2c26980 <_OBJC_SELECTOR_TABLE+1216>,
    wrapper=0x9082728, doc=0x8544568) at GormWrapperLoader.m:87
#3  0xb2c1fd2f in -[GormGormWrapperLoader loadFileWrapper:withDocument:] (
    self=0x8b1b310, _cmd=0xb7fa4208 <_OBJC_SELECTOR_TABLE+3336>,
    wrapper=0x9082728, doc=0x8544568) at GormGormWrapperLoader.m:361
#4  0xb7f071eb in -[GormDocument loadFileWrapperRepresentation:ofType:] (
    self=0x8544568, _cmd=0xb7dc22b8 <_OBJC_SELECTOR_TABLE+696>,
    wrapper=0x9082728, type=0x8143480) at GormDocument.m:3373
#5  0xb7a7782f in -[NSDocument readFromFileWrapper:ofType:error:] (
    self=0x8544568, _cmd=0xb7dc22d0 <_OBJC_SELECTOR_TABLE+720>,
    wrapper=0x9082728, type=0x8143480, error=0xbffff53c) at NSDocument.m:723
#6  0xb7a77768 in -[NSDocument readFromURL:ofType:error:] (self=0x8544568,
    _cmd=0xb7dc20b8 <_OBJC_SELECTOR_TABLE+184>, url=0x9082728, type=0x8143480,
    error=0xbffff53c) at NSDocument.m:757
#7  0xb7a78d41 in -[NSDocument initForURL:withContentsOfURL:ofType:error:] (
    self=0x8544568, _cmd=0xb7dc2108 <_OBJC_SELECTOR_TABLE+264>,
    forUrl=0x99d4120, url=0x99d4120, type=0x8143480, error=0xbffff53c)
    at NSDocument.m:163
#8  0xb7a78bf5 in -[NSDocument initWithContentsOfURL:ofType:error:] (
    self=0x8544568, _cmd=0xb7dc4800 <_OBJC_SELECTOR_TABLE+384>, url=0x99d4120,
    type=0x8143480, error=0xbffff53c) at NSDocument.m:189
#9  0xb7a7d222 in -[NSDocumentController makeDocumentWithContentsOfURL:ofType:error:] (self=0x8544568, _cmd=0xb7dc48d8 <_OBJC_SELECTOR_TABLE+600>,
    url=0x99d4120, type=0x8143480, err=0xbffff53c)
    at NSDocumentController.m:446
#10 0xb7a7c76c in -[NSDocumentController openDocumentWithContentsOfURL:display:error:] (self=0x8831348, _cmd=0xb7e5a688 <_OBJC_SELECTOR_TABLE+520>,
    url=0x99d4120, flag=1 '\001', err=0xbffff53c) at NSDocumentController.m:690
#11 0xb7ba748f in -[GSServicesManager application:openFile:] (self=0x81ca890,
    _cmd=0xb7e5a6b0 <_OBJC_SELECTOR_TABLE+560>, theApp=0x81f6ee8,
    file=0x811b3c8) at GSServicesManager.m:589
#12 0xb7ba7354 in -[GSServicesManager application:openFiles:] (self=0x81ca890,
    _cmd=0xb7d93128 <_OBJC_SELECTOR_TABLE+1960>, theApp=0x81f6ee8,
    files=0x816e008) at GSServicesManager.m:617
#13 0xb7a14c31 in -[NSApplication finishLaunching] (self=0x81f6ee8,
    _cmd=0xb7d93218 <_OBJC_SELECTOR_TABLE+2200>) at NSApplication.m:1126
#14 0xb7a1886d in -[NSApplication run] (self=0x81f6ee8,
    _cmd=0xb7d89408 <_OBJC_SELECTOR_TABLE+904>) at NSApplication.m:1538
#15 0xb79fa9bb in NSApplicationMain (argc=2, argv=0xbffff754) at Functions.m:91
#16 0x08049327 in main (argc=2, argv=0xbffff754) at main.m:30


Yavor Doganov <yavor>
Mon 21 Jul 2014 07:29:07 AM UTC, comment #5: 

This looks like the image loadign is failing for you and then Gorm tries to use the nil value to extract the size of the image. Because of a compiler bug this then results in a segmentation fault.
In the second init... method there was already a check for that case. I added one in that method as well and cleaned up the code a bit. Please update SVN and give it another try.

The more interesting question here is why does the image loading fail. Or the even more basic one, which image is it trying to load? I could not find one in the gorm file you attached to this bug report. And in gdb I don't see Gorm calling this method at all when loading your Gorm file.
For this reason I leave this bug in the open state.

Fred Kiefer <FredKiefer>
Group Member
Sun 20 Jul 2014 04:32:39 PM UTC, comment #4: 


==15741== Command: Gorm /tmp/viewpdf.app-0.2dfsg1/English.lproj/Document.gorm/
==15741==
2014-07-20 19:27:38.764 Gorm[15741] Tiff Error (GSTiffReadData) Not a TIFF or MDI file, bad magic number 20039 (0x4e47)
2014-07-20 19:27:42.187 Gorm[15741] Tiff Error (GSTiffReadData) Not a TIFF or MDI file, bad magic number 20039 (0x4e47)
==15741== Conditional jump or move depends on uninitialised value(s)
==15741==    at 0x408C385: _i_GormImage__initWithData_withFileName_inWrapper_ (in /usr/lib/gorm.app/libGormCore.so.1.2.20)
==15741==    by 0xB3A875F: ???
==15741==
vex x86->IR: unhandled instruction bytes: 0xF0 0x5A 0x3A 0xB
==15741== Use of uninitialised value of size 4
==15741==    at 0xB3A8762: ???
==15741==
==15741== Invalid read of size 1
==15741==    at 0xB3A8762: ???
==15741==  Address 0x134c0a52 is not stack'd, malloc'd or (recently) free'd
==15741==
==15741==
==15741== Process terminating with default action of signal 11 (SIGSEGV)
==15741==  Access not within mapped region at address 0x134C0A52
==15741==    at 0xB3A8762: ???
==15741==  If you believe this happened as a result of a stack
==15741==  overflow in your program's main thread (unlikely but
==15741==  possible), you can try to increase the size of the
==15741==  main thread stack using the --main-stacksize= flag.
==15741==  The main thread stack size used in this run was 8388608.
==15741==
==15741== HEAP SUMMARY:
==15741==     in use at exit: 9,972,293 bytes in 71,858 blocks
==15741==   total heap usage: 1,228,610 allocs, 1,156,752 frees, 105,972,400 bytes allocated
==15741==
==15741== LEAK SUMMARY:
==15741==    definitely lost: 37,671 bytes in 1,025 blocks
==15741==    indirectly lost: 62,465 bytes in 4,126 blocks
==15741==      possibly lost: 6,784,244 bytes in 27,296 blocks
==15741==    still reachable: 3,087,913 bytes in 39,411 blocks
==15741==         suppressed: 0 bytes in 0 blocks
==15741== Rerun with --leak-check=full to see details of leaked memory
==15741==
==15741== For counts of detected and suppressed errors, rerun with: -v
==15741== Use --track-origins=yes to see where uninitialised values come from
==15741== ERROR SUMMARY: 3 errors from 3 contexts (suppressed: 1 from 1)
Нарушение на разделянето(segfault)


Yavor Doganov <yavor>
Sat 19 Jul 2014 03:46:28 PM UTC, comment #3: 

Could you please re-run this test with valgrind? Don't look at the leak reports or what ever valgind might generate fpr you. In this specific case we are only interesting in unitialized variables that the code might be accessing. Valgrind shoul dbe able to report these even without any additional parameters.

Fred Kiefer <FredKiefer>
Group Member
Wed 16 Jul 2014 05:53:25 PM UTC, comment #2: 

GNUstep Base is built with detached debugging symbols and the -dbg package is installed.  The stack gets seriously messed up or destroyed.

Yavor Doganov <yavor>
Wed 16 Jul 2014 05:42:57 PM UTC, comment #1: 

Not that I may help much with the issue, but it seems, gnustep-base is built without debug symbols and stripped.

Do you can re-build/re-install it, run something similar to:

make clean && make debug=yes strip=no && sudo make install

Then the backtrace should be a bit more helpful.


Sebastian Reitenbach <buzzdee>
Group Member
Wed 16 Jul 2014 12:22:11 PM UTC, original submission:  

Yet another mysterious bug like bug #42717.  Both Vindaloo and Gorm crash on x86 when loading the attached gorm file.  If I rebuild GUI (0.24.0) without optimization there is no problem.  Needless to say, this worked pretty well with old GNUstep releases.

The backtrace is completely meaningless:

Program received signal SIGSEGV, Segmentation fault.
0xbfffedca in ?? ()
(gdb) bt
#0  0xbfffedca in ?? ()
#1  0xb7a27960 in ?? () from /usr/lib/libgnustep-base.so.1.24
Backtrace stopped: previous frame inner to this frame (corrupt stack?)


Cannot be reproduced on x86_64.

Yavor Doganov <yavor>

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach Files:
   
   
Comment:
   

Attached Files
file #31728:  Document.gorm.tar.gz added by yavor (1KiB - application/x-gzip)

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by gcasa (Posted a comment)
  • -email is unavailable- added by FredKiefer (Posted a comment)
  • -email is unavailable- added by buzzdee (Posted a comment)
  • -email is unavailable- added by yavor (Submitted the item)
  •  

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

    Only logged-in users can vote.

     

    Follow 12 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2014-11-10 FredKiefer StatusIn Progress Fixed
        Open/ClosedOpen Closed
    2014-07-26 FredKiefer CategoryGui/AppKit Gorm
        StatusReady For Test In Progress
        Open/ClosedIn Test Open
    2014-07-24 FredKiefer StatusIn Progress Ready For Test
        Open/ClosedOpen In Test
    2014-07-24 FredKiefer CategoryGorm Gui/AppKit
        Assigned toNone FredKiefer
    2014-07-23 FredKiefer CategoryGui/AppKit Gorm
        StatusNone In Progress
    2014-07-16 yavor Attached File- Added Document.gorm.tar.gz, #31728

    Back to the top

    Powered by Savane 3.13-f8d8.
    Corresponding source code