NSView viewWillDraw crash

  • I've just caught a crash in NSView's viewWillDraw method, stack
    backtrace below, note that none of my views implement this method. I'm
    trying to think of an instance in which a crash could happen without
    having overidden the method?

    I'f no-one can think of anything I'll just have to file a bug.

    - Keith

    #0  0x915f15e4 in CFRelease ()
    #1  0x91581343 in __CFArrayReleaseValues ()
    #2  0x915f17c8 in _CFRelease ()
    #3  0x9381f86a in -[NSView viewWillDraw] ()
    #4  0x9381f7fe in -[NSView viewWillDraw] ()
    #5  0x9385f14b in -[NSBox viewWillDraw] ()
    #6  0x9381f7fe in -[NSView viewWillDraw] ()
    #7  0x9381f7fe in -[NSView viewWillDraw] ()
    #8  0x9381f7fe in -[NSView viewWillDraw] ()
    #9  0x9381f7fe in -[NSView viewWillDraw] ()
    #10 0x9381f7fe in -[NSView viewWillDraw] ()
    #11 0x9381eeef in -[NSView _sendViewWillDrawInRect:] ()
    #12 0x9376133d in -[NSView displayIfNeeded] ()
    #13 0x93760f2d in -[NSWindow displayIfNeeded] ()
    #14 0x93760d50 in _handleWindowNeedsDisplay ()
    #15 0x915ed9e2 in __CFRunLoopDoObservers ()
    #16 0x915eed45 in CFRunLoopRunSpecific ()
    #17 0x915efd38 in CFRunLoopRunInMode ()
    #18 0x90b9f8a4 in RunCurrentEventLoopInMode ()
    #19 0x90b9f5f6 in ReceiveNextEventCommon ()
    #20 0x90b9f531 in BlockUntilNextEventMatchingListInMode ()
    #21 0x9375ed5b in _DPSNextEvent ()
    #22 0x9375e6a0 in -[NSApplication
    nextEventMatchingMask:untilDate:inMode:dequeue:] ()
    #23 0x937576d1 in -[NSApplication run] ()
    #24 0x937249ba in NSApplicationMain ()
    #25 0x00008bea in ?? ()
  • On Jan 10, 2008, at 1:13 PM, Keith Duncan wrote:
    > I've just caught a crash in NSView's viewWillDraw method, stack
    > backtrace below, note that none of my views implement this method.
    > I'm trying to think of an instance in which a crash could happen
    > without having overidden the method?
    >
    > I'f no-one can think of anything I'll just have to file a bug.
    >
    > - Keith
    >
    > #0  0x915f15e4 in CFRelease ()
    > #1  0x91581343 in __CFArrayReleaseValues ()
    > #2  0x915f17c8 in _CFRelease ()
    > #3  0x9381f86a in -[NSView viewWillDraw] ()

    It indicates that some view was likely removed from the view hierarchy
    while that particular thread was trying to figure out what views will
    need drawing.

    While the backtrace doesn't pass through your code, you cannot
    conclude that it isn't a bug in your code.  In particular, are you
    manipulating the view hierarchy -- removing views from it -- from
    another thread or in any "figure out the rect that needs to be
    refreshed" code?

    b.bum
  • On Jan 10, 2008, at 1:13 PM, Keith Duncan wrote:

    > I've just caught a crash in NSView's viewWillDraw method, stack
    > backtrace below, note that none of my views implement this method.
    > I'm trying to think of an instance in which a crash could happen
    > without having overidden the method?

    Two things you might want to check:

    * Are you using multiple threads, and doing anything that might not be
    thread safe?

    * Run with NSZombieEnabled to see if you can catch anything that way
    (unless you're using GC).

    j o a r
  • On Jan 10, 2008 1:13 PM, Keith Duncan <keith_duncan...> wrote:
    > I've just caught a crash in NSView's viewWillDraw method, stack
    > backtrace below, note that none of my views implement this method. I'm
    > trying to think of an instance in which a crash could happen without
    > having overidden the method?
    >
    > I'f no-one can think of anything I'll just have to file a bug.
    >
    > - Keith
    >
    > #0  0x915f15e4 in CFRelease ()
    > #1  0x91581343 in __CFArrayReleaseValues ()
    > #2  0x915f17c8 in _CFRelease ()

    Crashes in CFRelease or -release almost always indicate that some
    object has been over-released. I'd pay special attention to any code
    you have that either creates views or manipulates the view hierarchy
    in other ways. Look for any -release or -autorelease method calls that
    aren't properly balanced.

    --
    Clark S. Cox III
    <clarkcox3...>
  • > In particular, are you manipulating the view hierarchy -- removing
    > views from it -- from another thread or in any "figure out the rect
    > that needs to be refreshed" code?

    Nope, no views are added/removed in any of my code.

    > Crashes in CFRelease or -release almost always indicate that some
    > object has been over-released. I'd pay special attention to any code
    > you have that either creates views or manipulates the view hierarchy
    > in other ways. Look for any -release or -autorelease method calls that
    > aren't properly balanced.

    My thoughts exactly, however...

    > Run with NSZombieEnabled to see if you can catch anything that way
    > (unless you're using GC).

    ...I tried this along with CFZombieLevel, but it didn't log anything
    though. This is a preference pane app with the System Preferences
    started as a custom executable with NSZombie and CFZombieLevel set as
    arguments so that should still work right?

    From the original stack trace one of the return address' is in
    NSBox's implementation of viewWillDraw. Now, my interface has two
    boxes, one housing the other and a custom view. To investigate if I
    was perhaps doing something in my custom view to cause the crash I
    implemented viewWillDraw and simply called super - turns out that my
    custom view isn't the problem because its viewWillDraw is never in the
    return stack.

    Of course, it is far more likely to be something in my code that is at
    fault that something in the frameworks. The bug is also reproducible
    to a certain extent though it isn't always in the same return stack
    leading me to believe it is in fact a memory management bug. But if I
    can't get NSZombies to work then how am I to proceed?

    - Keith
  • >
    > Of course, it is far more likely to be something in my code that is
    > at fault that something in the frameworks. The bug is also
    > reproducible to a certain extent though it isn't always in the same
    > return stack leading me to believe it is in fact a memory management
    > bug. But if I can't get NSZombies to work then how am I to proceed?

    Try these steps (assuming you have Instruments on Leopard):

    http://www.corbinstreehouse.com/blog/?p=261

    They work excellent for finding out the over-releases...

    corbin
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