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


You are not allowed to post comments on this tracker with your current authentication level.

bug #42782: Crash when loading a gorm file

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

( 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>
Project MemberIn charge of this item.
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.


Gregory John Casamento <gcasa>
Project 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:

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>
Project MemberIn charge of this item.
Fri 25 Jul 2014 07:40:32 AM UTC, comment #17:

Valgrind output:

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:

There's still something fishy.

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>
Project MemberIn charge of this item.
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:

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>
Project MemberIn charge of this item.
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:

Putting breakpoints further:

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

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>
Project MemberIn charge of this item.
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:

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:

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>
Project MemberIn charge of this item.
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:

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>
Project MemberIn charge of this item.
Sun 20 Jul 2014 04:32:39 PM UTC, comment #4:
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>
Project MemberIn charge of this item.
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>
Project 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:

Cannot be reproduced on x86_64.

Yavor Doganov <yavor>


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)

    Do you think this task is very important?
    If so, you can add your encouragement to it.
    This task has 0 encouragements so far.

    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.3