gnustep-dev
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: r27812 - in /libs/gui/trunk: ChangeLog Source/NSBundleAdditions.m


From: Doug Simons
Subject: Re: r27812 - in /libs/gui/trunk: ChangeLog Source/NSBundleAdditions.m
Date: Mon, 22 Mar 2010 15:44:54 -0600

Thanks Fred,

It looks like that has fixed the problem with NSApp. It also appears to have solved the other problem that I reported to you privately. We will do some more testing and let you know if we run into any other problems with nib loading. Thanks for the quick fix!

Regards,

Doug

On Mar 22, 2010, at 3:27 PM, Fred Kiefer wrote:

Thank you for pointing out the problem with NSApp. This was caused by a
missing retain in some part of GSNibLoading that I hadn't cleaned up.

Hopefully this is fixed now. If there are any other issues I hope we can
resolve them as quick as that one.

Fred

Am 22.03.2010 18:24, schrieb Doug Simons:
I'm not positive, but I'm guessing that these nib loading changes
checked in over the weekend are the cause of new crashes that we are
seeing when building with the latest code (r30018) on Windows.

Our app now crashes on launch. Here's the relevant gdb output:

Program received signal SIGSEGV, Segmentation fault. 0x67848ae6 in
objc_msg_lookup () from c:\GNUstep\GNUstep\System\Tools\objc-1.dll
(gdb) bt #0  0x67848ae6 in objc_msg_lookup () from
c:\GNUstep\GNUstep\System\Tools\objc-1.dll #1  0x63c4ba52 in
-[NSWindow dealloc] (self=0x151f1a8, _cmd=0x65b59950) at
NSWindow.m:754 #2  0x65a2afad in -[NSObject release] (self=0x151f1a8,
_cmd=0x65b1b850) at NSObject.m:1890 #3  0x6594337f in -[GSArray
dealloc] (self=0x99fee40, _cmd=0x65b59950) at GSArray.m:136 #4
0x65a2afad in -[NSObject release] (self=0x99fee40, _cmd=0x65b2dc50)
at NSObject.m:1890 #5  0x659971dc in -[NSAutoreleasePool emptyPool]
(self=0x1215cb8, _cmd=0x65b2dcc0) at NSAutoreleasePool.m:441 #6
0x65996ff2 in -[NSAutoreleasePool dealloc] (self=0x1215cb8,
_cmd=0x65b2dcb8) at NSAutoreleasePool.m:342 #7  0x65996fb8 in
-[NSAutoreleasePool release] (self=0x1215cb8, _cmd=0x53b228) at
NSAutoreleasePool.m:335 #8  0x004209de in -[EggplantApplication
finishLaunching] (self=0x1211510, _cmd=0x63cf1af0) at
EggplantApplication.m:262 #9  0x63adedfc in -[NSApplication run]
(self=0x1211510, _cmd=0x63ce6ca0) at NSApplication.m:1506 #10
0x63ac1f0f in NSApplicationMain (argc=1, argv=0x10ae698) at
Functions.m:74 #11 0x00401a65 in main (argc=1, argv=0x10ae698) at
main.m:13 (gdb) up #1  0x63c4ba52 in -[NSWindow dealloc]
(self=0x151f1a8, _cmd=0x65b59950) at NSWindow.m:754 754       [NSApp
removeWindowsItem: self]; (gdb) p NSApp $1 = (class NSApplication *)
0x1211510 (gdb) p *NSApp $2 = {{{isa = 0xfeeefeee}, _interface_style
= 4277075694, _next_responder = 0xfeeefeee, _menu = 0xfeeefeee},
_default_context = 0xfeeefeee, _current_event = 0xfeeefeee, _session
= 0xfeeefeee, _key_window = 0xfeeefeee, _main_window = 0xfeeefeee,
_delegate = 0xfeeefeee, _listener = 0xfeeefeee, _main_menu =
0xfeeefeee, _windows_menu = 0xfeeefeee, _app_is_launched = 238 'ε',
_app_is_running = 254 '■', _app_is_active = 238 'ε', _app_is_hidden =
254 '■', _unhide_on_activation = 238 'ε', _windows_need_update = 254
'■', _app_icon = 0xfeeefeee, _app_icon_window = 0xfeeefeee, _hidden =
0xfeeefeee, _inactive = 0xfeeefeee, _hidden_key = 0xfeeefeee,
_infoPanel = 0xfeeefeee, _runLoopPool = 0xfeeefeee} (gdb)

As you can see, NSApp has been freed!! I'm guessing this is because
it is the File's Owner for our main nib file? I'm not sure how else
to explain it getting released.

By adding [NSApp retain] we can get beyond this point, but are
hitting other problems with object loaded from nibs.

Can someone familiar with the recent changes see what might be
causing NSApp to be released? Something is clearly broken here.
Thanks!




reply via email to

[Prev in Thread] Current Thread [Next in Thread]