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: Fred Kiefer
Subject: Re: r27812 - in /libs/gui/trunk: ChangeLog Source/NSBundleAdditions.m
Date: Mon, 22 Mar 2010 22:27:08 +0100
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; de; rv:1.9.1.8) Gecko/20100228 SUSE/3.0.3-1.1.1 Thunderbird/3.0.3

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]