2011915 - Crash in [@ mozilla::dom::Event_Binding::get_target]

Status: NEW

(Core :: JavaScript Engine, defect, P5)

Description

[Sebastian Hengst [:aryx] (needinfo me if it's about an intermittent or backout)]

Crash report: https://crash-stats.mozilla.org/report/index/4827ea22-c74c-4d25-896a-624db0260122

79 crash reports from 69 installs of Firefox 147.0 and 147.0.1 on Windows, half of them more than an hour after the application had been launched. The crash stack was corrupted for 6/6 reports checked.

Reason:

EXCEPTION_ACCESS_VIOLATION_READ

Top 10 frames:

0  xul.dll  mozilla::dom::Event_Binding::get_target(JSContext*, JS::Handle<JSObject*>, vo...  dom/bindings/EventBinding.cpp:262
1  ?  @0x000000d9f0b82b0f
2  ?  @0x000000d9f0dbc706
3  ?  @0x000000d9f0ee1145
4  ?  @0x000000d9f0b8142b
5  xul.dll  EnterJit(JSContext*, js::RunState&, unsigned char*)  js/src/jit/Jit.cpp:107
5  xul.dll  js::jit::MaybeEnterJit(JSContext*, js::RunState&)  js/src/jit/Jit.cpp:255
5  xul.dll  js::RunScript(JSContext*, js::RunState&)  js/src/vm/Interpreter.cpp:450
5  xul.dll  js::InternalCallOrConstruct(JSContext*, JS::CallArgs const&, js::MaybeConstru...  js/src/vm/Interpreter.cpp:618
5  xul.dll  InternalCall(JSContext*, js::AnyInvokeArgs const&, js::CallReason)  js/src/vm/Interpreter.cpp:653

Comment 1

[Olli Pettay [:smaug][[e-mail]]]

At least not DOM Events :) Either webidl bindings, Spidermonkey, or something totally different.

Comment 2

[Iain Ireland [:iain]]

Peeking at a minidump, the instructions around the crash site look like this:

7ffaec20230a:    int3
7ffaec20230b:    int3
7ffaec20230c:    int3
7ffaec20230d:    int3
7ffaec20230e:    int3
7ffaec20230f:    int3
7ffaec202310:    push   %r15            <-- function entry
7ffaec202312:    push   %r14
7ffaec202314:    push   %r12
7ffaec202316:    push   %rsi
7ffaec202317:    push   %rdi
7ffaec202318:    push   %rbx
7ffaec202319:    sub    $0x48,%rsp
7ffaec20231d:    mov    %r9,%rsi
7ffaec202320:    mov    %rcx,%rdi
7ffaec202323:    mov    0x6792dd6(%rip),%rax        # 0x7ffaf2995100
7ffaec20232a:    xor    %rsp,%rax
7ffaec20232d:    mov    %rax,0x40(%rsp)
7ffaec202332:    mov    0x98(%rcx),%rcx
7ffaec202339:    mov    %rcx,0x38(%rsp)
7ffaec20233e:    test   %rcx,%rcx
7ffaec202341:    jne    0x7ffaec202530
7ffaec202347:    mov    0x28(%r8),%rax    <---- we crash loading at an offset from r8
^^^^^^^^^^^^^    ^^^^^^^^^^^^^^^^^^^^^^
7ffaec20234b:    mov    0x50(%rax),%rcx

On Windows, r8 is the third argument. The reported value of r8 is 0x0000000000000006. It looks like we're calling this code with void_self of 6, which isn't ideal. It looks like all the crashes have the exact same value of void_self. There are no crashes with this signature from non-Windows platforms; not sure if that's a clue or not.

We're calling directly from jitcode. Unfortunately, the crash reports don't give us much information about what's going on in the caller.

The consistent value of 6 is weird. I was curious and looked for other crashes with a crash address of 0x000000000000002e (which is what you get if you call a DOM getter binding with void_self=6, then call GetTarget on it). Faceting on signatures, there are a number of event getters seeing the same crash. The top three all have bugs open. One is this bug; the other two are bug 1973138 and bug 1972341, both of which have been identified as CPU-specific problems with Raptor Lake. Indeed, the crashes in this bug also appear to be almost entirely Raptor Lake.

This is a CPU bug.