Crash investigation for pref synchronization in Nightly
Categories
(Core :: Preferences: Backend, defect)
Tracking
()
Tracking | Status | |
---|---|---|
firefox-esr91 | --- | unaffected |
firefox-esr102 | --- | unaffected |
firefox102 | --- | unaffected |
firefox103 | --- | unaffected |
firefox104 | blocking | disabled |
firefox105 | --- | fixed |
People
(Reporter: tjr, Assigned: tjr)
References
(Regression)
Details
(Keywords: crash, regression, topcrash)
Crash Data
Attachments
(10 files)
48 bytes,
text/x-phabricator-request
|
Details | Review | |
48 bytes,
text/x-phabricator-request
|
Details | Review | |
48 bytes,
text/x-phabricator-request
|
Details | Review | |
48 bytes,
text/x-phabricator-request
|
Details | Review | |
48 bytes,
text/x-phabricator-request
|
Details | Review | |
48 bytes,
text/x-phabricator-request
|
Details | Review | |
48 bytes,
text/x-phabricator-request
|
Details | Review | |
48 bytes,
text/x-phabricator-request
|
Details | Review | |
48 bytes,
text/x-phabricator-request
|
Details | Review | |
48 bytes,
text/x-phabricator-request
|
Details | Review |
This bug is to watch for crashes in Nightly and land patches to address things, if needed.
Assignee | ||
Comment 1•3 years ago
|
||
The first and only crash so far is on 'services.settings.preview_enabled' which is a dynamic boolean pref, which means that user had set it to a string.
Updated•3 years ago
|
Assignee | ||
Updated•3 years ago
|
Assignee | ||
Comment 2•3 years ago
|
||
We also have someone generating crashes on media.decoder-doctor.MediaPlatformDecoderNotFound.formats
which is a dynamic pref that seems to be involved here: https://searchfox.org/mozilla-central/search?q=media.decoder-doctor.&path=&case=false®exp=false
Assignee | ||
Updated•3 years ago
|
Assignee | ||
Comment 3•3 years ago
|
||
Assignee | ||
Updated•3 years ago
|
Assignee | ||
Updated•3 years ago
|
Assignee | ||
Comment 5•3 years ago
|
||
I found a userchromeJS pref, which we are not going to support; but I tried to let that community know here. https://github.com/xiaoxiaoflood/firefox-scripts/issues/162
Assignee | ||
Comment 6•3 years ago
|
||
Assignee | ||
Comment 7•3 years ago
|
||
It looks like there is an undocumented pdfjs.defaultZoomValue
pref that can only be set via about:config and is a string (although it seems like it could be a number?)
Comment 8•3 years ago
|
||
bugherder |
Comment 9•3 years ago
|
||
Locally, I'm also crashing on browser.region.update.updated
. In Visual Studio debugger, I can see quite clearly:
DumpJSStack()
0 XPCU_defineLazyPreferenceGetter(aObject = "[object Object]", aName = ""lastUpdated"", aPreference = ""browser.region.update.updated"", aDefaultValue = "0") ["resource://gre/modules/XPCOMUtils.sys.mjs":289:36]
this = [object Object]
1 <TOP LEVEL> ["resource://gre/modules/Region.jsm":72:11]
2 get DEFAULT_REGION() ["resource://autofill/FormAutofill.jsm":82:4]
this = [object Object]
3 _isSupportedRegion(available = ""detect"", supportedCountries = ""US,CA"") ["resource://autofill/FormAutofill.jsm":106:0]
this = [object Object]
4 get isAutofillAddressesAvailable() ["resource://autofill/FormAutofill.jsm":135:16]
this = [object Object]
5 get isAutofillAddressesEnabled() ["resource://autofill/FormAutofill.jsm":156:0]
this = [object Object]
6 get isAutofillEnabled() ["resource://autofill/FormAutofill.jsm":116:4]
this = [object Object]
7 handleEvent(evt = [cross-compartment wrapper]) ["resource://autofill/FormAutofillChild.jsm":119:12]
this = [object JSWindowActorChild]
<void>
Assignee | ||
Comment 10•3 years ago
|
||
Assignee | ||
Comment 11•3 years ago
|
||
It appears that there's a large swath of dynamic UI preferences: https://searchfox.org/mozilla-central/rev/ffb50da3ca89100b6ae5054cfe69c187679515f0/widget/nsXPLookAndFeel.cpp#212
Assignee | ||
Comment 12•3 years ago
|
||
There's a large list of dynamic preferences in the ui. tree
but none of them should contain personally identifiable data.
Comment 13•3 years ago
|
||
Updated•3 years ago
|
Comment 14•3 years ago
|
||
Tom, this is turning into a top crash for our nightly population this morning, I think that if the patch on autoland doesn't reduce the crash volume, we should back out bug 1772345 while you work on this bug so as that we don't loose users on the channel.
Updated•3 years ago
|
![]() |
||
Comment 15•3 years ago
|
||
agibson hit this with Should not access the preference 'browser.uitour.testingOrigins' in the Content Processes
.
Comment 16•3 years ago
|
||
Here's my crash report for Comment 15:
https://crash-stats.mozilla.org/report/index/d15ad557-6ea9-4c41-aace-4c2670220721
Assignee | ||
Comment 17•3 years ago
|
||
Comment 18•3 years ago
|
||
I've hit this multiple times in debug builds testing Photoshop on the Web; both the update.updated bug and gfx.blacklist.webrtc.hw.acceleration.h264.failureid (and I would assume all or most of the gfx.blacklist prefs are likewise).
I would also take a look at all the prefs in GetPrefNameForFeature() in GfxInfoBase.cpp in conjunction with a gfx person.
Assignee | ||
Comment 19•3 years ago
|
||
Assignee | ||
Comment 20•3 years ago
|
||
Assignee | ||
Comment 22•3 years ago
|
||
(In reply to Pascal Chevrel:pascalc from comment #14)
Tom, this is turning into a top crash for our nightly population this morning, I think that if the patch on autoland doesn't reduce the crash volume, we should back out bug 1772345 while you work on this bug so as that we don't loose users on the channel.
I've submitted a patch to disable it - we've gotten a lot of reports, and while I'm landing fixes as fast as I can, people only get the update so fast. Especially since I'll be away for the weekend, we should turn this off and let the reports die down and land all the fixes we see coming in from the tail of reports from un-updated users.
Unfortunately, we ran the full test test suite and ran an opt-in trial via dev-platform that failed to yield the results we're seeing here. I will take another look at some code patterns these reports surfaced, but when we re-enable it there will probably be another stream of reports. I may need to re-architecture this to use Telemetry Events or possibly some code I had written that was designed to limit a crash to a single instance. (Unfortunately it was parent-process only, so it may not work.)
Comment 23•3 years ago
|
||
:tjr, since this bug is a regression, could you fill (if possible) the regressed_by field?
For more information, please visit auto_nag documentation.
Comment 24•3 years ago
|
||
Copying crash signatures from duplicate bugs.
Comment 25•3 years ago
|
||
Assignee | ||
Updated•3 years ago
|
Assignee | ||
Comment 26•3 years ago
|
||
Assignee | ||
Comment 27•3 years ago
|
||
I've pressed the lando button several times in a row on un-attached-but-dependent revisions, but always in the correct landing order, so hopefully it works...
Comment 28•3 years ago
|
||
Comment 29•3 years ago
|
||
Comment 30•3 years ago
|
||
Comment 31•3 years ago
|
||
bugherder |
Comment 32•3 years ago
|
||
Comment 33•3 years ago
|
||
bugherder |
Comment 34•3 years ago
|
||
bugherder |
Comment hidden (Intermittent Failures Robot) |
Assignee | ||
Comment 37•3 years ago
|
||
Comment 38•3 years ago
|
||
Comment 39•3 years ago
|
||
bugherder |
Comment hidden (Intermittent Failures Robot) |
Assignee | ||
Comment 41•3 years ago
|
||
Comment 42•3 years ago
|
||
Comment 43•3 years ago
|
||
Set release status flags based on info from the regressing bug 1772345
Comment 44•3 years ago
|
||
bugherder |
Updated•3 years ago
|
Updated•3 years ago
|
Assignee | ||
Comment 45•3 years ago
|
||
We're not going to do any more work in this bug.
Updated•3 years ago
|
Updated•3 years ago
|
Description
•