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!
>
>
_______________________________________________
Gnustep-dev mailing list
Gnustep-dev@gnu.org
http://lists.gnu.org/mailman/listinfo/gnustep-dev
