1967257 - Crash in [@ OOM | unknown | nsPIDOMWindowInner::GetDoc]

Status: NEW

(Core :: JavaScript Engine, defect, P3)

Description

[Andrew McCreight [:mccr8]]

Crash report: https://crash-stats.mozilla.org/report/index/8927f82f-9f6b-441e-b3db-2bb540250518

Reason:

EXCEPTION_ACCESS_VIOLATION_READ

Top 10 frames:

0  xul.dll  RefPtr<mozilla::dom::Document>::operator!() const  mfbt/RefPtr.h:339
0  xul.dll  nsPIDOMWindowInner::GetDoc()  dom/base/nsPIDOMWindow.h:403
0  xul.dll  nsGlobalWindowInner::GetDocument()  dom/base/nsGlobalWindowInner.h:616
0  xul.dll  mozilla::dom::SetUseCounter(JSObject*, mozilla::UseCounter)  dom/bindings/BindingUtils.cpp:4062
1  xul.dll  mozilla::CycleCollectedJSRuntime::OnOutOfMemory()  xpcom/base/CycleCollectedJSRuntime.cpp:2092
1  xul.dll  mozilla::CycleCollectedJSRuntime::OutOfMemoryCallback(JSContext*, void*)  xpcom/base/CycleCollectedJSRuntime.cpp:1330
2  xul.dll  JSContext::onOutOfMemory()  js/src/vm/JSContext.cpp:277
3  xul.dll  js::NativeObject::growSlots(JSContext*, unsigned int, unsigned int)  js/src/vm/NativeObject.cpp:336
3  xul.dll  js::NativeObject::growSlotsForNewSlot(JSContext*, unsigned int, unsigned int)  js/src/vm/NativeObject.cpp:382
4  xul.dll  js::NativeObject::setShapeAndAddNewSlot(JSContext*, js::SharedShape*, unsigne...  js/src/vm/NativeObject-inl.h:598

Seen on the signature spike report. This code was added in bug 1964451.

Comment 1

[Andrew McCreight [:mccr8]]

It looks like we're in the middle of setting up a new global, so maybe the document isn't set yet?

Comment 2

[Andrew McCreight [:mccr8]]

The obvious fix here is to add a null check and not record anything in that case, but on the other hand it is a bit unfortunate because I think we're likely to see the most OOMs while setting up new globals. Maybe smaug or somebody has an idea about how we could deal with this situation better.

Comment 3

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

Set release status flags based on info from the regressing bug 1964451

Comment 4

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

The bug is marked as tracked for firefox140 (nightly). We have limited time to fix this, the soft freeze is in a day. However, the bug still isn't assigned.

:sdetar, could you please find an assignee for this tracked bug? Given that it is a regression and we know the cause, we could also simply backout the regressor. If you disagree with the tracking decision, please talk with the release managers.

For more information, please visit BugBot documentation.

Comment 5

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

I'm sort of confused by the signature. SetUseCounter already seems to have the null checking one would expect here. We're crashing inside of the RefPtr<>::operator!(), which means inferring based on the crash address 0xfff9800000000038, which is the same throughout, that this == 0xfff9800000000000 .

What's that address? mDoc should be default initialized, so... I'm not sure where this pointer is coming from

Comment 6

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

So that would be window = 0xfff9800000000000; window is computed here. I wonder sort of it CurrentGlobalOrNull is leading us astray here.

Comment 7

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

I'm going to write a patch based on Bug 1967257, which shows a problem happening earlier, and we'll see if that also fixes this signature at the same time.

Comment 8

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

Actually: given how close we are to the soft freeze, I'm actually going to get the original telemetry patch backed out, then I'll re-land the updated version from Bug 1967257 after the soft freeze is done.

Comment 9

[Donal Meehan [:dmeehan]]

Setting Fx140 to fixed since the regressor was backed out
https://bugzilla.mozilla.org/show_bug.cgi?id=1964451#c6