[bug #42782] Crash when loading a gorm file
Update of bug #42782 (project gnustep): Status: In Progress = Fixed Open/Closed:Open = Closed ___ Follow-up Comment #22: Closed on request of original author. ___ Reply to this item at: http://savannah.gnu.org/bugs/?42782 ___ Nachricht gesendet von/durch Savannah http://savannah.gnu.org/ ___ Bug-gnustep mailing list Bug-gnustep@gnu.org https://lists.gnu.org/mailman/listinfo/bug-gnustep
[bug #42782] Crash when loading a gorm file
Follow-up Comment #21, bug #42782 (project gnustep): 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. ___ Reply to this item at: http://savannah.gnu.org/bugs/?42782 ___ Message sent via/by Savannah http://savannah.gnu.org/ ___ Bug-gnustep mailing list Bug-gnustep@gnu.org https://lists.gnu.org/mailman/listinfo/bug-gnustep
Re: [bug #42782] Crash when loading a gorm file
We should separate each of the issues out into separate reports. It's difficult to track issues when they are combined like this. On Saturday, November 1, 2014, Yavor Doganov invalid.nore...@gnu.org wrote: Follow-up Comment #21, bug #42782 (project gnustep): 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. ___ Reply to this item at: http://savannah.gnu.org/bugs/?42782 ___ Message sent via/by Savannah http://savannah.gnu.org/ -- Gregory Casamento Open Logic Corporation, Principal Consultant (240)274-9630 (Cell) http://www.gnustep.org http://heronsperch.blogspot.com ___ Bug-gnustep mailing list Bug-gnustep@gnu.org https://lists.gnu.org/mailman/listinfo/bug-gnustep
[bug #42782] Crash when loading a gorm file
Follow-up Comment #20, bug #42782 (project gnustep): 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 ___ Reply to this item at: http://savannah.gnu.org/bugs/?42782 ___ Message sent via/by Savannah http://savannah.gnu.org/ ___ Bug-gnustep mailing list Bug-gnustep@gnu.org https://lists.gnu.org/mailman/listinfo/bug-gnustep
[bug #42782] Crash when loading a gorm file
Update of bug #42782 (project gnustep): Category: Gui/AppKit = Gorm Status: Ready For Test = In Progress Open/Closed: In Test = Open ___ Reply to this item at: http://savannah.gnu.org/bugs/?42782 ___ Nachricht gesendet von/durch Savannah http://savannah.gnu.org/ ___ Bug-gnustep mailing list Bug-gnustep@gnu.org https://lists.gnu.org/mailman/listinfo/bug-gnustep
[bug #42782] Crash when loading a gorm file
Follow-up Comment #16, bug #42782 (project gnustep):
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=0xb0b8,
_cmd=0x83960f8, proposedNewOrigin=...) at CenteringClipView.m:83
83 return newScrollPoint;
(gdb) bt
#0 0x08049d24 in -[CenteringClipView constrainScrollPoint:] (self=0xb0b8,
_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 ' 01',
err=0xb4cc) 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=0xb6e4) at
Functions.m:91
#20 0x08049857 in main (argc=2, argv=0xb6e4) 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.
___
Reply to this item at:
http://savannah.gnu.org/bugs/?42782
___
Message sent via/by Savannah
http://savannah.gnu.org/
___
Bug-gnustep mailing list
[bug #42782] Crash when loading a gorm file
Follow-up Comment #17, bug #42782 (project gnustep): 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 s05l.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 d05l.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/s05l.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/d05l.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== ___ Reply to this item at: http://savannah.gnu.org/bugs/?42782 ___
[bug #42782] Crash when loading a gorm file
Follow-up Comment #18, bug #42782 (project gnustep): 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. ___ Reply to this item at: http://savannah.gnu.org/bugs/?42782 ___ Nachricht gesendet von/durch Savannah http://savannah.gnu.org/ ___ Bug-gnustep mailing list Bug-gnustep@gnu.org https://lists.gnu.org/mailman/listinfo/bug-gnustep
[bug #42782] Crash when loading a gorm file
Follow-up Comment #19, bug #42782 (project gnustep): 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. ___ Reply to this item at: http://savannah.gnu.org/bugs/?42782 ___ Message sent via/by Savannah http://savannah.gnu.org/ ___ Bug-gnustep mailing list Bug-gnustep@gnu.org https://lists.gnu.org/mailman/listinfo/bug-gnustep
[bug #42782] Crash when loading a gorm file
Update of bug #42782 (project gnustep): Category:Gorm = Gui/AppKit Assigned to:None = FredKiefer ___ Follow-up 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. ___ Reply to this item at: http://savannah.gnu.org/bugs/?42782 ___ Nachricht gesendet von/durch Savannah http://savannah.gnu.org/ ___ Bug-gnustep mailing list Bug-gnustep@gnu.org https://lists.gnu.org/mailman/listinfo/bug-gnustep
[bug #42782] Crash when loading a gorm file
Follow-up Comment #13, bug #42782 (project gnustep): 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. ___ Reply to this item at: http://savannah.gnu.org/bugs/?42782 ___ Message sent via/by Savannah http://savannah.gnu.org/ ___ Bug-gnustep mailing list Bug-gnustep@gnu.org https://lists.gnu.org/mailman/listinfo/bug-gnustep
[bug #42782] Crash when loading a gorm file
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=0xb088, _cmd=0x83e7600, proposedNewOrigin=...) at CenteringClipView.m:82 82 return newScrollPoint; (gdb) bt #0 0x0804bb34 in -[CenteringClipView constrainScrollPoint:] (self=0xb088, _cmd=0x83e7600, proposedNewOrigin=...) at CenteringClipView.m:82 #1 0xb0b8 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/ ___ Bug-gnustep mailing list Bug-gnustep@gnu.org https://lists.gnu.org/mailman/listinfo/bug-gnustep
[bug #42782] Crash when loading a gorm file
Update of bug #42782 (project gnustep): Status: In Progress = Ready For Test Open/Closed:Open = In Test ___ Follow-up 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? ___ Reply to this item at: http://savannah.gnu.org/bugs/?42782 ___ Nachricht gesendet von/durch Savannah http://savannah.gnu.org/ ___ Bug-gnustep mailing list Bug-gnustep@gnu.org https://lists.gnu.org/mailman/listinfo/bug-gnustep
[bug #42782] Crash when loading a gorm file
Update of bug #42782 (project gnustep): Category: Gui/AppKit = Gorm Status:None = In Progress ___ Follow-up 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. ___ Reply to this item at: http://savannah.gnu.org/bugs/?42782 ___ Nachricht gesendet von/durch Savannah http://savannah.gnu.org/ ___ Bug-gnustep mailing list Bug-gnustep@gnu.org https://lists.gnu.org/mailman/listinfo/bug-gnustep
[bug #42782] Crash when loading a gorm file
Follow-up Comment #8, bug #42782 (project gnustep): 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. ___ Reply to this item at: http://savannah.gnu.org/bugs/?42782 ___ Message sent via/by Savannah http://savannah.gnu.org/ ___ Bug-gnustep mailing list Bug-gnustep@gnu.org https://lists.gnu.org/mailman/listinfo/bug-gnustep
[bug #42782] Crash when loading a gorm file
Follow-up Comment #9, bug #42782 (project gnustep): 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: ??? ___ Reply to this item at: http://savannah.gnu.org/bugs/?42782 ___ Message sent via/by Savannah http://savannah.gnu.org/ ___ Bug-gnustep mailing list Bug-gnustep@gnu.org https://lists.gnu.org/mailman/listinfo/bug-gnustep
[bug #42782] Crash when loading a gorm file
Follow-up Comment #10, bug #42782 (project gnustep): 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? ___ Reply to this item at: http://savannah.gnu.org/bugs/?42782 ___ Nachricht gesendet von/durch Savannah http://savannah.gnu.org/ ___ Bug-gnustep mailing list Bug-gnustep@gnu.org https://lists.gnu.org/mailman/listinfo/bug-gnustep
[bug #42782] Crash when loading a gorm file
Follow-up Comment #11, bug #42782 (project gnustep):
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 ' 01', err=0xb4cc) 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
[bug #42782] Crash when loading a gorm file
Follow-up Comment #5, bug #42782 (project gnustep): 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. ___ Reply to this item at: http://savannah.gnu.org/bugs/?42782 ___ Nachricht gesendet von/durch Savannah http://savannah.gnu.org/ ___ Bug-gnustep mailing list Bug-gnustep@gnu.org https://lists.gnu.org/mailman/listinfo/bug-gnustep
[bug #42782] Crash when loading a gorm file
Follow-up Comment #6, bug #42782 (project gnustep): 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 ' 01') 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 ' 01') 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 ' 01') 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=0xb53c) at NSDocument.m:723 #6 0xb7a77768 in -[NSDocument readFromURL:ofType:error:] (self=0x8544568, _cmd=0xb7dc20b8 _OBJC_SELECTOR_TABLE+184, url=0x9082728, type=0x8143480, error=0xb53c) 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=0xb53c) at NSDocument.m:163 #8 0xb7a78bf5 in -[NSDocument initWithContentsOfURL:ofType:error:] ( self=0x8544568, _cmd=0xb7dc4800 _OBJC_SELECTOR_TABLE+384, url=0x99d4120, type=0x8143480, error=0xb53c) at NSDocument.m:189 #9 0xb7a7d222 in -[NSDocumentController makeDocumentWithContentsOfURL:ofType:error:] (self=0x8544568, _cmd=0xb7dc48d8 _OBJC_SELECTOR_TABLE+600, url=0x99d4120, type=0x8143480, err=0xb53c) at NSDocumentController.m:446 #10 0xb7a7c76c in -[NSDocumentController openDocumentWithContentsOfURL:display:error:] (self=0x8831348, _cmd=0xb7e5a688 _OBJC_SELECTOR_TABLE+520, url=0x99d4120, flag=1 ' 01', err=0xb53c) 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=0xb754) at Functions.m:91 #16 0x08049327 in main (argc=2, argv=0xb754) at main.m:30 ___ Reply to this item at: http://savannah.gnu.org/bugs/?42782 ___ Message sent via/by Savannah http://savannah.gnu.org/ ___ Bug-gnustep mailing list Bug-gnustep@gnu.org https://lists.gnu.org/mailman/listinfo/bug-gnustep
[bug #42782] Crash when loading a gorm file
Follow-up Comment #4, bug #42782 (project gnustep): ==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) ___ Reply to this item at: http://savannah.gnu.org/bugs/?42782 ___ Message sent via/by Savannah http://savannah.gnu.org/ ___ Bug-gnustep mailing list Bug-gnustep@gnu.org https://lists.gnu.org/mailman/listinfo/bug-gnustep
[bug #42782] Crash when loading a gorm file
Follow-up Comment #3, bug #42782 (project gnustep): 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. ___ Reply to this item at: http://savannah.gnu.org/bugs/?42782 ___ Nachricht gesendet von/durch Savannah http://savannah.gnu.org/ ___ Bug-gnustep mailing list Bug-gnustep@gnu.org https://lists.gnu.org/mailman/listinfo/bug-gnustep
[bug #42782] Crash when loading a gorm file
URL: http://savannah.gnu.org/bugs/?42782 Summary: Crash when loading a gorm file Project: GNUstep Submitted by: yavor Submitted on: Wed 16 Jul 2014 03:22:11 PM EEST Category: Gui/AppKit Severity: 3 - Normal Item Group: Bug Status: None Privacy: Public Assigned to: None Open/Closed: Open Discussion Lock: Any ___ Details: 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. ___ File Attachments: --- Date: Wed 16 Jul 2014 03:22:11 PM EEST Name: Document.gorm.tar.gz Size: 1kB By: yavor http://savannah.gnu.org/bugs/download.php?file_id=31728 ___ Reply to this item at: http://savannah.gnu.org/bugs/?42782 ___ Message sent via/by Savannah http://savannah.gnu.org/ ___ Bug-gnustep mailing list Bug-gnustep@gnu.org https://lists.gnu.org/mailman/listinfo/bug-gnustep
[bug #42782] Crash when loading a gorm file
Follow-up Comment #1, bug #42782 (project gnustep): 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. ___ Reply to this item at: http://savannah.gnu.org/bugs/?42782 ___ Message sent via/by Savannah http://savannah.gnu.org/ ___ Bug-gnustep mailing list Bug-gnustep@gnu.org https://lists.gnu.org/mailman/listinfo/bug-gnustep
[bug #42782] Crash when loading a gorm file
Follow-up Comment #2, bug #42782 (project gnustep): GNUstep Base is built with detached debugging symbols and the -dbg package is installed. The stack gets seriously messed up or destroyed. ___ Reply to this item at: http://savannah.gnu.org/bugs/?42782 ___ Message sent via/by Savannah http://savannah.gnu.org/ ___ Bug-gnustep mailing list Bug-gnustep@gnu.org https://lists.gnu.org/mailman/listinfo/bug-gnustep
