bugGNUstep - Bugs: bug #15612, Exception on Gorm launch with...

Group
 
 

bug #15612: Exception on Gorm launch with latest SVN (r22413)

Submitter:  Quentin Mathé <qmathe>
Submitted:  Fri 03 Feb 2006 01:40:13 AM UTC
   
 
Category:  Gui/AppKit Severity:  2 - Minor
Item Group:  Bug Status:  Fixed
Privacy:  Public Assigned to:  CaS
Open/Closed:  Closed
* Mandatory Fields

Add a New Comment Rich Markup
   

Jump to the original submission

Sat 11 Nov 2006 05:23:41 AM UTC, comment #6: 

Tested and confirmed this is not happening.  No feedback from submitter.

Gregory John Casamento <gcasa>
Group administrator
Sun 23 Apr 2006 10:47:14 PM UTC, comment #5: 

Changed category and marked as in test.

Fred Kiefer <FredKiefer>
Group Member
Tue 07 Feb 2006 03:38:13 PM UTC, comment #4: 

I mean a notification whose userInfo dictionary did not contain a key 'NSApplicationName' (I guess you would call that 'badly formed').
The stack trace looks like this was the application aqctivation notification, but I checked the NSApplication.m code for the version of the library you had trouble with, and it contained the changes to put the application name in the user info.

Is it possible that you could have had the gui built with NSApplication.m and NSWorkspace.m at different gui versions (ie the new NSWorkspace code but the older NSApplication code)?  That would explain it.

Richard Frith-Macdonald <CaS>
Group Member
Sat 04 Feb 2006 12:09:19 PM UTC, comment #3: 

Gorm is now launching without hurdle. Thanks Richard.

How did that bad notification get sent to my Gorm copy… well I have no idea.

By 'bad' notification, do you mean 'not well formed' or 'wrongly sent' ?
I'm not sure, but -[NSApplication activateIgnoringOtherApps:] is sent as notification, right ?

Quentin Mathé <qmathe>
Group Member
Fri 03 Feb 2006 07:53:13 AM UTC, comment #2: 

I've reclassed this as minort rather than closing it.

I've changed the code in GSLaunched() to hide the problem/prevent the crash since, while I can't reproduce the problem by running an app, the stacktrace makes it quite clear what the immediate problem is even though it doesn't tell us the underlying cause.

Simply, the code was assuming that the notification user info contained the NSApplicationName value that the notifications should have in them ... then raising a nil pointer exception when trying to use the (non-existent) name from the dictionary.

Clearly this was wrong and the code should have chacked the notification contents (since any app can send the notifications and omit information which should have been in them), however the question is how did that bad notification get sent tto your copy of Gorm ... where did it come from  and if it was posted with the application name in it, how did that get lost?


Richard Frith-Macdonald <CaS>
Group Member
Fri 03 Feb 2006 01:45:47 AM UTC, comment #1: 

Here is a complete stack trace as promised.

#0  -[NSException raise] (self=0x84a53c8, _cmd=0xb7aa2020) at NSException.m:147
#1  0xb7881108 in -[GSMutableDictionary setObject:forKey:] (self=0x84a5278,
    _cmd=0xb7dbeb90, anObject=0x0, aKey=0xb7dbf6c0) at GSDictionary.m:407
#2  0xb7cc454c in GSLaunched (notification=0x84a2dd0, active=1 '\001')
    at NSWorkspace.m:183
#3  0xb792dbf9 in -[NSNotificationCenter _postAndRelease:] (self=0x8088bd0,
    _cmd=0xb7aca480, notification=0x84a2dd0) at NSNotificationCenter.m:1070
#4  0xb792b79b in -[NSNotificationCenter postNotificationName:object:userInfo:]
    (self=0x8088bd0, _cmd=0xb7d38010, name=0xb7dc7fa8, object=0x8178a40,
    info=0x83f4c50) at NSNotificationCenter.m:1138
#5  0xb7b94995 in -[NSApplication activateIgnoringOtherApps:] (self=0x8178a40,
    _cmd=0xb7dbb0e8, flag=1 '\001') at NSApplication.m:1177
#6  0xb7cbc9e6 in -[NSWindow sendEvent:] (self=0x8484358, _cmd=0xb7d38150,
    theEvent=0x84a2fa8) at NSWindow.m:3048
#7  0xb7b95e13 in -[NSApplication sendEvent:] (self=0x8178a40,
    _cmd=0xb7d38088, theEvent=0x84a2fa8) at NSApplication.m:1830
#8  0xb7b95801 in -[NSApplication runModalSession:] (self=0x8178a40,
    _cmd=0xb7d380e0, theSession=0x8498050) at NSApplication.m:1608
#9  0xb7b954cf in -[NSApplication runModalForWindow:] (self=0x8178a40,
    _cmd=0xb7d34878, theWindow=0x8484358) at NSApplication.m:1496
#10 0xb7b901c0 in -[GSAlertPanel runModal] (self=0x8484358, _cmd=0xb7d348f8)
    at NSAlert.m:716
#11 0xb7b90b29 in NSRunAlertPanel (title=0x0, msg=0xb7ed5340,
---Type <return> to continue, or q <return> to quit---defaultButton=0xb7Quit
) at NSAlert.m:960
#12 0xb7e82a00 in -[GormPalettesManager loadPalette:] (self=0x8260828,
    _cmd=0xb7ed4be8, path=0xbf900b78) at GormPalettesManager.m:409
#13 0xb7e82284 in -[GormPalettesManager init] (self=0x8260828, _cmd=0x8053610)
    at GormPalettesManager.m:351
#14 0x0804e5b9 in -[Gorm palettesManager] (self=0x8178a40, _cmd=0x8053670)
    at Gorm.m:1105
#15 0x0804990b in -[Gorm init] () at Gorm.m:148
#16 0xb7b947c9 in +[NSApplication sharedApplication] (self=0x8053ce0,
    _cmd=0xb7d313c0) at NSApplication.m:771
#17 0xb7b89579 in NSApplicationMain (argc=1, argv=0xbf900ff4) at Functions.m:72
#18 0x0804fcd4 in main (argc=1, argv=0xbf900ff4) at main.m:30

Quentin Mathé <qmathe>
Group Member
Fri 03 Feb 2006 01:40:13 AM UTC, original submission:  

Ubuntu Linux x86

When I launch Gorm 1.0.4 (or latest SVN version), I'm observing an exception "Tried to add nil value for key 'GSActive' to dictionary".

I'm not observing this bug with other application like GSTest to take an example.

I have reproduced this problem with two -base and-gui versions:
- latest cvs
- SVN r22413 (iirc I observed the issue with -gui r22399 too)

Finally it happens with Gorm 1.0.1 also.

I'm not sure the bug is related to Gorm because it is involving stuff like GSLaunched, GSActive which are related to recent changes in NSApplication.m or/and NSWorkspace.m

Related stack trace to follow soon.

Quentin.

Quentin Mathé <qmathe>
Group Member

 

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

Attach Files:
   
   
Comment:
   

No files currently attached

 

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
2006-11-11 gcasa Open/ClosedIn Test Closed
2006-04-23 FredKiefer CategoryNone Gui/AppKit
    StatusNone Fixed
    Assigned toNone CaS
    Open/ClosedOpen In Test
2006-02-03 CaS Severity5 - Blocker 2 - Minor

Back to the top

Powered by Savane 3.13-758e.
Corresponding source code