Closed Bug 1805619 Opened 2 years ago Closed 2 years ago

perma comm/mail/components/enterprisepolicies/tests/browser/browser_policy_disable_safemode.js | application crashed [@ MOZ_Crash(char const*, int, char const*)]

Categories

(Thunderbird :: General, defect)

defect

Tracking

(thunderbird_esr102 unaffected)

RESOLVED FIXED
110 Branch
Tracking Status
thunderbird_esr102 --- unaffected

People

(Reporter: intermittent-bug-filer, Assigned: mconley)

References

Details

(Keywords: crash, intermittent-failure)

Crash Data

Attachments

(1 file)

Summary: Intermittent comm/mail/components/enterprisepolicies/tests/browser/browser_policy_disable_safemode.js | application crashed [@ MOZ_Crash(char const*, int, char const*)] → perma comm/mail/components/enterprisepolicies/tests/browser/browser_policy_disable_safemode.js | application crashed [@ MOZ_Crash(char const*, int, char const*)]
Mozilla crash reason: Missing chrome or resource URLs: resource:///modules/MigrationUtils.sys.mjs

Which makes me think it's https://hg.mozilla.org/mozilla-central/rev/912f29a6243b2bf5199462a6ecaf499aeacb9789#l12.13 (bug 718280)
Sadly MigrationUtils.sys.mjs lives in browser and is referenced in toolkit. Maybe the fix here is to update our migration implementation to also provide a local MigrationUtils.sys.mjs?

Also I think bug 1805620 is the same crash.

I suspect it's this part: https://hg.mozilla.org/mozilla-central/diff/912f29a6243b2bf5199462a6ecaf499aeacb9789/toolkit/modules/ResetProfile.sys.mjs

The test that's failing is loading about:support, which loads ResetProfile.sys.mjs to see if a FirefoxProfileMigrator exists, which is a pre-requisite to doing a profile reset.

Before, it used to check for the existence of the profile by asking XPCOM to see if the migrator was registered as a component. Now that MigrationUtils is doing all of that management, we now ask it instead. And this module is only registered for browser, so crash.

So a few options to fix this:

  1. comm stubs out a fake MigrationUtils and returns false for migratorExists. This seems like a kludge and probably an option of last resort.
  2. ResetProfile.sys.mjs is modified so that it doesn't assume MigrationUtils exists. It'll check for existence as a first step, and then check that an appropriate migrator exists.

I suggest (2) is probably the best way forward.

Thank you for jumping in here!

I'm not familiar with our migration code nor the toolkit migration paths at all, but I wanted to note that we appear to have our own implementations of the migrator that was previously called, or at least I think we did? https://searchfox.org/comm-central/source/mail/components/migration/src/components.conf

Though I'm not sure we'd ever see any of those "types" from this specific code path.

From a quick glance, that should still probably work - the mail migrator code still tries to pull its migrators from XPCOM, and that's what it's using to register them, so you should be good there.

Assignee: nobody → mconley

Can you check to see if the patch here fixes the crash for TB?

Flags: needinfo?(martin)
Flags: needinfo?(martin)

Still crashes: https://treeherder.mozilla.org/logviewer?job_id=399653134&repo=try-comm-central&lineNumber=2736

I think the issue is that even trying to resolve the URI triggers the crash: https://searchfox.org/mozilla-central/rev/17aeb39742eba71e0936ae44a51a54197100166d/netwerk/base/nsNetUtil.cpp#3898

So I guess the solution is to check against the app constant?

Alright, added a condition for MOZ_BUILD_APP to the lazy getter. Does that fix it?

Flags: needinfo?(martin)
Pushed by mconley@mozilla.com: https://hg.mozilla.org/integration/autoland/rev/347b3b17f31d Check for MigrationUtils before calling into it in ResetProfile.sys.mjs. r=NeilDeakin
Status: NEW → RESOLVED
Closed: 2 years ago
Resolution: --- → FIXED
Target Milestone: --- → 110 Branch
Duplicate of this bug: 1805620
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: