[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

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 wrote: > Follow-up Comment #21, bug #42782 (project gnustep): > > > The issues comes from the fact that there is a file

[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

[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

[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 _

[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 u

[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

[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 Vi

[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

[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 th

[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 b

[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

[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 digg

[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 g

[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

[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==

[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, ca

[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 G

[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

[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

[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]

[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 d

[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:

[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 b

[bug #42782] Crash when loading a gorm file

URL: 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 - Norm