Open Bug 1282862 Opened 4 years ago Updated 2 years ago
Intermittent failure, PR
_ASSERT during xpcshell shutdown on Mac
This seems to happen in basically every test.
Depends on: 1282522
Depends on: 1282915
Depends on: 1283321
Depends on: 1283509
Is anybody actually working on this or should we just continue to file dupes indefinitely?
All these crashes are the same and are only happened in xpcshell child test in OS X debug build but we lost the assertion info in the log for further analysis. ni :gps for bug 1282522 to help to identify the reason of the assertion.
Flags: needinfo?(btseng) → needinfo?(gps)
I'm not actively working on bug 1282522. I'll send an email to auto-tools to see if we can find an owner.
I have a candidate patch for bug 1282522 that I ran through try with some re-triggers. The results are here: https://treeherder.mozilla.org/#/jobs?repo=try&revision=8e592ef51b64d348f8e5271721190257bcc3a09b 4 of the jobs contain failures that appear to match this pattern (2 are in indexedDB tests). All 4 point to the assertion at http://searchfox.org/mozilla-central/rev/bcc9ea6947878ca6378e5b7d6f08c1c090ed9eb7/nsprpub/pr/src/pthreads/ptthread.c#870 in _pt_thread_death.
(In reply to Chris Manchester (:chmanchester) from comment #4) > 4 of the jobs contain failures that appear to match this pattern (2 are in > indexedDB tests). All 4 point to the assertion at > http://searchfox.org/mozilla-central/rev/ > bcc9ea6947878ca6378e5b7d6f08c1c090ed9eb7/nsprpub/pr/src/pthreads/ptthread. > c#870 in _pt_thread_death. thanks for pointing out this!
I am now working on bug 1300454 or bug 1286210 more specifically in priority which happens more frequent according to the orange robot's summary. I'll revisit this later.
ICYMI, bug 1282522 landed, which means test output should contain stderr if we crash on shutdown. Have fun finding crashes!
After more observation in treeherder: https://treeherder.mozilla.org/#/jobs?repo=try&revision=3fec30eb0e24&selectedJob=28481069 This is more likely a common issue in xpcshell test instead of an IDB issue while doing run_test_in_child() in OS X debug build. We can see all those failures caused by assertion are happened at nsprpub/pr/src/pthreads/ptthread.c#870 in _pt_thread_death and all these failed tests are run with run_test_in_child(): http://searchfox.org/mozilla-central/search?q=run_test_in_child&case=false®exp=false&path=
Assignee: btseng → nobody
Component: DOM: IndexedDB → XPCShell Harness
Product: Core → Testing
Ted: You know the xpcshell child process foo better than anyone (I think). Care to weigh in regarding comment #8?
The logs from that try run apparently expired. :-( Bevis: can you find me an instance of this with a log that still exists?
Flags: needinfo?(ted) → needinfo?(btseng)
I've re-triggered 200 trials again and the failed ones(1 in idb 6 in netwerk) with the same symptom are filtered as unclassified failures for your reference: https://treeherder.mozilla.org/#/jobs?repo=try&revision=3fec30eb0e24&filter-resultStatus=testfailed&filter-resultStatus=busted&filter-resultStatus=exception&filter-resultStatus=pending&filter-resultStatus=running&filter-classifiedState=unclassified These assertions all happened after test is completed. BTW, for IDB, these test scripts run in both xpcshell test and mochitest but only died in xpcshell-child process. Not pretty sure if there is something we have to take more care about when test is shutting down. If it's still more related to each implementation instead of the test harness, please let me know, thanks!
Someone CCed me on bug 1295139, which has a suspiciously similar set of crashes, and in bug 1295139 comment 17 jld proposed a pretty sensible-sounding analysis. I bet it's the same root cause.
This is basically permafailing now on OSX debug.
The crash happens in various XPCShell tests, and the permafailing one recently in central and inbound is browser/components/sessionstore/test/unit/test_startup_invalid_session.js. We need test harness or sessionstore owners' help to analyze this instead.
Moving to p3 because no activity for at least 24 weeks.
Priority: P1 → P3
You need to log in before you can comment on or make changes to this bug.