Closed Bug 1882423 Opened 10 months ago Closed 25 days ago

[meta] Crash in [@ js::IsProxy] from various code paths

Categories

(Core :: JavaScript Engine, defect, P3)

Other
All
defect

Tracking

()

RESOLVED DUPLICATE of bug 1928412
Tracking Status
firefox125 --- affected

People

(Reporter: release-mgmt-account-bot, Unassigned)

References

(Blocks 2 open bugs)

Details

(Keywords: crash, meta, topcrash)

Crash Data

Crash report: https://crash-stats.mozilla.org/report/index/977a98d1-2a4d-4b20-b422-532440240226

Reason: EXCEPTION_ACCESS_VIOLATION_READ

Top 10 frames of crashing thread:

0  xul.dll  js::IsProxy  js/public/Proxy.h:384
0  xul.dll  js::IsWrapper  js/public/Wrapper.h:393
0  xul.dll  js::IsCrossCompartmentWrapper  js/public/Wrapper.h:397
0  xul.dll  JS::GetNonCCWObjectGlobal  js/src/jsapi.cpp:1192
0  xul.dll  xpc::NativeGlobal  js/xpconnect/wrappers/WrapperFactory.cpp:787
1  xul.dll  mozilla::dom::AutoJSAPI::Init  dom/script/ScriptSettings.cpp:431
1  xul.dll  nsMessageManagerScriptExecutor::TryCacheLoadAndCompileScript  dom/base/nsFrameMessageManager.cpp:1273
1  xul.dll  nsMessageManagerScriptExecutor::LoadScriptInternal  dom/base/nsFrameMessageManager.cpp:1200
2  xul.dll  mozilla::dom::ContentProcessMessageManager::LoadScript  dom/base/ContentProcessMessageManager.cpp:119
3  xul.dll  mozilla::dom::ContentChild::RecvLoadProcessScript  dom/ipc/ContentChild.cpp:2320

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

  • First crash report: 2023-12-28
  • Process type: Multiple distinct types
  • Is startup crash: No
  • Has user comments: No
  • Is null crash: Yes - 14 out of 25 crashes happened on null or near null memory address
Component: General → JavaScript Engine

So, looking at the stack here I actually think this is an implementation error in ContentProcessMessageManager::LoadScript.

The problem is that this function calls GetOrCreateWrapper, which is a fallible operation, but never actually checks to see if the wrapper allocation succeeded. If wrapper allocation fails here, then the next point where we dereference the pointer is the stack highlighted here.

Component: JavaScript Engine → DOM: Core & HTML
Component: DOM: Core & HTML → DOM: Content Processes
Summary: Crash in [@ js::IsProxy] → Crash in [@ js::IsProxy] from ContentProcessMessageManager::LoadScript

That makes sense for the crash in comment 0. This signature is pretty bad, unfortunately, so I'm not sure how common that specific crash is. I looked at the most common proto signatures for this crash and didn't see any other instances of message manager thing, at least on release.

Severity: -- → S3

This signature is pretty bad, unfortunately, so I'm not sure how common that specific crash is.

Yeah, this looks a bit like a meta crash bug with many different causes. I'd propose to remove the ContentProcessMessageManager::LoadScript from the title here and move it to some more general component while filing new bugs for concrete things to improve like this.

Depends on: 1883869

I hope it is fair to keep the signature in the Javascript world, even though reasons might be manifold.

Component: DOM: Content Processes → JavaScript Engine
Keywords: meta
Summary: Crash in [@ js::IsProxy] from ContentProcessMessageManager::LoadScript → [meta] Crash in [@ js::IsProxy] from various code paths

We could add a bunch of these JS predicate/getter helpers to the skip list though I'm not sure how useful the result would be. The volume here is just not that high.

Yeah, most of these crashes don't have much actionable; the signature covers a whole range of things.

Severity: S3 → S4
Priority: -- → P3

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

  • Top 10 desktop browser crashes on nightly

For more information, please visit BugBot documentation.

Keywords: topcrash

Looks like there was a one-day spike in build 20241107212807 (with 160 crashes). There are two other builds since then, which have 4 and 10 crashes respectively, so it might have been some sort of transient problem with that particular build.

Maybe something landed and was backed out / fixed?

It appears that all of the crashes involved calling xpc::NativeGlobal for a JSObject* of 0x0007800000000000, which is not a valid pointer.

Ah, this is the same set of crashes that caused us to back out bug 1928412! Duping there.

Status: NEW → RESOLVED
Closed: 25 days ago
Duplicate of bug: 1928412
Resolution: --- → DUPLICATE

I realized after closing this that we could leave it open as a long-term tracking bug for this signature, but I think it's currently too broad. The existing crashes appear to be dominated by hardware noise. If there's another spike in the future, we can open a bug with a more precise signature.

You need to log in before you can comment on or make changes to this bug.