Crash in [@ mozilla::detail::MutexImpl::unlock | js::GCParallelTask::join] on Mac
Categories
(Thunderbird :: General, defect)
Tracking
(Not tracked)
People
(Reporter: wsmwk, Unassigned)
References
Details
(Keywords: crash)
Crash Data
#117 crash for Thunderbird 78.7.1
Crash report: https://crash-stats.mozilla.org/report/index/5036204a-6dd5-4ea5-bf3a-abfa70210221
Reason: EXC_BAD_ACCESS / EXC_I386_GPFLT
Top 10 frames of crashing thread:
0 XUL js::GCMarker::eagerlyMarkChildren js/src/gc/Marking.cpp:1260
1 XUL js::GCMarker::processMarkStackTop js/src/gc/Marking.cpp:2067
2 XUL js::GCMarker::lazilyMarkChildren js/src/gc/Marking.cpp:1582
3 XUL js::GCMarker::markUntilBudgetExhausted js/src/gc/Marking.cpp:1853
4 XUL js::gc::GCRuntime::performSweepActions js/src/gc/GC.cpp:6150
5 XUL js::gc::GCRuntime::incrementalSlice js/src/gc/GC.cpp:6694
6 libmozglue.dylib mozilla::detail::MutexImpl::unlock mozglue/misc/Mutex_posix.cpp:121
7 XUL js::GCParallelTask::join js/src/gc/GCParallelTask.cpp:66
8 XUL js::gc::GCRuntime::gcCycle js/src/gc/GC.cpp:7104
9 XUL js::gc::GCRuntime::collect js/src/gc/GC.cpp:7315
bp-4e979265-2f6e-441b-ac6f-de8630210220
bp-6bd930bb-3913-42e4-a224-e12e50210220
Comment 1•4 years ago
|
||
Crash at https://hg.mozilla.org/releases/mozilla-esr78/file/tip/js/src/gc/Marking.cpp#l1260 - if base is null it will crash
https://searchfox.org/mozilla-central/rev/7bb1cc6abf6634b2a20f71935e1e519e73402b63/js/src/gc/Marking.cpp#1251
Is there a hasBase() call missing?
Comment 2•4 years ago
|
||
(In reply to Magnus Melin [:mkmelin] from comment #1)
The addresses given the crash reports are not null though. base is never null here.
Comment 3•4 years ago
|
||
These stacks are messed up. The "MutexImpl::unlock | GCParallelTask::join" part is unrelated to the rest of the stack. I don't know why these crashes are being classified based on that part. They are really crashes in GCMarker::eagerlyMarkChildren or GCMarker::processMarkStackTop which are likely memory corruption and for which we have several open bugs.
Comment 4•4 years ago
|
||
(In reply to Jon Coppeard (:jonco) from comment #3)
These stacks are messed up. The "MutexImpl::unlock | GCParallelTask::join" part is unrelated to the rest of the stack. I don't know why these crashes are being classified based on that part. They are really crashes in GCMarker::eagerlyMarkChildren or GCMarker::processMarkStackTop which are likely memory corruption and for which we have several open bugs.
Some mutex frames got added to the "sentinel" list, which I guess means that Socorro digs through any and all frames if it sees that somewhere. With some of these weird stacks, the results are not good. Bug 1692983 has been filed about reverting that change.
Comment 5•4 years ago
|
||
(In reply to Andrew McCreight [:mccr8] from comment #4)
Thanks, I thought I had seen something like this before.
Reporter | ||
Comment 6•3 years ago
|
||
Thanks for the analysis
Description
•