Re: Using NSWindow in a dynamically loaded binary / memory issues
Re: Using NSWindow in a dynamically loaded binary / memory issues
- Subject: Re: Using NSWindow in a dynamically loaded binary / memory issues
- From: John Stiles <email@hidden>
- Date: Sun, 13 Jan 2008 20:05:38 -0800
In the past, it wasn't legal to unload any dylib which used Objective-C,
because at load time its classes would get mixed in to the application
and there wasn't any way to take them out again.
I don't know if this has been changed in Leopard, but it definitely was
no good in Tiger.
Wesley Smith wrote:
Hi,
I've got a dynamically loaded binary that can create NSWindow objects.
Currently I'm having some memory issues when the binary gets unloaded
with the try to free a pointer that is not a malloc buffer message
rearing its head. Here's a backtrace:
GuardMalloc[LuaAV-29575]: Tried to free pointer at 0x15a8f860 which is
not currently a pointer to a malloc buffer.
GuardMalloc[LuaAV-29575]: Explicitly trapping into debugger!!!
Program received signal: "SIGTRAP".
#0 0x9b873085 in GMfree ()
#1 0x90a5b8cc in _free_internal ()
#2 0x90a6255f in unmap_images ()
#3 0x90a59368 in _objc_notify_images ()
#4 0x8fe0e31a in
__dyld__ZN16ImageLoaderMachO14doNotificationE15dyld_image_modejPK15dyld_image_info
()
#5 0x8fe029af in __dyld__ZN4dyld11removeImageEP11ImageLoader ()
#6 0x8fe07a99 in __dyld_NSUnLinkModule ()
#7 0x900510c4 in NSUnLinkModule ()
#8 0x00035d85 in gctm ()
#9 0x00030dd8 in luaD_precall ()
#10 0x00030e78 in luaD_call ()
#11 0x00032664 in GCTM ()
#12 0x0003268e in luaC_callGCTM ()
#13 0x000304f2 in luaD_rawrunprotected ()
#14 0x0003ab16 in lua_close ()
#15 0x0000481a in LuaAV::close_Lua (this=0x6180)
#16 0x00004880 in close_lua () at
/Users/whsmith/Documents/Jitter-Dev/jit.gl.lua/Lua_dev/luawindow/app/LuaAV.cpp:16
#17 0x00002a2d in -[LuaAVResponder applicationWillTerminate:]
(self=0xb8178ff4, _cmd=0x5064, aNotification=0xe8b8efec)
#18 0x927f015b in _nsnote_callback ()
#19 0x908563ca in __CFXNotificationPost ()
#20 0x9084db69 in _CFXNotificationPostNotification ()
#21 0x927e8704 in -[NSNotificationCenter
postNotificationName:object:userInfo:] ()
#22 0x927ef6a9 in -[NSNotificationCenter postNotificationName:object:] ()
#23 0x93423140 in -[NSApplication terminate:] ()
#24 0x93389dbc in -[NSApplication sendAction:to:from:] ()
#25 0x93437d0f in -[NSMenu performActionForItemAtIndex:] ()
#26 0x93437a51 in -[NSCarbonMenuImpl
performActionWithHighlightingForItemAtIndex:] ()
#27 0x934376a8 in -[NSMenu performKeyEquivalent:] ()
#28 0x93437149 in -[NSApplication _handleKeyEquivalent:] ()
#29 0x9336adbb in -[NSApplication sendEvent:] ()
#30 0x93295e1e in -[NSApplication run] ()
#31 0x93289d4f in NSApplicationMain ()
#32 0x0000257e in main (argc=1, argv=0xbffff818)
Seems it somehow the _objc_notify_images() call ends up trying to free
the Window even though it has already been killed. I'm not incredibly
familiar with the peculiarities of the Cocoa/objc memory mechanisms
and I'm wondering what those last few function calls are doing. I'm
running this right now on the latest Tiger update.
thanks,
wes
_______________________________________________
Cocoa-dev mailing list (email@hidden)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden
_______________________________________________
Cocoa-dev mailing list (email@hidden)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden