Crash in [@ mozilla::Fuzzyfox::Fuzzyfox]
Categories
(Core :: Security, defect, P3)
Tracking
()
People
(Reporter: marcia, Assigned: tjr)
Details
(Keywords: crash, regression)
Crash Data
Attachments
(1 file)
47 bytes,
text/x-phabricator-request
|
RyanVM
:
approval-mozilla-beta+
|
Details | Review |
This bug is for crash report bp-02d21deb-a7d1-4c6c-b370-0b5350191105.
Seen while looking at release crash stats - startup crash which goes back to at least 69: https://mzl.la/2CcgVJc. On beta there is a correlation to Lavasoft:
45.83% in signature vs 00.22% overall) Module "LavasoftTcpService.dll" = true [57.89% vs 00.37% if platform_pretty_version = Windows 7]
Although it is a relatively small volume crash, since it is a startup crash I thought it was worth investigating why it might be happening.
Top 10 frames of crashing thread:
0 xul.dll mozilla::Fuzzyfox::Fuzzyfox toolkit/components/fuzzyfox/Fuzzyfox.cpp:78
1 xul.dll mozilla::Fuzzyfox::Start toolkit/components/fuzzyfox/Fuzzyfox.cpp:53
2 xul.dll nsLayoutStatics::Initialize layout/build/nsLayoutStatics.cpp:306
3 xul.dll nsLayoutModuleInitialize layout/build/nsLayoutModule.cpp:111
4 xul.dll nsComponentManagerImpl::Init xpcom/components/nsComponentManager.cpp:493
5 xul.dll NS_InitXPCOM xpcom/build/XPCOMInit.cpp:445
6 xul.dll int XREMain::XRE_main toolkit/xre/nsAppRunner.cpp:4714
7 xul.dll XRE_main toolkit/xre/nsAppRunner.cpp:4799
8 xul.dll int mozilla::BootstrapImpl::XRE_main toolkit/xre/Bootstrap.cpp:45
9 firefox.exe static int NS_internal_main browser/app/nsBrowserApp.cpp:300
Reporter | ||
Comment 1•5 years ago
|
||
Adding Tom in case he might know why this crash might be happening.
Updated•5 years ago
|
Comment 2•5 years ago
|
||
We have shipped our last beta for 71 but since those crashes seem to be startup crashes, I am leaving the bug as fix-optional for 71 in case we have a sage patch to uplift in a future dot release.
Comment 3•4 years ago
|
||
Crashes started in 70, and the crashing line and null dereference indicates we failed to load the pref service. Not sure how the earlier Preferences::GetBool() worked--guess it handled the failure and just used the default argument? Maybe something in 70 shifted the timing enough that fuzzyfox was initialized before the pref service now? Or given the relatively low numbers of infected users probably a race of some kind?
It would be fine to null check and just not set the pref observers for these rare cases. How many people need to change fuzzyness live, who couldn't just restart their browser if they got one of the racy starts.
Updated•4 years ago
|
Assignee | ||
Comment 4•4 years ago
|
||
Pushed by tritter@mozilla.com: https://hg.mozilla.org/integration/autoland/rev/c13fea29c3b1 Check if we got the pref service before using it to avoid a crash r=mhowell
Comment 6•4 years ago
|
||
bugherder |
Comment 7•4 years ago
|
||
Since the status are different for nightly and release, what's the status for beta?
For more information, please visit auto_nag documentation.
Assignee | ||
Updated•4 years ago
|
Assignee | ||
Comment 8•4 years ago
|
||
Comment on attachment 9119227 [details]
Bug 1594083 - Check if we got the pref service before using it to avoid a crash r?mhowell
Beta/Release Uplift Approval Request
- User impact if declined: 130ish users will encourage an average of 2 startup crashes.
- Is this code covered by automated tests?: Unknown
- Has the fix been verified in Nightly?: No
- Needs manual test from QE?: No
- If yes, steps to reproduce:
- List of other uplifts needed: None
- Risk to taking this patch: Low
- Why is the change risky/not risky? (and alternatives if risky): Low-risk patch because it doesn't change much.
- String changes made/needed:
Updated•4 years ago
|
Comment 9•4 years ago
|
||
Comment on attachment 9119227 [details]
Bug 1594083 - Check if we got the pref service before using it to avoid a crash r?mhowell
Fixes a startup crash hit occasionally in the wild. Approved for 73.0b3.
Comment 10•4 years ago
|
||
bugherder uplift |
Description
•