Crash Log with no Relation to where it Crashed

  • My application is crashing deep in my code when I full expand an
    NSOutlineView item having 41 levels and about 160,000 unique items. I
    wrote a subclass of NSOutlineView to fully expand myself and try to
    find out where it crashes, but the crash log doesn't have any
    information about my code or about NSOutlineView code.

    Is there an explanation for such a minimalist crash log listed below
    (and it is showing all the threads, I left out only the binary image
    descriptions to save space):

    Everything is fine if the list is smaller (e.g., 31 levels with about
    50,000 items)

    **********

    Host Name:      John-Nairn-Mac-Mini
    Date/Time:      2007-12-12 09:34:03.329 -0800
    OS Version:    10.4.10 (Build 8R218)
    Report Version: 4

    Command: GEDitCOM II
    Path:    /Users/john/Programming/Cocoa_HomeProjects/GEDitCOM Pro/
    build/Default/GEDitCOM II.app/Contents/MacOS/GEDitCOM II
    Parent:  WindowServer [73]

    Version: Version 1.0a3 (1)

    PID:    27031
    Thread: 0

    Exception:  EXC_BAD_ACCESS (0x0001)
    Codes:      KERN_INVALID_ADDRESS (0x0001) at 0xe0000400

    Thread 0 Crashed:
    0  <<00000000>>     0xfffeff20 objc_msgSend_rtp + 32
    1  com.apple.Foundation       0x92bbf908 NSPopAutoreleasePool + 536
    2  com.apple.AppKit           0x9379dd34 -[NSApplication run] + 544
    3  com.apple.AppKit           0x9388e87c NSApplicationMain + 452
    4  com.geditcom.GEDitCOMII     0x00008e18 _start + 760
    5  com.geditcom.GEDitCOMII     0x00008b1c start + 48

    Thread 1:
    0  libSystem.B.dylib           0x9002c3c8 semaphore_wait_signal_trap + 8
    1  libSystem.B.dylib           0x90030eac pthread_cond_wait + 480
    2  com.apple.Foundation       0x92bea30c -[NSConditionLock
    lockWhenCondition:] + 68
    3  com.apple.AppKit           0x9383e708 -[NSUIHeartBeat
    _heartBeatThread:] + 324
    4  com.apple.Foundation       0x92be31a0 forkThreadForFunction + 108
    5  libSystem.B.dylib           0x9002bd08 _pthread_body + 96

    Thread 0 crashed with PPC Thread State 64:
      srr0: 0x00000000fffeff20 srr1:
    0x000000000200f030                        vrsave: 0x0000000000000000
        cr: 0x44000224          xer: 0x0000000000000000  lr:
    0x0000000092bbf908  ctr: 0x0000000000000016
        r0: 0x0000000000000001  r1: 0x00000000bffff1b0  r2:
    0x00000000e0000400  r3: 0x000000000a118720
        r4: 0x0000000090aa9904  r5: 0x0000000001800000  r6:
    0x00000000ffffffff  r7: 0x0000000007c4d470
        r8: 0x0000000000000001  r9: 0x0000000000341000  r10:
    0x0000000000000004  r11: 0x000000006f549904
        r12: 0x000000000a11b2ab  r13: 0x0000000000000000  r14:
    0x0000000000000000  r15: 0x0000000000000000
        r16: 0x0000000000000000  r17: 0x0000000000000000  r18:
    0x0000000000000000  r19: 0x0000000000000000
        r20: 0x0000000000000000  r21: 0x0000000000000000  r22:
    0x0000000000000000  r23: 0x0000000000000000
        r24: 0x0000000000000000  r25: 0x0000000000000002  r26:
    0x0000000000000000  r27: 0x00000000a37dd85c
        r28: 0x0000000090aac18c  r29: 0x000000000a118720  r30:
    0x00000000a3799078  r31: 0x0000000092bbf704

    ---------------
    John Nairn (1-541-737-4265, FAX:1-541-737-3385)
    Professor and Richardson Chair
    Web Page: http://woodscience.oregonstate.edu/faculty/nairn.php (under
    construction)
    FEA/MPM Web Page: http://oregonstate.edu/~nairnj
  • Overreleasing an object is the most likely explanation. (It's crashing
    while cleaning up autoreleases.) Have you turned on NSZombie checking?

    John Nairn wrote:
    > My application is crashing deep in my code when I full expand an
    > NSOutlineView item having 41 levels and about 160,000 unique items. I
    > wrote a subclass of NSOutlineView to fully expand myself and try to
    > find out where it crashes, but the crash log doesn't have any
    > information about my code or about NSOutlineView code.
    >
    > Is there an explanation for such a minimalist crash log listed below
    > (and it is showing all the threads, I left out only the binary image
    > descriptions to save space):
    >
    > Everything is fine if the list is smaller (e.g., 31 levels with about
    > 50,000 items)
    >
    > **********
    >
    > Host Name:      John-Nairn-Mac-Mini
    > Date/Time:      2007-12-12 09:34:03.329 -0800
    > OS Version:    10.4.10 (Build 8R218)
    > Report Version: 4
    >
    > Command: GEDitCOM II
    > Path:    /Users/john/Programming/Cocoa_HomeProjects/GEDitCOM
    > Pro/build/Default/GEDitCOM II.app/Contents/MacOS/GEDitCOM II
    > Parent:  WindowServer [73]
    >
    > Version: Version 1.0a3 (1)
    >
    > PID:    27031
    > Thread: 0
    >
    > Exception:  EXC_BAD_ACCESS (0x0001)
    > Codes:      KERN_INVALID_ADDRESS (0x0001) at 0xe0000400
    >
    > Thread 0 Crashed:
    > 0  <<00000000>>    0xfffeff20 objc_msgSend_rtp + 32
    > 1  com.apple.Foundation        0x92bbf908 NSPopAutoreleasePool + 536
    > 2  com.apple.AppKit            0x9379dd34 -[NSApplication run] + 544
    > 3  com.apple.AppKit            0x9388e87c NSApplicationMain + 452
    > 4  com.geditcom.GEDitCOMII    0x00008e18 _start + 760
    > 5  com.geditcom.GEDitCOMII    0x00008b1c start + 48
    >
    > Thread 1:
    > 0  libSystem.B.dylib          0x9002c3c8 semaphore_wait_signal_trap + 8
    > 1  libSystem.B.dylib          0x90030eac pthread_cond_wait + 480
    > 2  com.apple.Foundation        0x92bea30c -[NSConditionLock
    > lockWhenCondition:] + 68
    > 3  com.apple.AppKit            0x9383e708 -[NSUIHeartBeat
    > _heartBeatThread:] + 324
    > 4  com.apple.Foundation        0x92be31a0 forkThreadForFunction + 108
    > 5  libSystem.B.dylib          0x9002bd08 _pthread_body + 96
    >
    > Thread 0 crashed with PPC Thread State 64:
    > srr0: 0x00000000fffeff20 srr1:
    > 0x000000000200f030                        vrsave: 0x0000000000000000
    > cr: 0x44000224          xer: 0x0000000000000000  lr:
    > 0x0000000092bbf908  ctr: 0x0000000000000016
    > r0: 0x0000000000000001  r1: 0x00000000bffff1b0  r2:
    > 0x00000000e0000400  r3: 0x000000000a118720
    > r4: 0x0000000090aa9904  r5: 0x0000000001800000  r6:
    > 0x00000000ffffffff  r7: 0x0000000007c4d470
    > r8: 0x0000000000000001  r9: 0x0000000000341000  r10:
    > 0x0000000000000004  r11: 0x000000006f549904
    > r12: 0x000000000a11b2ab  r13: 0x0000000000000000  r14:
    > 0x0000000000000000  r15: 0x0000000000000000
    > r16: 0x0000000000000000  r17: 0x0000000000000000  r18:
    > 0x0000000000000000  r19: 0x0000000000000000
    > r20: 0x0000000000000000  r21: 0x0000000000000000  r22:
    > 0x0000000000000000  r23: 0x0000000000000000
    > r24: 0x0000000000000000  r25: 0x0000000000000002  r26:
    > 0x0000000000000000  r27: 0x00000000a37dd85c
    > r28: 0x0000000090aac18c  r29: 0x000000000a118720  r30:
    > 0x00000000a3799078  r31: 0x0000000092bbf704
    >
    > ---------------
    > John Nairn (1-541-737-4265, FAX:1-541-737-3385)
    > Professor and Richardson Chair
    > Web Page: http://woodscience.oregonstate.edu/faculty/nairn.php (under
    > construction)
    > FEA/MPM Web Page: http://oregonstate.edu/~nairnj
  • It's very likely that you release something that is also autoreleased
    some where. Like a string, an dictionary or an array holding the data.

    John

    On 12/12/07, John Stiles <JStiles...> wrote:
    >
    > Overreleasing an object is the most likely explanation. (It's crashing
    > while cleaning up autoreleases.) Have you turned on NSZombie checking?
    >
    >
    > John Nairn wrote:
    >> My application is crashing deep in my code when I full expand an
    >> NSOutlineView item having 41 levels and about 160,000 unique items. I
    >> wrote a subclass of NSOutlineView to fully expand myself and try to
    >> find out where it crashes, but the crash log doesn't have any
    >> information about my code or about NSOutlineView code.
    >>
    >> Is there an explanation for such a minimalist crash log listed below
    >> (and it is showing all the threads, I left out only the binary image
    >> descriptions to save space):
    >>
    >> Everything is fine if the list is smaller (e.g., 31 levels with about
    >> 50,000 items)
    >>
    >> **********
    >>
    >> Host Name:      John-Nairn-Mac-Mini
    >> Date/Time:      2007-12-12 09:34:03.329 -0800
    >> OS Version:    10.4.10 (Build 8R218)
    >> Report Version: 4
    >>
    >> Command: GEDitCOM II
    >> Path:    /Users/john/Programming/Cocoa_HomeProjects/GEDitCOM
    >> Pro/build/Default/GEDitCOM II.app/Contents/MacOS/GEDitCOM II
    >> Parent:  WindowServer [73]
    >>
    >> Version: Version 1.0a3 (1)
    >>
    >> PID:    27031
    >> Thread: 0
    >>
    >> Exception:  EXC_BAD_ACCESS (0x0001)
    >> Codes:      KERN_INVALID_ADDRESS (0x0001) at 0xe0000400
    >>
    >> Thread 0 Crashed:
    >> 0  <<00000000>>    0xfffeff20 objc_msgSend_rtp + 32
    >> 1  com.apple.Foundation        0x92bbf908 NSPopAutoreleasePool + 536
    >> 2  com.apple.AppKit            0x9379dd34 -[NSApplication run] + 544
    >> 3  com.apple.AppKit            0x9388e87c NSApplicationMain + 452
    >> 4  com.geditcom.GEDitCOMII    0x00008e18 _start + 760
    >> 5  com.geditcom.GEDitCOMII    0x00008b1c start + 48
    >>
    >> Thread 1:
    >> 0  libSystem.B.dylib          0x9002c3c8 semaphore_wait_signal_trap +
    > 8
    >> 1  libSystem.B.dylib          0x90030eac pthread_cond_wait + 480
    >> 2  com.apple.Foundation        0x92bea30c -[NSConditionLock
    >> lockWhenCondition:] + 68
    >> 3  com.apple.AppKit            0x9383e708 -[NSUIHeartBeat
    >> _heartBeatThread:] + 324
    >> 4  com.apple.Foundation        0x92be31a0 forkThreadForFunction + 108
    >> 5  libSystem.B.dylib          0x9002bd08 _pthread_body + 96
    >>
    >> Thread 0 crashed with PPC Thread State 64:
    >> srr0: 0x00000000fffeff20 srr1:
    >> 0x000000000200f030                        vrsave: 0x0000000000000000
    >> cr: 0x44000224          xer: 0x0000000000000000  lr:
    >> 0x0000000092bbf908  ctr: 0x0000000000000016
    >> r0: 0x0000000000000001  r1: 0x00000000bffff1b0  r2:
    >> 0x00000000e0000400  r3: 0x000000000a118720
    >> r4: 0x0000000090aa9904  r5: 0x0000000001800000  r6:
    >> 0x00000000ffffffff  r7: 0x0000000007c4d470
    >> r8: 0x0000000000000001  r9: 0x0000000000341000  r10:
    >> 0x0000000000000004  r11: 0x000000006f549904
    >> r12: 0x000000000a11b2ab  r13: 0x0000000000000000  r14:
    >> 0x0000000000000000  r15: 0x0000000000000000
    >> r16: 0x0000000000000000  r17: 0x0000000000000000  r18:
    >> 0x0000000000000000  r19: 0x0000000000000000
    >> r20: 0x0000000000000000  r21: 0x0000000000000000  r22:
    >> 0x0000000000000000  r23: 0x0000000000000000
    >> r24: 0x0000000000000000  r25: 0x0000000000000002  r26:
    >> 0x0000000000000000  r27: 0x00000000a37dd85c
    >> r28: 0x0000000090aac18c  r29: 0x000000000a118720  r30:
    >> 0x00000000a3799078  r31: 0x0000000092bbf704
    >>
    >> ---------------
    >> John Nairn (1-541-737-4265, FAX:1-541-737-3385)
    >> Professor and Richardson Chair
    >> Web Page: http://woodscience.oregonstate.edu/faculty/nairn.php (under
    >> construction)
    >> FEA/MPM Web Page: http://oregonstate.edu/~nairnj

    >
previous month december 2007 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