Using NSWindow in a dynamically loaded binary / memory issues

  • 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
  • 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
    >
previous month january 2008 next month
MTWTFSS
  1 2 3 4 5 6
7 8 9 10 11 12 13
14 15 16 17 18 19 20
21 22 23 24 25 26 27
28 29 30 31      
Go to today