NSWindow and autorelease with dynamic binary

  • Hi,
    I've managed to track my crashing problems with a Cocoa dynamically
    loaded binary down to some NSAutoreleasePool stuff.  If I close the
    NSWindow by clicking on the red button in the topleft, and _then_
    quite the app, no crashing.  If I quite the app with an active window,
    I do get crashing after the dynamic binary has been unloaded and the
    app is in its final stack unwind.  What happens is:

    objc_msgSend    <-------------------------------------- CRASH EXC_BAD_ACCESSS
    NSPopAutoReleasePool
    +[NSAutoreleasePoop releaseAllPools]

    which makes sense if a reference is left over.  My question is how can
    I guarantee that all such things have been taken care of?  In my
    dynamic binary teardown, I call

    [window close];
    [window release];

    I thought this would be enough but apparently not.
    Any ideas?

    thanks,
    wes
  • Perhaps your window is already set to release-on-close, so the extra
    release is actually a problem?

    On Jan 15, 2008, at 2:18 AM, Wesley Smith wrote:

    > Hi,
    > I've managed to track my crashing problems with a Cocoa dynamically
    > loaded binary down to some NSAutoreleasePool stuff.  If I close the
    > NSWindow by clicking on the red button in the topleft, and _then_
    > quite the app, no crashing.  If I quite the app with an active window,
    > I do get crashing after the dynamic binary has been unloaded and the
    > app is in its final stack unwind.  What happens is:
    >
    > objc_msgSend    <-------------------------------------- CRASH
    > EXC_BAD_ACCESSS
    > NSPopAutoReleasePool
    > +[NSAutoreleasePoop releaseAllPools]
    >
    > which makes sense if a reference is left over.  My question is how can
    > I guarantee that all such things have been taken care of?  In my
    > dynamic binary teardown, I call
    >
    > [window close];
    > [window release];
    >
    > I thought this would be enough but apparently not.
    > Any ideas?
    >
    > thanks,
    > wes
  • So taking out the extra release call doesn't help at all, that was a
    shot in the dark.  I checked and isReleasedWhenClosed is enabled, so
    after I call [win close], I expect it to be released.  Yet, I'm still
    getting crashes in

    #0    0x90a594c0 in objc_msgSend
    #1    0x003cf090 in ??
    #2    0x927fb7f6 in +[NSAutoreleasePool releaseAllPools]
    #3    0x93423817 in -[NSApplication _deallocHardCore:]
    #4    0x934232d1 in -[NSApplication terminate:]
    #5    0x93389dbc in -[NSApplication sendAction:to:from:]
    #6    0x93437d0f in -[NSMenu performActionForItemAtIndex:]
    #7    0x93437a51 in -[NSCarbonMenuImpl
    performActionWithHighlightingForItemAtIndex:]
    #8    0x934376a8 in -[NSMenu performKeyEquivalent:]
    #9    0x93437149 in -[NSApplication _handleKeyEquivalent:]
    #10    0x9336adbb in -[NSApplication sendEvent:]
    #11    0x93295e1e in -[NSApplication run]
    #12    0x93289d4f in NSApplicationMain
    #13    0x00002f62 in main at main.m:13

    I'm wondering if despite the release, the autoreleasepools still
    retain the memory somewhere and expect it at this point (which is
    after the dynamic binary has been unlinked.  Is there a way to flush
    the autorelease pools to test this theory out?

    thanks,
    wes

    On Jan 15, 2008 9:23 AM, John Stiles <JStiles...> wrote:
    > Perhaps your window is already set to release-on-close, so the extra
    > release is actually a problem?
    >
    >
    > On Jan 15, 2008, at 2:18 AM, Wesley Smith wrote:
    >
    >> Hi,
    >> I've managed to track my crashing problems with a Cocoa dynamically
    >> loaded binary down to some NSAutoreleasePool stuff.  If I close the
    >> NSWindow by clicking on the red button in the topleft, and _then_
    >> quite the app, no crashing.  If I quite the app with an active window,
    >> I do get crashing after the dynamic binary has been unloaded and the
    >> app is in its final stack unwind.  What happens is:
    >>
    >> objc_msgSend    <-------------------------------------- CRASH
    >> EXC_BAD_ACCESSS
    >> NSPopAutoReleasePool
    >> +[NSAutoreleasePoop releaseAllPools]
    >>
    >> which makes sense if a reference is left over.  My question is how can
    >> I guarantee that all such things have been taken care of?  In my
    >> dynamic binary teardown, I call
    >>
    >> [window close];
    >> [window release];
    >>
    >> I thought this would be enough but apparently not.
    >> Any ideas?
    >>
    >> thanks,
    >> wes
    >
    >
  • On Jan 15, 2008, at 10:04 AM, Wesley Smith wrote:

    > So taking out the extra release call doesn't help at all, that was a
    > shot in the dark.  I checked and isReleasedWhenClosed is enabled, so
    > after I call [win close], I expect it to be released.  Yet, I'm still
    > getting crashes in

    Use NSZombieEnabled to figure out what type of deallocated object that
    is triggering the crash.
    This should be your priority #1.

    j o a r
  • > Use NSZombieEnabled to figure out what type of deallocated object that
    > is triggering the crash.
    > This should be your priority #1.
    >

    Ok, So I've turned that on.  From what I've read about NSZombieEnabled
    it should automatically post log messages without me having to do
    anything else right?  Unfortunately, it doesn't seem to be doing so.
    I'm wondering how I can see what Objc_msgSend is trying to do i.e.
    what's the class of the object the selector it's trying talk to.

    wes
  • Set a breakpoint on -[NSException raise].

    On Jan 15, 2008, at 11:36 AM, Wesley Smith wrote:

    >> Use NSZombieEnabled to figure out what type of deallocated object
    >> that
    >> is triggering the crash.
    >> This should be your priority #1.
    >>
    >
    > Ok, So I've turned that on.  From what I've read about NSZombieEnabled
    > it should automatically post log messages without me having to do
    > anything else right?  Unfortunately, it doesn't seem to be doing so.
    > I'm wondering how I can see what Objc_msgSend is trying to do i.e.
    > what's the class of the object the selector it's trying talk to.
    >
    > wes
  • So I've been trying setting breakpoints everywhere and doing all of
    the debugging env variable stuff I can to ge an info as to what's
    going on with no luck.  It seems there is a weird interaction between
    the dynamic binary and the app in Cocoa and I can't get a bead on it.
    I get crashes in dyld close and NSUnlinkModule depending on which I
    use and sometimes from an app terminate-induced NSAutoreleasePool
    call.  What really puzzles me is the difference between manually
    closing the window and procedurally closing the window.  The former
    works, the latter crashes.  If all the manual method does is trigger
    [win close], then I am doing the exact same thing procedurally and
    there should be no difference, but this is not the case.  I can't find
    any docs on what might be different between the two.  Any pointers?

    thanks,
    wes
  • On Jan 15, 2008 3:17 PM, Wesley Smith <wesley.hoke...> wrote:
    > What really puzzles me is the difference between manually
    > closing the window and procedurally closing the window.  The former
    > works, the latter crashes.  If all the manual method does is trigger
    > [win close], then I am doing the exact same thing procedurally and
    > there should be no difference, but this is not the case.  I can't find
    > any docs on what might be different between the two.  Any pointers?

    What happens if you use -[NSWindow performClose:] instead?  That's the
    action associated with the standard close button.

    Maybe the window's delegate is disappearing from under its feet while
    it's trying to ask whether the window should be closed?

    --Kyle Sluder
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