Closed Bug 624915 Opened 10 years ago Closed 8 years ago

Intermittent shutdown crash on mochitest-4 osx: [@ google_breakpad::ExceptionHandler::WriteMinidump ]


(Toolkit :: Crash Reporting, defect)

Not set





(Reporter: ehsan, Unassigned)



(Keywords: crash, intermittent-failure)

Crash Data
Rev3 MacOSX Snow Leopard 10.6.2 mozilla-central debug test mochitests-4/5 on 2011/01/11 14:55:59

NEXT ERROR Thread 0 (crashed)
 0  libSystem.B.dylib + 0xe82
    rbx = 0x5fbfa700   r12 = 0x00008103   r13 = 0x00003303   r14 = 0x700be5d0
    r15 = 0x12141968   rip = 0x80579e82   rsp = 0x5fbfa5e8   rbp = 0x5fbfa620
    Found by: given as instruction pointer in context
 1  libSystem.B.dylib + 0x63cc
    rip = 0x8057f3cd   rsp = 0x5fbfa5f0
    Found by: stack scanning
 2  XUL!google_breakpad::ExceptionHandler::WriteMinidump [ : 298 + 0xc]
    rip = 0x0005c60a   rsp = 0x5fbfa630
    Found by: stack scanning
 3  XUL!google_breakpad::ExceptionHandler::WriteMinidump [ : 313 + 0x12]
    rip = 0x0005c992   rsp = 0x5fbfa660
    Found by: stack scanning
 4  XUL!google_breakpad::ScopedTaskSuspend::~ScopedTaskSuspend [scoped_task_suspend-inl.h:556f7620b78f : 47 + 0xa]
    rip = 0x0005976b   rsp = 0x5fbfa670
    Found by: stack scanning
 5  XUL!CrashReporter::CreateFileFromPath [nsExceptionHandler.cpp:556f7620b78f : 317 + 0x1]
    rip = 0x0005586c   rsp = 0x5fbfa680
    Found by: stack scanning
 6  XUL!CrashReporter::CreateFileFromPath [nsExceptionHandler.cpp:556f7620b78f : 317 + 0x1]
    rip = 0x0005586c   rsp = 0x5fbfa6d0
    Found by: stack scanning
 7  XUL!__static_initialization_and_destruction_0 [nsXBLInsertionPoint.cpp:556f7620b78f : 118 + 0x2]
    rip = 0x0000ba03   rsp = 0x5fbfa6f0
    Found by: stack scanning
Keywords: crash
Dustin was kind enough to run nm on libSystem.B.dylib on a 10.6 build slave, and we have:
00000e61 T _mach_port_deallocate
000061fc T _pthread_mutex_lock

as the top two frames on the stack. Which I guess makes sense if frame 3 is correct, since it's pointing at:

which is calling pthread_mutex_lock.

I don't actually know what that means, though, and the fact that the rest of the stack is garbage doesn't really help. :-/
Crash Signature: [@ google_breakpad::ExceptionHandler::WriteMinidump ]
Mass marking whiteboard:[orange] bugs WFM (to clean up TBPL bug suggestions) that:
* Haven't changed in > 6months
* Whose whiteboard contains none of the strings: {disabled,marked,random,fuzzy,todo,fails,failing,annotated,leave open,time-bomb}
* Passed a (quick) manual inspection of bug summary/whiteboard to ensure they weren't a false positive.

I've also gone through and searched for cases where the whiteboard wasn't labelled correctly after test disabling, by using attachment description & basic comment searches. However if the test for which this bug was about has in fact been disabled/annotated/..., please accept my apologies & reopen/mark the whiteboard appropriately so this doesn't get re-closed in the future (and please ping me via IRC or email so I can try to tweak the saved searches to avoid more edge cases).

Sorry for the spam! Filter on: #FFA500
Closed: 8 years ago
Resolution: --- → WORKSFORME
Whiteboard: [orange]
You need to log in before you can comment on or make changes to this bug.