1918917 - Crash in [@ mozilla::extensions::URLInfo::Host]

Status: RESOLVED INVALID

(WebExtensions :: General, defect)

Description

[Roger Yang [:royang]]

Crash report: https://crash-stats.mozilla.org/report/index/d44d463c-41db-481a-a6ea-fa1230240914

Reason: SIGSEGV / SEGV_MAPERR

Top 10 frames:

0  libxul.so  mozilla::extensions::URLInfo::Host() const  toolkit/components/extensions/MatchPattern.cpp:130
0  libxul.so  mozilla::extensions::URLInfo::HostAtom() const  toolkit/components/extensions/MatchPattern.cpp:137
1  libxul.so  mozilla::extensions::WebExtensionPolicy::IsRestrictedURI(mozilla::extensions:...  toolkit/components/extensions/WebExtensionPolicy.cpp:541
2  libxul.so  mozilla::extensions::WebExtensionPolicyCore::CanAccessURI(mozilla::extensions...  toolkit/components/extensions/WebExtensionPolicy.cpp:264
3  libxul.so  mozilla::extensions::WebExtensionPolicy::CanAccessURI(mozilla::extensions::UR...  toolkit/components/extensions/WebExtensionPolicy.h:249
3  libxul.so  mozilla::extensions::ChannelWrapper::GetTraceableChannel(mozilla::extensions:...  toolkit/components/extensions/webrequest/ChannelWrapper.cpp:821
4  libxul.so  mozilla::extensions::WebRequestService::GetTraceableChannel(unsigned long, mo...  toolkit/components/extensions/webrequest/WebRequestService.cpp:43
5  libxul.so  mozilla::extensions::ChannelWrapper::GetRegisteredChannel(mozilla::dom::Globa...  toolkit/components/extensions/webrequest/ChannelWrapper.cpp:183
6  libxul.so  mozilla::dom::ChannelWrapper_Binding::getRegisteredChannel(JSContext*, unsign...  dom/bindings/ChannelWrapperBinding.cpp:1006
7  libxul.so  CallJSNative(JSContext*, bool (*)(JSContext*, unsigned int, JS::Value*), js::...  js/src/vm/Interpreter.cpp:491

Comment 1

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

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

• Top 10 AArch64 and ARM crashes on nightly

For more information, please visit BugBot documentation.

Comment 2

[Rob Wu [:robwu]]

Interestingly, crashstats shows that the crashes started spiking in 132. There was also a brief spike in 130 due to bug 1910110. After fixing the crash I added comprehensive test coverage in bug 1910243.

This is also Fenix-only; there are no such crashes in Firefox.

There are zero reported crashes in 131, so something must have changed in 132.

Aggregation of affected build IDs:

• 20240726035627 (130.0a1 - fixed by bug 1910110)
• 20240912092307 (132.0a1)
• 20240913100931 (132.0a1)

Comment 3

[Rob Wu [:robwu]]

:royang mentioned that the changelog that introduced the crashes was https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=169a59fe35f8&tochange=8ea146da980a
and that the changelog that resulted in the disappearance of crashes is https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=b0716d2d5fef&tochange=b91e1b615932

I noticed that in the "regression" range, the new crash reporter was enabled (bug 1905774),
and in the "fixed" range, the new crash reporter was disabled again (bug 1918750).

If this observation is correct, then it is possible for the regression to be around much longer, but only visible by its stack "thanks to the new crash reporter". In this case, either the crashes were not sent before, or they were reported with a different signature.

:boek - is my analysis likely? If yes, do you know where to find older crash reports relating to this bug?

Comment 4

[Rob Wu [:robwu]]

:royang theorized that the crash reports may be old crash reports that were submitted when the new crash reporter was enabled. In this case, the metadata of the crash report would reflect the application at the time of submission, not the time of the crash.

When I look at the crash report from bp-d44d463c-41db-481a-a6ea-fa1230240914, the metadata claims that the application is 132.0a1. But when I click through on the linked source code in the crash report, I get a link to https://hg.mozilla.org/mozilla-central/file/69a2460cfcb3a816edaf95e35971cdabc9ce13b7/toolkit/components/extensions/webrequest/ChannelWrapper.cpp#l821, which predates the patch from bug 1910110.

Given the circumstances, my firm conclusion is therefore that the observed crashes are old crashes that are resurfacing, and not an unexpected new regression.

I'll mark this as "regressed by bug 1905774" to signal that the temporarily enabled new crash reporter resulted in confusing reports.
And I'll also mark as "depends on bug 1918750" to signal that disabling the new crash reporter resolved the unexpected incoming crashes.