bugGNUstep - Bugs: bug #15178, Gorm crashes on exit if opening a...

Group
 
 

bug #15178: Gorm crashes on exit if opening a .gorm file directly from the commandline

Submitter:  Nikolaus Waxweiler <madleser>
Submitted:  Fri 09 Dec 2005 09:13:16 PM UTC
   
 
Category:  Gorm Severity:  3 - Normal
Item Group:  Bug Status:  Fixed
Privacy:  Public Assigned to:  gcasa
Open/Closed:  Closed
* Mandatory Fields

Add a New Comment Rich Markup
   

Jump to the original submission

Mon 02 Jan 2006 07:36:38 PM UTC, comment #12: 

Argh.

'openapp Gorm -GSFilePath ~/Entwicklung/objc/Calendar/Resources/Calendar.gorm' -> "NSInvalidArgumentException: GormDocument(class) does not recognize readableTypes." -> Abort.

This one is mystifying me.. the compiler doesn't complain and readableTypes is a class method, so why isn't it recognized?

Nikolaus Waxweiler <madleser>
Sun 18 Dec 2005 01:17:36 PM UTC, comment #11: 

Originally submitter tested and found it working.

Gregory John Casamento <gcasa>
Group administrator
Sun 18 Dec 2005 10:05:51 AM UTC, comment #10: 

Works. :)

Nikolaus Waxweiler <madleser>
Sat 17 Dec 2005 02:24:01 PM UTC, comment #9: 

Made a further correction in CVS.  Try it again please.

Gregory John Casamento <gcasa>
Group administrator
Thu 15 Dec 2005 04:44:20 PM UTC, comment #8: 

You forgot that 'objects.gorm' is also a gorm file -- it still crashes with that. Yes, it's an obscure bordercase nobody else is going to stumble over but it would be nice to have it fixed anyway.

Nikolaus Waxweiler <madleser>
Thu 15 Dec 2005 03:11:42 AM UTC, comment #7: 

Good catch on this one.  The problem stemmed from the fact that the document was being allocated and loadDocument called on the instance.   When the unarchiver crashed (because the file isn't a gorm file) the state of the document object is inconsistent.

The solution was to externalize the check (as is done with NSDocument) and not to instantiate a document object, unless the type of file passed in warrents it.

Please test the version in CVS to make sure this is corrected.  My tests here on Linux and FreeBSD work fine. 

The workaround for Gorm 1.0.1 users is simply to avoid loading files which are not .gorm files from the command-line. :)

GJC

Gregory John Casamento <gcasa>
Group administrator
Tue 13 Dec 2005 10:48:15 PM UTC, comment #6: 

You shouldn't load the objects.gorm file directly.   I'm not exactly sure why there's a compulsion to do this, perhaps I'll add a warning or something like that to the code which will alert the user to the problem.

I will try to load some other file and see if it yields the problem you described.

Thanks, GJC

Gregory John Casamento <gcasa>
Group administrator
Tue 13 Dec 2005 09:11:05 PM UTC, comment #5: 

Thanks for the libobjc hint :).
Silly me also forgot to mention that I don't open the .gorm "directory-file" but the objects.gorm file within >_>. Of course it works fine otherwise, sorry for the confusion.

Further testing revealed that Gorm crashes on exit with any file that is not the gorm directory-file it expected. Do a '/usr/local/GNUstep/System/Applications/Gorm.app/Gorm -GSFilePath randomfile', quit and see.

Nikolaus Waxweiler <madleser>
Tue 13 Dec 2005 06:40:57 AM UTC, comment #4: 

Also tried the same test with Gorm and several files on FreeBSD 5.4.   I currently don't have 6.0 installed, but will try that soon.   In the meantime, please attach the .gorm file which you are using to this bug.

Thanks, GJC

Gregory John Casamento <gcasa>
Group administrator
Tue 13 Dec 2005 06:20:10 AM UTC, comment #3: 

It should also be mentioned that the gnustep-objc library is not needed since you're using gcc 3.4.4.   That version of the compiler has a newer version of libobjc.  

gnustep-libobjc is meant to be used with older gcc compilers which don't have a working libobjc.

GJC

Gregory John Casamento <gcasa>
Group administrator
Tue 13 Dec 2005 05:56:17 AM UTC, comment #2: 

I have tried both methods with a number of files on Linux and have been unable to recreate the problem using Gorm 1.0.1.  I will compile and build on FreeBSD and check to see if there is a problem there.

Please attach the .gorm file you are having trouble with to this bug, if possible and I will test with that.   GJC

Gregory John Casamento <gcasa>
Group administrator
Fri 09 Dec 2005 09:21:23 PM UTC, comment #1: 

Forgot to add that I use Gorm 1.0.1.

Nikolaus Waxweiler <madleser>
Fri 09 Dec 2005 09:13:16 PM UTC, original submission:  

'Directly' meaning using either 'gopen file.gorm' or 'Gorm.app -GSFilePath file.gorm'. Gorm complains about not being able to load those files directly and crashes when you try to quit.
Opening a .gorm file in the shelf or from within ProjectCenter works just fine.

OS: FreeBSD/x86 6.0
GCC version: 3.4.4 [FreeBSD] 20050518
Libraries:
 - gnustep-back-0.10.1 (Standard backend)
 - gnustep-base-1.11.1
 - gnustep-gui-0.10.1
 - gnustep-make-1.11.1
 - gnustep-objc-1.4.0,1 ("A snapshot of libobjc, meant to be used with GNUstep")

Nikolaus Waxweiler <madleser>

 

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

Attach Files:
   
   
Comment:
   

Attached Files
file #2454:  backtrace.txt added by madleser (3KiB - text/plain - Backtrace.)

 

Depends on the following items: None found

Items that depend on this one: None found

 

CC list is empty

 

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 6 latest changes.

Date Changed by Updated Field Previous Value => Replaced by
2005-12-18 gcasa Open/ClosedIn Test Closed
2005-12-15 gcasa StatusWorks For Me Fixed
    Open/ClosedOpen In Test
2005-12-13 gcasa StatusNone Works For Me
    Assigned toNone gcasa
2005-12-09 madleser Attached File- Added backtrace.txt, #3175

Back to the top

Powered by Savane 3.13-f8d8.
Corresponding source code