1971222 - JS_SWEPT_TENURED_PATTERN crash in [@ js::GlobalObject::maybeWindowProxy]

Status: RESOLVED INCOMPLETE

(Core :: JavaScript Engine, defect, P3)

Description

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

Crash report: https://crash-stats.mozilla.org/report/index/6131508a-997e-4ee2-84ce-8cb950250521

Reason: EXCEPTION_ACCESS_VIOLATION_READ

Top 10 frames of crashing thread:

0  xul.dll  js::GlobalObject::maybeWindowProxy const  js/src/vm/GlobalObject.h:1047
0  xul.dll  js::detail::IsWindowSlow  js/src/vm/WindowProxy.cpp:69
0  xul.dll  js::IsWindow  js/public/friend/WindowProxy.h:74
0  xul.dll  JS::Compartment::getNonWrapperObjectForCurrentCompartment  js/src/vm/Compartment.cpp:248
0  xul.dll  JS::Compartment::wrap  js/src/vm/Compartment.cpp:360
1  xul.dll  JS::Compartment::wrap  js/src/vm/Compartment.cpp:424
1  xul.dll  JS::Compartment::wrap  js/src/vm/Compartment.cpp:443
2  xul.dll  JS_WrapPropertyDescriptor  js/src/jsfriendapi.cpp:178
2  xul.dll  xpc::XrayTraits::resolveOwnProperty  js/xpconnect/wrappers/XrayWrapper.cpp:1668
3  xul.dll  xpc::JSXrayTraits::resolveOwnProperty  js/xpconnect/wrappers/XrayWrapper.cpp:522

By querying Nightly crashes reported within the last 2 months, here are some insights about the signature:

• First crash report: 2025-04-10
• Process type: Content
• Is startup crash: No
• Has user comments: No
• Is null crash: Yes - 4 out of 10 crashes happened on null or near null memory address
• Is use after free crash: Yes - 6 out of 10 crashes happened on or near an allocator poison value

Comment 1

[Andrew McCreight [:mccr8]]

This one is interesting because about 60% of the 300 crashes in the last 6 months are on the JS_SWEPT_TENURED_PATTERN, 0x4b. The crash in comment 0 has Xrays in the stack, but I don't think that's the most common thing.

There are 186 crashes on poison values with this signature in the last 6 months.

107 of them have Element_Binding::get_classList() in the proto signature (example: bp-cc77b6cc-a8ce-49b6-bfde-36e200250410), with a stack something like:

0  xul.dll  js::GlobalObject::maybeWindowProxy() const  js/src/vm/GlobalObject.h:1047
0  xul.dll  js::detail::IsWindowSlow(JSObject*)  js/src/vm/WindowProxy.cpp:69
0  xul.dll  js::IsWindow(JSObject*)  js/public/friend/WindowProxy.h:74
0  xul.dll  JS::Compartment::getNonWrapperObjectForCurrentCompartment(JSContext*, JS::Han...  js/src/vm/Compartment.cpp:248
0  xul.dll  JS::Compartment::wrap(JSContext*, JS::MutableHandle<JSObject*>)  js/src/vm/Compartment.cpp:360
1  xul.dll  JS::Compartment::wrap(JSContext*, JS::MutableHandle<JS::Value>)  js/src/vm/Compartment-inl.h:103
1  xul.dll  JS_WrapValue(JSContext*, JS::MutableHandle<JS::Value>)  js/src/jsapi.cpp:579
2  xul.dll  mozilla::dom::binding_detail::DoGetOrCreateDOMReflector(JSContext*, nsDOMToke...  dom/bindings/BindingUtils.h:1361
2  xul.dll  mozilla::dom::GetOrCreateDOMReflector(JSContext*, nsDOMTokenList*, JS::Mutabl...  dom/bindings/BindingUtils.h:1380
2  xul.dll  mozilla::dom::Element_Binding::get_classList(JSContext*, JS::Handle<JSObject*...  dom/bindings/ElementBinding.cpp:2071

51 of them have Element_Binding::get_attributes in the proto signature (example:bp-ea9c0db0-3e4a-434e-9078-069b60250525), with a similar stack to get_classlist.

I'm not sure if this is a SpiderMonkey issue or a DOM bindings issue.

Comment 2

[Andrew McCreight [:mccr8]]

That being said, it looks like the crash volume for poison crashes with this signature dropped off massively after 138.0.1, and later versions have been out for awhile, so maybe something got fixed? I don't see any security advisories except for 138.0.4, which was our Pwn2Own release. It doesn't look like there was a signature change, as I don't see anything else with Element_Binding::get_classList in the proto signature that is a poison crash.

Comment 3

[Andrew McCreight [:mccr8]]

Okay, so I only see a single crash from a build after the end of April that has this signature and is on a poison value: bp-e2778c5f-e137-46e3-9ad3-246220250609

0  xul.dll  js::GlobalObject::maybeWindowProxy() const  js/src/vm/GlobalObject.h:1060
0  xul.dll  js::detail::IsWindowSlow(JSObject*)  js/src/vm/WindowProxy.cpp:69
0  xul.dll  js::IsWindow(JSObject*)  js/public/friend/WindowProxy.h:74
0  xul.dll  JS::Compartment::getNonWrapperObjectForCurrentCompartment(JSContext*, JS::Han...  js/src/vm/Compartment.cpp:248
0  xul.dll  JS::Compartment::wrap(JSContext*, JS::MutableHandle<JSObject*>)  js/src/vm/Compartment.cpp:360
1  xul.dll  JS::Compartment::wrap(JSContext*, JS::MutableHandle<JS::Value>)  js/src/vm/Compartment-inl.h:103
1  xul.dll  JS_WrapValue(JSContext*, JS::MutableHandle<JS::Value>)  js/src/jsapi.cpp:579
2  xul.dll  mozilla::dom::binding_detail::DoGetOrCreateDOMReflector(JSContext*, nsDOMAttr...  dom/bindings/BindingUtils.h:1328
2  xul.dll  mozilla::dom::GetOrCreateDOMReflector(JSContext*, nsDOMAttributeMap*, JS::Mut...  dom/bindings/BindingUtils.h:1347
2  xul.dll  mozilla::dom::Element_Binding::get_attributes(JSContext*, JS::Handle<JSObject...  dom/bindings/ElementBinding.cpp:2204

So it doesn't seem like there's actually a big ongoing issue any more. I'm not sure how much we can really derive from a single crash. (The report in comment 0 is on a newer build, but is on null instead of a poison value.)

Comment 4

[Andrew McCreight [:mccr8]]

Jan, is there anything we can do with this? Or maybe we could close it as incomplete if there's only one scary crash since the end of April? Thanks.

Comment 5

[Matthew Gaudet (he/him) [:mgaudet]]

I agree this looks scary, though the drop in volume is heartening.

It's unclear how actionable this will be unfortunately, so marking S3 for now.

Comment 6

[Steven DeTar [:sdetar]]

Actually, because it is a sec-high bug, we should mark it S2.

Comment 7

[Jan de Mooij [:jandem]]

(In reply to Andrew McCreight [:mccr8] from comment #4)

Jan, is there anything we can do with this? Or maybe we could close it as incomplete if there's only one scary crash since the end of April? Thanks.

I don't see anything obvious (stack traces suggest a garbage DOM reflector?) and if the crashes have mostly disappeared then closing seems reasonable.