#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

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?

(In reply to Magnus Melin [:mkmelin] from comment #1)
The addresses given the crash reports are not null though. base is never null here.

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.

(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.

(In reply to Andrew McCreight [:mccr8] from comment #4)
Thanks, I thought I had seen something like this before.

Thanks for the analysis