Closed Bug 1594404 Opened 5 months ago Closed 5 months ago

Crash in [@ mozilla::AutoSafeJSContext::AutoSafeJSContext]

Categories

(Core :: XPConnect, defect, critical)

Unspecified
Windows 7
defect
Not set
critical

Tracking

()

RESOLVED FIXED
mozilla72
Root Cause ?
Tracking Status
firefox-esr68 --- unaffected
firefox70 --- unaffected
firefox71 --- unaffected
firefox72 blocking fixed

People

(Reporter: pascalc, Unassigned)

References

(Regression)

Details

(Keywords: crash, regression, topcrash)

Crash Data

Attachments

(1 file)

This bug is for crash report bp-3fcbd07a-642b-40b0-8c8d-b71d00191106.

Top 10 frames of crashing thread:

0 xul.dll mozilla::AutoSafeJSContext::AutoSafeJSContext dom/script/ScriptSettings.cpp:716
1 xul.dll static nsresult CentralizedAdminPrefManagerInit extensions/pref/autoconfig/src/nsJSConfigTriggers.cpp:54
2 xul.dll nsresult nsReadConfig::readConfigFile extensions/pref/autoconfig/src/nsReadConfig.cpp:163
3 xul.dll nsresult nsReadConfig::Observe extensions/pref/autoconfig/src/nsReadConfig.cpp:91
4 xul.dll nsObserverList::NotifyObservers xpcom/ds/nsObserverList.cpp:66
5 xul.dll nsObserverService::NotifyObservers xpcom/ds/nsObserverService.cpp:291
6 xul.dll mozilla::Preferences::InitializeUserPrefs modules/libpref/Preferences.cpp:3672
7 xul.dll nsXREDirProvider::InitializeUserPrefs toolkit/xre/nsXREDirProvider.cpp:886
8 xul.dll nsresult XREMain::XRE_mainRun toolkit/xre/nsAppRunner.cpp:4401
9 xul.dll int XREMain::XRE_main toolkit/xre/nsAppRunner.cpp:4740

Started showing up in the 20191106095742 nightly build.

Mike, FYI, this seems to involve autoconfig somehow.

Flags: needinfo?(mozilla)

OK apparently we have no tests for this autoconfig thing? :/

Component: JavaScript Engine → XPConnect

I can 'fix' this by loading autoconfig after we initialize JS. That means autoconfig files can't set or affect JS engine startup prefs because that's a chicken-and-egg problem. That was also the situation before bug 1579367 so it's not making anything worse.

We do have tests for Autoconfig:

https://searchfox.org/mozilla-central/source/extensions/pref/autoconfig/test/unit

But they are xpcshell

We couldn't figure out how to test things that require files laid down before Firefox even starts.

Flags: needinfo?(mozilla)

This fixes crashes when using autoconfig files.

The patch I posted seems to fix this locally. It's not pretty but I think it's the best we can do given autoconfig requires JS execution.

Flags: needinfo?(jdemooij)

1000 startup crashes in the last 4 hours, I stopped nightly updates and will ask sheriffs to backout bug 1579367 and respin nightlies.

Regressed by: 1579367
Keywords: topcrash

(In reply to Mike Kaply [:mkaply] from comment #6)

We do have tests for Autoconfig:

https://searchfox.org/mozilla-central/source/extensions/pref/autoconfig/test/unit

But they are xpcshell

We couldn't figure out how to test things that require files laid down before Firefox even starts.

You should be able to do that with Marionette.

I'm shocked that all these folks have autoconfig on nightly. Is autoconfig always in the call stack?

(In reply to Mike Kaply [:mkaply] from comment #11)

I'm shocked that all these folks have autoconfig on nightly. Is autoconfig always in the call stack?

There's around 1300 of these crashes on the latest Nightly build, from 170 installations. Splitting them up by proto-signature, at least 1200 of them look roughly like those in comment 0.

(In reply to Mike Kaply [:mkaply] from comment #11)

I'm shocked that all these folks have autoconfig on nightly. Is autoconfig always in the call stack?

It appears to be. Unfortunately, I suspect a lot of people still use autoconfig as a hack to execute chrome JS.

(In reply to Kris Maglione [:kmag] from comment #13)

(In reply to Mike Kaply [:mkaply] from comment #11)

I'm shocked that all these folks have autoconfig on nightly. Is autoconfig always in the call stack?

It appears to be. Unfortunately, I suspect a lot of people still use autoconfig as a hack to execute chrome JS.

I use it to load a mozilla.cfg file (via general.config.filename), which applies a bunch of lockPref/defaultPref/pref stuff that I want to have on every one of my Firefox installs. If there's documentation about how to do this any other way, it's very hard to find.

(In reply to Steven Noonan from comment #14)

I use it to load a mozilla.cfg file (via general.config.filename), which applies a bunch of lockPref/defaultPref/pref stuff that I want to have on every one of my Firefox installs. If there's documentation about how to do this any other way, it's very hard to find.

That's a correct use for it.

You should be able to do that with Marionette.

https://bugzilla.mozilla.org/show_bug.cgi?id=1594584

Duplicate of this bug: 1594560

Fixed by backout. I'll try landing bug 1579367 again in a few days and fold the patch here into it...

Status: NEW → RESOLVED
Closed: 5 months ago
Resolution: --- → FIXED
Crash Signature: [@ mozilla::AutoSafeJSContext::AutoSafeJSContext] → [@ mozilla::AutoSafeJSContext::AutoSafeJSContext] [@ nsReadConfig::Observe]

(In reply to Pascal Chevrel:pascalc from comment #9)

1000 startup crashes in the last 4 hours, I stopped nightly updates and will ask sheriffs to backout bug 1579367 and respin nightlies.

Nightly updates are restored.

Crash Signature: [@ mozilla::AutoSafeJSContext::AutoSafeJSContext] [@ nsReadConfig::Observe] → [@ mozilla::AutoSafeJSContext::AutoSafeJSContext] [@ nsReadConfig::Observe]
Target Milestone: --- → mozilla72

Please specify a root cause for this bug. See :tmaity for more information.

Root Cause: --- → ?
You need to log in before you can comment on or make changes to this bug.