1837277 - Migration on startup crashes for debug builds

Status: NEW

(Toolkit :: Startup and Profile System, defect)

Description

[kpatenio]

It seems that the migration wizard crashes Firefox when running ./mach run --migration with debug builds.

STR for local builds:

1. Check out to and build mozilla-central
2. Run ./mach run --migration
3. In the migration wizard, try to import data from another browser profile (ex. Chrome, Safari, etc.)

Expected:

• data should be migrated successfully and Firefox should open without issue

Actual:

• Firefox immediately crashes

Notes:

• Affects both the older migration wizard and the newer one (see Bug 1823537)
• Does not occur if importing data from another existing Firefox profile
• Does not occur if importing a HTML file (new migration wizard only)
• No crashes happened when I ran a Firefox refresh, so it's possible this is unique to the ./mach run --migration command only.

Comment 1

[Mike Conley (:mconley) (:⚙️)]

Looks like an assertion failure. Here's the stack:

Assertion failure: mPrefsInitialized, at /Users/mikeconley/Projects/mozilla-central/toolkit/xre/nsXREDirProvider.cpp:735
#01: nsXREDirProvider::DoStartup()[/Users/mikeconley/Projects/mozilla-central/obj-debug/toolkit/library/build/XUL +0xe54e745]
#02: NS_InvokeByIndex[/Users/mikeconley/Projects/mozilla-central/obj-debug/toolkit/library/build/XUL +0x17eb20e]
#03: CallMethodHelper::Invoke()[/Users/mikeconley/Projects/mozilla-central/obj-debug/toolkit/library/build/XUL +0x2fa81a1]
#04: CallMethodHelper::Call()[/Users/mikeconley/Projects/mozilla-central/obj-debug/toolkit/library/build/XUL +0x2f86301]
#05: XPCWrappedNative::CallMethod(XPCCallContext&, XPCWrappedNative::CallMode)[/Users/mikeconley/Projects/mozilla-central/obj-debug/toolkit/library/build/XUL +0x2f85ff7]
#06: XPC_WN_CallMethod(JSContext*, unsigned int, JS::Value*)[/Users/mikeconley/Projects/mozilla-central/obj-debug/toolkit/library/build/XUL +0x2f88617]
#07: CallJSNative(JSContext*, bool (*)(JSContext*, unsigned int, JS::Value*), js::CallReason, JS::CallArgs const&)[/Users/mikeconley/Projects/mozilla-central/obj-debug/toolkit/library/build/XUL +0xe76d7df]
#08: js::InternalCallOrConstruct(JSContext*, JS::CallArgs const&, js::MaybeConstruct, js::CallReason)[/Users/mikeconley/Projects/mozilla-central/obj-debug/toolkit/library/build/XUL +0xe76d2ac]
#09: InternalCall(JSContext*, js::AnyInvokeArgs const&, js::CallReason)[/Users/mikeconley/Projects/mozilla-central/obj-debug/toolkit/library/build/XUL +0xe76dfee]
#10: js::CallFromStack(JSContext*, JS::CallArgs const&, js::CallReason)[/Users/mikeconley/Projects/mozilla-central/obj-debug/toolkit/library/build/XUL +0xe76dde3]
#11: js::Interpret(JSContext*, js::RunState&)[/Users/mikeconley/Projects/mozilla-central/obj-debug/toolkit/library/build/XUL +0xe77da0e]
#12: MaybeEnterInterpreterTrampoline(JSContext*, js::RunState&)[/Users/mikeconley/Projects/mozilla-central/obj-debug/toolkit/library/build/XUL +0xe76cbe6]
#13: js::RunScript(JSContext*, js::RunState&)[/Users/mikeconley/Projects/mozilla-central/obj-debug/toolkit/library/build/XUL +0xe76c4e8]
#14: js::InternalCallOrConstruct(JSContext*, JS::CallArgs const&, js::MaybeConstruct, js::CallReason)[/Users/mikeconley/Projects/mozilla-central/obj-debug/toolkit/library/build/XUL +0xe76d4bc]
#15: InternalCall(JSContext*, js::AnyInvokeArgs const&, js::CallReason)[/Users/mikeconley/Projects/mozilla-central/obj-debug/toolkit/library/build/XUL +0xe76dfee]
#16: js::Call(JSContext*, JS::Handle<JS::Value>, JS::Handle<JS::Value>, js::AnyInvokeArgs const&, JS::MutableHandle<JS::Value>, js::CallReason)[/Users/mikeconley/Projects/mozilla-central/obj-debug/toolkit/library/build/XUL +0xe76e1bc]
#17: js::CallSelfHostedFunction(JSContext*, JS::Handle<js::PropertyName*>, JS::Handle<JS::Value>, js::AnyInvokeArgs const&, JS::MutableHandle<JS::Value>)[/Users/mikeconley/Projects/mozilla-central/obj-debug/toolkit/library/build/XUL +0xecca77d]
#18: js::jit::InterpretResume(JSContext*, JS::Handle<JSObject*>, JS::Value*, JS::MutableHandle<JS::Value>)[/Users/mikeconley/Projects/mozilla-central/obj-debug/toolkit/library/build/XUL +0xf85ad31]

