1814490 - Crash in [@ mozilla::NullPrincipal::Create] MOZ_RELEASE_ASSERT(uri->SchemeIs(NS_NULLPRINCIPAL_SCHEME))

Status: NEW

(Core :: DOM: Navigation, defect, P5)

Description

[Chris Peterson [:cpeterson]]

@ Nika, I think this MOZ_RELEASE_ASSERT(uri->SchemeIs(NS_NULLPRINCIPAL_SCHEME)) failure is a regression in Firefox 109 from noopener bug 1694993. Is this assertion failure a concern?

All 300+ crash reports are from just 2-3 Android users (running a five year old version of Android on 32-bit ARM devices), so maybe their crashes are an anomaly and we can ignore these crashes for now.

Crash report: https://crash-stats.mozilla.org/report/index/e2788dcb-3c3f-4151-827d-3b0bf0230127

Reason: SIGSEGV / SEGV_MAPERR

Top 10 frames of crashing thread:

0  libxul.so  mozilla::NullPrincipal::Create  caps/NullPrincipal.cpp:60
1  libxul.so  mozilla::NullPrincipal::CreateWithoutOriginAttributes  caps/NullPrincipal.cpp:73
2  libxul.so  nsContentUtils::Init  dom/base/nsContentUtils.cpp:788
3  libxul.so  nsLayoutStatics::Initialize  layout/build/nsLayoutStatics.cpp:165
3  libxul.so  nsLayoutModuleInitialize  layout/build/nsLayoutModule.cpp:104
4  libxul.so  nsComponentManagerImpl::Init  xpcom/components/nsComponentManager.cpp:371
5  libxul.so  NS_InitXPCOM  xpcom/build/XPCOMInit.cpp:421
6  libxul.so  ScopedXPCOMStartup::Initialize  toolkit/xre/nsAppRunner.cpp:2076
6  libxul.so  XREMain::XRE_main  toolkit/xre/nsAppRunner.cpp:5969
7  libxul.so  XRE_main  toolkit/xre/nsAppRunner.cpp:6029

Comment 1

[Nika Layzell [:nika] (ni? for response)]

This is very confusing, as the stack is in NullPrincipal::CreateWithoutOriginAttributes, which means that it is creating a brand-new null principal from scratch, so the returned URI should definitely have the null principal scheme.

Looking at the crash I don't see any crash reason being recorded, which means that the crash could potentially be somewhere other than being caused by an assertion failure. One possibility is that the uri value is nullptr, and we're crashing on the access to the vtable.

Looking at the code for NullPrincipal::CreateURI, we could return nullptr if mutator.Finalize fails - this is guarded by a MOZ_ALWAYS_SUCCEEDS (https://searchfox.org/mozilla-central/rev/2d820afafbe62b0148e2766a4d371556edefe36f/caps/NullPrincipal.cpp#147), but that will be ignored in release builds IIRC.

As network.uri.useDefaultURI is false by default on all platforms (https://searchfox.org/mozilla-central/rev/2d820afafbe62b0148e2766a4d371556edefe36f/modules/libpref/init/StaticPrefList.yaml#11951-11955), we will be using the nsSimpleURI implementations of the mutator methods. As this caller definitely doesn't have a precursor URI, the only method of note is the call to SetSpec with the string "moz-nullprincipal:{uuid}", which will call through to SetSpecInternal (https://searchfox.org/mozilla-central/rev/2d820afafbe62b0148e2766a4d371556edefe36f/netwerk/base/nsSimpleURI.cpp#267). Assuming the user didn't tamper with network.url.max-length, the URI won't need any escaping, so can't fail there, and AFAICT could only possibly fail on the fallible small-string allocation which specifies the string's path (https://searchfox.org/mozilla-central/rev/2d820afafbe62b0148e2766a4d371556edefe36f/netwerk/base/nsSimpleURI.cpp#415). An OOM this early during startup on such a specific fallible allocation of a tiny string seems quite unlikely, but given it's only happened to a small number of users, perhaps it's possible?

Overall I'm not sure there's much actionable here other than potentially strengthening the MOZ_ALWAYS_SUCCEEDS check to report NS_ABORT_OOM of some kind if it fails with NS_ERROR_OUT_OF_MEMORY.

Comment 2

[Chris Peterson [:cpeterson]]

Thanks. I'll drop this bug to priority P5 for now. I don't see any crash reports from Android or desktop after 109.

Comment 3

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

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

Comment 4

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

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

• Top 10 AArch64 and ARM crashes on beta

:zcorpan, could you consider increasing the severity of this top-crash bug?

For more information, please visit BugBot documentation.

Comment 5

[Hsin-Yi Tsai (she/her)[:hsinyi]]

It looks like the recent spike was handled in bug 1972225.

Comment 6

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

Based on the topcrash criteria, the crash signature linked to this bug is not a topcrash signature anymore.

For more information, please visit BugBot documentation.