Crash in [@ MaybeMutex::ShouldLock]
Categories
(Core :: Layout, defect, P3)
Tracking
()
| Tracking | Status | |
|---|---|---|
| firefox-esr102 | --- | unaffected |
| firefox-esr115 | --- | unaffected |
| firefox115 | --- | unaffected |
| firefox116 | --- | affected |
| firefox117 | --- | affected |
People
(Reporter: aryx, Assigned: pbone)
Details
(Keywords: crash)
Crash Data
Attachments
(1 file)
6 crashes from 5+ installations - 1 with Firefox 116.0b6, 5 with 116.0b7. Beta 6 was the first beta built as "late beta" this time. All crashing installations have an Nvidia graphics card.
The crashes have style code in their stack.
Crash report: https://crash-stats.mozilla.org/report/index/8d64ac27-77dd-4d43-acd4-c70a40230725
Reason: EXCEPTION_ACCESS_VIOLATION_WRITE
Top 10 frames of crashing thread:
0 mozglue.dll MaybeMutex::ShouldLock memory/build/Mutex.h:256
0 mozglue.dll MaybeMutex::Lock memory/build/Mutex.h:228
0 mozglue.dll AutoLock<MaybeMutex>::AutoLock memory/build/Mutex.h:276
0 mozglue.dll arena_t::MallocSmall memory/build/mozjemalloc.cpp:3243
0 mozglue.dll arena_t::Malloc memory/build/mozjemalloc.cpp:3299
0 mozglue.dll BaseAllocator::malloc memory/build/mozjemalloc.cpp:4503
0 mozglue.dll Allocator<MozJemallocBase>::malloc memory/build/malloc_decls.h:51
0 mozglue.dll je_malloc memory/build/malloc_decls.h:51
1 xul.dll alloc::alloc::alloc /rustc/84c898d65adf2f39a5a98507f1fe0ce10a2b8dbc/library/alloc/src/alloc.rs:95
1 xul.dll alloc::alloc::Global::alloc_impl /rustc/84c898d65adf2f39a5a98507f1fe0ce10a2b8dbc/library/alloc/src/alloc.rs:177
|
||
Comment 1•2 years ago
|
||
I'm not sure how that function can crash on an invalid write? Mike, Paul, can you make any sense of it?
|
||
Comment 2•2 years ago
|
||
It's as if the arena_t address is 0. Paul, does it sound plausible to you that this could happen?
|
Assignee | |
Comment 3•2 years ago
|
||
maybe not null, but something that's close to null but isn't null. When I look at other crash reports with the same signature I see all different crash addresses (all ending in a 9) and they're all off-thread style code. There's one exception from the 18th of July whose call stack is completely different.
So I think that either BaseAllocator::mArena isn't initialised (or it's following a bad BaseAllocator pointer) or the arena in TLS isn't initialised properly. Glandium what do you think about how rust calls jemalloc here? Could it have a bad BaseAllocator pointer or net initialised that properly?
|
|
||
Comment 4•2 years ago
|
||
Sooo.... on x86-64 windows, offsetof(arena_t, mLock) is 0x20 and offsetof(MaybeMutex, mDoLock) is 0x28. That would put the arena pointer at 0xb1 in the specific crash from comment 0... I was kind of hoping it would be 0xe5... at least it would make some kind of sense.
I don't see how this could happen, except maybe some corruption of the thread local pointer to the thread local arena...
|
|
Assignee | |
Comment 6•2 years ago
|
||
I think we could land a patch with some assertions to try to tease out where the bad pointer is coming from. E.g. from TLS or BaseAllocator::mArena. I suspect TLS since all the crashes come from style threads.
|
|
Assignee | |
Comment 7•2 years ago
|
||
|
||
Updated•2 years ago
|
|
|
Assignee | |
Updated•2 years ago
|
|
||
Comment 9•2 years ago
|
||
| bugherder | ||
| Comment hidden (Intermittent Failures Robot) |
| Comment hidden (Intermittent Failures Robot) |
|
||
Comment 12•1 year ago
|
||
The leave-open keyword is there and there is no activity for 6 months.
:pbone, maybe it's time to close this bug?
For more information, please visit BugBot documentation.
|
|
Assignee | |
Comment 13•1 year ago
|
||
This is so rare that I think it's fine to close.
|
||
Updated•1 year ago
|
Description
•