Closed Bug 514397 Opened 12 years ago Closed 12 years ago

[moz2-darwin9-slave*] xpcshell-tests: test_crashreporter.js crashes intermittently


(Toolkit :: Crash Reporting, defect)

Not set



Tracking Status
status1.9.2 --- .14-fixed


(Reporter: ted, Assigned: ted)



(Keywords: crash, intermittent-failure, Whiteboard: [disabled parts of test] [qa-ntd-192])

Similar to bug 488596, but it doesn't appear to be happening on shutdown.

From that bug:
  -------  Comment #76 From  Daniel Holbert [:dholbert]   2009-08-13 12:11:13 PDT   (-) [reply] -------

I think we hit this again today, on moz2-darwin9-slave05
OS X 10.5.2 mozilla-central unit test on 2009/08/13 08:41:53

Full output looks like this:

| test failed (with xpcshell return code: -10), see following log:
  ### XPCOM_MEM_LEAK_LOG defined -- logging leaks to
TEST-INFO | (xpcshell/head.js) | test 1 pending
INFO | test_crashreporter.js | Get crashreporter service.
| [run_test : 11] [xpconnect wrapped nsICrashReporter] != null
INFO | test_crashreporter.js | Disable crashreporter.
| [run_test : 20] false == false
| [run_test : 27] 3253927937 == 3253927937
| [run_test : 35] 3253927937 == 3253927937


-------  Comment #77 From  Daniel Holbert [:dholbert]   2009-09-02 20:47:02 PDT   (-) [reply] -------
OS X 10.5.2 mozilla-central unit test on 2009/09/02 17:32:20
See other important comments in bug 488596...
Depends on: 488596
OS: All → Mac OS X
Summary: xpcshell-tests: test_crashreporter.js crashes intermittently → [moz2-darwin9-slave*] xpcshell-tests: test_crashreporter.js crashes intermittently
Whiteboard: [orange]
Keywords: crash
sayrer was kind enough to valgrind this for me:
TEST-PASS | /Users/sayrer/dev/mc-debug/_tests/xpcshell/crashreporter/unit/test_crashreporter.js | [run_test : 64] true == true
TEST-PASS | /Users/sayrer/dev/mc-debug/_tests/xpcshell/crashreporter/unit/test_crashreporter.js | [run_test : 71] 2147500037 == 2147500037
==46682== Thread 5:
==46682== Invalid read of size 1
==46682==    at 0x2E130BE: google_breakpad::ExceptionHandler::WaitForMessage(void*) (in /Users/sayrer/dev/mc-debug/toolkit/library/XUL)
==46682==    by 0x605154: _pthread_start (in /usr/lib/libSystem.B.dylib)
==46682==    by 0x605011: thread_start (in /usr/lib/libSystem.B.dylib)
==46682==  Address 0xafdcff5 is 53 bytes inside a block of size 104 free'd
==46682==    at 0x3FB1A: operator delete(void*) (vg_replace_malloc.c:346)
==46682==    by 0x2E0DFC9: CrashReporter::UnsetExceptionHandler() (in /Users/sayrer/dev/mc-debug/toolkit/library/XUL)
==46682==    by 0x2DE7481: nsXULAppInfo::SetEnabled(int) (in /Users/sayrer/dev/mc-debug/toolkit/library/XUL)
==46682==    by 0x3F9F142: NS_InvokeByIndex_P (in /Users/sayrer/dev/mc-debug/toolkit/library/XUL)
==46682==    by 0x2E70CAF: XPCWrappedNative::CallMethod(XPCCallContext&, XPCWrappedNative::CallMode) (in /Users/sayrer/dev/mc-debug/toolkit/library/XUL)
==46682==    by 0x2E81CA0: XPCWrappedNative::SetAttribute(XPCCallContext&) (in /Users/sayrer/dev/mc-debug/toolkit/library/XUL)
==46682==    by 0x2E7D30E: XPC_WN_GetterSetter(JSContext*, JSObject*, unsigned int, long*, long*) (in /Users/sayrer/dev/mc-debug/toolkit/library/XUL)
==46682==    by 0x33E6E2: js_Invoke (in /Users/sayrer/dev/mc-debug/js/src/libmozjs.dylib)
==46682==    by 0x33E9FA: js_InternalInvoke (in /Users/sayrer/dev/mc-debug/js/src/libmozjs.dylib)
==46682==    by 0x33EC42: js_InternalGetOrSet (in /Users/sayrer/dev/mc-debug/js/src/libmozjs.dylib)
==46682==    by 0x34C02E: js_SetSprop (in /Users/sayrer/dev/mc-debug/js/src/libmozjs.dylib)
==46682==    by 0x357C20: js_NativeSet (in /Users/sayrer/dev/mc-debug/js/src/libmozjs.dylib)
TEST-PASS | /Users/sayrer/dev/mc-debug/_tests/xpcshell/crashreporter/unit/test_crashreporter.js | [run_test : 83] ==
TEST-PASS | /Users/sayrer/dev/mc-debug/_tests/xpcshell/crashreporter/unit/test_crashreporter.js | [run_test : 83] ==

This shows that the problem is the bits of the test that set/unset the exception handler. Apparently there's some kind of race here that winds up with the handler thread accessing freed memory, which is bad news. If I comment out the parts of the test that disable the crash reporter, the valgrind warnings go away. I think I might just comment those out for now, to get rid of the random orange, and figure out a Breakpad fix later. When we actually run Firefox we only set the exception handler on startup and unset it right before shutdown, so it's not like this is something we'd hit in normal app usage.
Disabled those bits of the test:

I'll reenable them when we get a fix upstream and pick it up in our copy. Until then I'm closing this bug because this intermittent failure will go away, and there's a Breakpad issue filed to track the root cause.
Assignee: nobody → ted.mielczarek
Closed: 12 years ago
Resolution: --- → FIXED
Flags: in-testsuite+
Whiteboard: [orange] → [c-n: comment 4 to m-1.9.2] [disabled parts of test] [orange]
Target Milestone: --- → mozilla1.9.3a1
(In reply to comment #4)
Whiteboard: [c-n: comment 4 to m-1.9.2] [disabled parts of test] [orange] → [disabled parts of test] [orange]
Nothing for QA to do here for 1.9.2 release.
Whiteboard: [disabled parts of test] [orange] → [disabled parts of test] [orange] [qa-ntd-192]
Whiteboard: [disabled parts of test] [orange] [qa-ntd-192] → [disabled parts of test] [qa-ntd-192]
You need to log in before you can comment on or make changes to this bug.