1867677 - Crash in [@ js::wasm::CodeRange::kind] by profiler during lazy stub allocation

Status: NEW

(Core :: JavaScript: WebAssembly, defect, P2)

Description

[Andrew McCreight [:mccr8]]

Crash report: https://crash-stats.mozilla.org/report/index/033d8b08-c662-4c9d-a255-6b8ab0231129

Reason: EXC_BAD_ACCESS / KERN_INVALID_ADDRESS

Top 10 frames of crashing thread:

0  XUL  js::wasm::CodeRange::kind const  js/src/wasm/WasmCodegenTypes.h:429
0  XUL  js::wasm::CodeRange::isInterpEntry const  js/src/wasm/WasmCodegenTypes.h:458
0  XUL  js::wasm::ProfilingFrameIterator::operator++  js/src/wasm/WasmFrameIter.cpp:1570
1  XUL  JS::ProfilingFrameIterator::operator++  js/src/vm/Stack.cpp:489
2  XUL  ExtractJsFrames  tools/profiler/core/platform.cpp:1842
3  XUL  DoSharedSample  tools/profiler/core/platform.cpp:2531
4  XUL  DoSyncSample const  tools/profiler/core/platform.cpp:2586
4  XUL  mozilla::profiler::ThreadRegistration::OnThreadRef::WithConstLockedRWOnThread<DoSyncSample const  tools/profiler/public/ProfilerThreadRegistration.h:188
4  XUL  DoSyncSample const  tools/profiler/core/platform.cpp:2584
4  XUL  mozilla::profiler::ThreadRegistration::WithOnThreadRef<DoSyncSample  tools/profiler/public/ProfilerThreadRegistration.h:285

Null crashes. In this one, maybe codeRange_ is null?

Comment 1

[Ryan Hunt [:rhunt] (on leave until early May)]

Whoah. From the report, we're:

1. Running EnsureEntryStubs for calling a wasm function with a lazy generated entry point
2. Which is mutating a CodeRanges vector by growing it
3. Which triggers profiler::profiler_add_native_allocation_marker
4. Which then goes into DoSyncSample
5. Which iterates over the stack using JitFrameIter
6. Which looks like it's then accessing the malformed CodeRanges vector

Gonna need to look into our profiler integration a bit to find a fix.

Comment 2

[Ryan Hunt [:rhunt] (on leave until early May)]

Actually, I'm less sure what's going on here now. I'm not sure how the wasm::FrameIter could be accessing the LazyStubSegment that is being created further up on the stack, because that would require the lazy stub code we're generating to be called and on the call stack. A test case would be great here, but probably hard to make.

Comment 3

[BugBot [:suhaib / :marco/ :calixte]]

The bug is linked to a topcrash signature, which matches the following criterion:

• Top 10 desktop browser crashes on nightly

:rhunt, could you consider increasing the severity of this top-crash bug?

For more information, please visit BugBot documentation.

Comment 4

[Ryan Hunt [:rhunt] (on leave until early May)]

The topcrash signature appears to almost always be from applications that are having a wasm trap, and don't have any profiler frames involved. I think it's a separate issue. Will file a separate issue for it.