2063234 - Crash in [@ nsWrapperCache::GetWrapperMaybeDead]

Status: NEW

(Core :: DOM: Core & HTML, defect)

Description

[Calixte Denizet (:calixte)]

Crash report: https://crash-stats.mozilla.org/report/index/081481b1-5dc3-4334-836a-084690260813

Crash Reason:

SIGSEGV / SEGV_MAPERR at 0x0000000000000010

Top 10 frames:

0  libxul.so  nsWrapperCache::GetWrapper() const  dom/base/nsWrapperCacheInlines.h:26
1  libxul.so  mozilla::dom::ShadowRoot_Binding::get_host(JSContext*, JS::Handle<JSObject*>, vo...  dom/bindings/ShadowRootBinding.cpp:272
2  libxul.so  js::Call(JSContext*, JS::Handle<JS::Value>, JS::Handle<JS::Value>, js::AnyInvoke...  js/src/vm/Interpreter.cpp:711
3  libxul.so  js::Proxy::get(JSContext*, JS::Handle<JSObject*>, JS::Handle<JS::Value>, JS::Han...  js/src/proxy/Proxy.cpp:529
4  libxul.so  js::Proxy::get(JSContext*, JS::Handle<JSObject*>, JS::Handle<JS::Value>, JS::Han...  js/src/proxy/Proxy.cpp:529
5  libxul.so  js::Interpret(JSContext*, js::RunState&)  js/src/vm/Interpreter.cpp:2955
6  libxul.so  js::Call(JSContext*, JS::Handle<JS::Value>, JS::Handle<JS::Value>, js::AnyInvoke...  js/src/vm/Interpreter.cpp:711
7  libxul.so  mozilla::dom::EventListener::HandleEvent(mozilla::dom::BindingCallContext&, JS::...  dom/bindings/EventListenerBinding.cpp:62
8  libxul.so  mozilla::dom::JSWindowActorProtocol::HandleEvent(mozilla::dom::Event*)  dom/ipc/jsactor/JSWindowActorProtocol.cpp:204
9  libxul.so  mozilla::EventTargetChainItem::HandleEventTargetChain(nsTArray<mozilla::EventTar...  dom/events/EventDispatcher.cpp:528

There is 1 crash in nightly 155 with buildid 20260810093015.

Clouseau analysis (automated, 97% worth investigating — a calibrated estimate that this is worth someone's time, not that the changeset below caused it). The mechanism below fits the evidence but is not proven end-to-end:

The crash is a genuine null Element* (the ShadowRoot's host) flowing unchecked through mozilla::dom::ShadowRoot::Host() and mozilla::dom::binding_detail::DoGetOrCreateDOMReflector<Element> into nsWrapperCache::GetWrapper(), most plausibly because ShadowRoot::Unattach() nulled mHost (during UA-widget teardown, e.g. a <video>'s controls) while a JSWindowActorChild's mouse-event handler (matching code exists in PictureInPictureChild.sys.mjs's PictureInPictureToggleChild click case, and similarly in ContextMenuChild.sys.mjs) still reads shadowRoot.host without a null check.

The reported fault address 0x10 exactly matches the absolute byte offset of nsWrapperCache::mWrapper within EventTarget/nsINode/Element (nsISupports vtable at 0, nsWrapperCache subobject at +8, mWrapper at +8 within it = 0x10), which is the deterministic signature of a null this reaching GetWrapper() — not a hardware bit-flip as the weak (44% confidence) auto-annotation guessed.

Starting point — NOT a suspected cause: cafe8f49eb3f (bug 1665251) by Neil Deakin.

This changeset did not land in this build's pushlog window, so there is no evidence here that the crash is a recent regression from it; it is named only as the closest thing found on the crash path. If you know where this actually comes from, that correction is the most useful thing you could leave on this bug.

Code references:

• mozilla::dom::ShadowRoot::Host
• PictureInPictureToggleChild
• mozilla::dom::EventTarget

What the automated skeptic pass checked (its own words — a pass means the check succeeded, which is not always support for the conclusion):

• unverifiable recent-regressor-search — No changeset touching the crashing dispatch path (HandleEvent*) or ShadowRoot host lifecycle landed near the build date; closest-in-time EventListenerManager.cpp changes (Aug 7) only touch Add/RemoveEventListenerInternal, a different code path. Consistent with a long-standing latent race rather than a fresh regression.
• pass seed-candidate-noise — bug 2056804 diff only touches PresShell/nsIFrame content-visibility tracking; zero overlap with ShadowRoot/wrapper-cache/actor code.
• pass mechanism — Null-flow-through chain (Unattach -> Host -> DoGetOrCreateDOMReflector -> GetWrapper) verified structurally by re-reading each function body.
• pass deterministic-corroborator — EventTarget base-class order and field offsets re-verified; 0x10 fault address arithmetic holds under Itanium ABI this-adjustment reasoning.

:enndeakin, can you have a look please?

Filed automatically by Clouseau, which analyses nightly crashes with an LLM. Nothing above was written or checked by a human. Please close it as INVALID if it is wrong — that is useful feedback, not a nuisance.

Comment 1

[Neil Deakin (away until Sept 6)]

I think we can just triage this normally.

Comment 2

[kpatenio]

Looking at the crash report https://crash-stats.mozilla.org/report/index/081481b1-5dc3-4334-836a-084690260813, the first few frames point to dom/base/nsWrapperCache.h and dom/base/nsWrapperCacheInlines.h, suggesting there's a mismatch when we try to fetch a shadowRoot host. Guarding against a falseyshadowRoot in https://searchfox.org/firefox-main/source/toolkit/actors/PictureInPictureChild.sys.mjs#607 would feel like a bandaid fix if the problem is actually within the dom layer.

Passing this over to Core :: DOM: Core & HTML to confirm.