Here's the JS stack:

0 migrate() ["resource:///modules/MigratorBase.sys.mjs":486:41]
1 InterpretGeneratorResume(gen = "[object Object]", val = "[object Object],[object Object],[object Object],[object Object],[object Object]", kind = ""next"") ["self-hosted":1497:33]
2 AsyncFunctionNext(val = "[object Object],[object Object],[object Object],[object Object],[object Object]") ["self-hosted":894:26]
    this = [object Object]
3 showMigrationWizard(aOpener = "null", aOptions = "[object Object]") ["resource:///modules/MigrationUtils.sys.mjs":655:16]
    this = [object Object]
4 asyncStartupMigration() ["resource:///modules/MigrationUtils.sys.mjs":755:9]
5 AsyncFunctionNext(val = "[object Object]") ["self-hosted":894:26]
    this = [object Object]
6 spinResolve(promise = "[object Promise]") ["resource:///modules/MigrationUtils.sys.mjs":355:16]
    this = [object Object]
7 startupMigration(aProfileStartup = "[xpconnect wrapped nsIProfileStartup @ 0x100da9a00 (native @ 0x7ff7bfefe948)]", aMigratorKey = """", aProfileToMigrate = """") ["resource:///modules/MigrationUtils.sys.mjs":682:9]
    this = [object Object]

Comment 2

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

The severity field is not set for this bug.
:mossop, could you have a look please?

For more information, please visit BugBot documentation.

Comment 3

[Dave Townsend [:mossop]]

This appears to be a regression from bug 1398895 which moved the prefs initialisation out of nsXREDirProvider::DoStartup to earlier in startup and replaced it with the assertion that we're hitting. But it moved the prefs initialisation to just after we enter the migration code (which calls DoStartup internally).

Unfortunately we have a bit of a chicken and egg situation. This comment says we need to run the migrator before loading prefs but the intent of bug 1398895 was to ensure that prefs were loaded before we load any JS components. If I'm reading right though bug 1398895 was about ensuring that the pref to enable sharing JSM globals we set correctly before we load any JSM globals ... and that pref seems to no longer exist so maybe we don't need to care so much now.

I suspect that we could replace the assertion with calls to InitializeUserPrefs and FinishInitializingUserPrefs (which are no-ops if prefs are already initialised). Kris do you have any thoughts?

Comment 4

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

Clear a needinfo that is pending on an inactive user.

Inactive users most likely will not respond; if the missing information is essential and cannot be collected another way, the bug maybe should be closed as INCOMPLETE.

For more information, please visit BugBot documentation.