2053962 - Crash in [@ mozilla::Preferences::BackupPrefFile]

Status: RESOLVED FIXED

(Core :: Preferences: Backend, defect)

Description

[BugBot [:suhaib / :marco]]

Crash report: https://crash-stats.mozilla.org/report/index/bb2c9fa7-6978-41a4-a34d-6fe580260703

MOZ_CRASH Reason: MozPromise::ThenValue created from 'BackupPrefFile' destroyed without being either disconnected, resolved, or rejected (dispatchRv: not dispatched)

Top 10 frames of crashing thread:

0  xul.dll  MOZ_Crash  mfbt/Assertions.h:402
0  xul.dll  mozilla::MozPromise<bool, nsresult, 0>::ThenValueBase::AssertIsDead  xpcom/threads/MozPromise.h:541
1  xul.dll  mozilla::MozPromise<bool, nsresult, 0>::AssertIsDead  xpcom/threads/MozPromise.h:1267
2  xul.dll  mozilla::MozPromise<bool, nsresult, 0>::~MozPromise  xpcom/threads/MozPromise.h:1315
3  xul.dll  mozilla::MozPromise<bool, nsresult, 0>::Private::~Private  xpcom/threads/MozPromise.h:255
4  xul.dll  mozilla::MozPromiseRefcountable::Release  xpcom/threads/MozPromise.h:150
4  xul.dll  mozilla::RefPtrTraits<mozilla::MozPromise<bool, nsresult, 0> >::Release  mfbt/RefPtr.h:48
4  xul.dll  RefPtr<mozilla::MozPromise<bool, nsresult, 0> >::ConstRemovingRefPtrTraits<mozilla::MozPromise<bool, nsresult, 0> >::Release  mfbt/RefPtr.h:406
4  xul.dll  RefPtr<mozilla::MozPromise<bool, nsresult, 0> >::~RefPtr  mfbt/RefPtr.h:79
4  xul.dll  mozilla::Preferences::BackupPrefFile  modules/libpref/Preferences.cpp:5093

By querying Nightly crashes reported within the last 2 months, here are some insights about the signature:

• First crash report: 2026-05-05
• Process type: Parent
• Is startup crash: No
• Has user comments: No
• Is null crash: Yes - 1 out of 10 crashes happened on null or near null memory address

Comment 1

[Jens Stutte [:jstutte]]

Attachment: Bug 2053962 - Dispatch async backup pref writes as standalone writes instead of sharing the sPendingWriteData slot. r=gstoll

BackupPrefFile writes go through PreferencesImpl::WritePrefFile, which coalesces
all writes through a single sPendingWriteData slot destined for the profile
prefs.js. A backup targets a different file with a filtered pref set and carries
a MozPromise. When the slot was already occupied, the backup took the coalescing
early-return, dropping its MozPromiseHolder without settling it and leaving its
filtered data in the slot. Give writes that carry a promise holder their own
PWRunnable with their own data so they never touch the shared slot.

Comment 2

[BugBot [:suhaib / :marco]]

There is an r+ patch which didn't land and no activity in this bug for 1 week.
:jstutte, could you have a look please?
If you still have some work to do, you can add an action "Plan Changes" in Phabricator.
For more information, please visit BugBot documentation.

Comment 3

[Pulsebot]

Pushed by [e-mail]:
https://github.com/mozilla-firefox/firefox/commit/58d973b24a3b
https://hg.mozilla.org/integration/autoland/rev/fa8e9db1acdd
Dispatch async backup pref writes as standalone writes instead of sharing the sPendingWriteData slot. r=gstoll

Comment 4

[Norisz Fay [:noriszfay]]

https://hg.mozilla.org/mozilla-central/rev/fa8e9db1acdd

Comment 5

[Norisz Fay [:noriszfay]]

https://hg.mozilla.org/mozilla-central/rev/fa8e9db1acdd

Comment 6

[Norisz Fay [:noriszfay]]

https://hg.mozilla.org/mozilla-central/rev/fa8e9db1acdd

Comment 7

[Norisz Fay [:noriszfay]]

https://hg.mozilla.org/mozilla-central/rev/fa8e9db1acdd

Comment 8

[Jens Stutte [:jstutte]]

Greg, do you think we should uplift this to beta? I am a bit worried that this might not be the only possible consequence of that race and we may save wrong prefs or some such.

Comment 9

[BugBot [:suhaib / :marco]]

The patch landed in nightly and beta is affected.
:jstutte, is this bug important enough to require an uplift?

• If yes, please nominate the patch for beta approval.
  • See https://wiki.mozilla.org/Release_Management/Requesting_an_Uplift for documentation on how to request an uplift.
• If no, please set status-firefox154 to wontfix.

For more information, please visit BugBot documentation.

Comment 10

[Greg Stoll :gstoll]

Yeah, I think it would probably be a good idea to uplift this as it could lead to data loss. Let me know if you'd like me to do that or if you'd rather handle it, thanks!

Comment 11

[Jens Stutte [:jstutte]]

I'll handle it.

Comment 12

[Jens Stutte [:jstutte]]

IIUC this has been introduced in Fx125, so all versions but ESR 115 are affected. I'll propose an uplift to ESR 153, too.

Comment 13

[Jens Stutte [:jstutte]]

Attachment: Bug 2053962 - Dispatch async backup pref writes as standalone writes instead of sharing the sPendingWriteData slot.

BackupPrefFile writes go through PreferencesImpl::WritePrefFile, which coalesces
all writes through a single sPendingWriteData slot destined for the profile
prefs.js. A backup targets a different file with a filtered pref set and carries
a MozPromise. When the slot was already occupied, the backup took the coalescing
early-return, dropping its MozPromiseHolder without settling it and leaving its
filtered data in the slot. Give writes that carry a promise holder their own
PWRunnable with their own data so they never touch the shared slot.

Original Revision: https://phabricator.services.mozilla.com/D311551

Comment 14

[Phabricator Automation]

firefox-beta Uplift Approval Request

• User impact if declined/Reason for urgency: Preference backups may not work as expected, resulting in potential data loss (only for the backups, but still).
  Note: There seems to be no UI in Fenix to reach this code, so we can probably do without uplifting it there.
• Code covered by automated testing?: yes
• Fix verified in Nightly?: yes
• Needs manual QE testing?: no
• Steps to reproduce for manual QE testing:
• Risk associated with taking this patch: low
• Explanation of risk level: The fix is a bit more than a on-liner, but straight forward and existing tests continue to pass + a new one.
• String changes made/needed?: None
• Is Android affected?: no

Comment 15

[Phabricator Automation]

firefox-esr153 Uplift Approval Request

• User impact if declined/Reason for urgency: Preference backups may not work as expected, resulting in potential data loss (only for the backups, but still).
  Note: There seems to be no UI in Fenix to reach this code, so we can probably do without uplifting it there.
• Code covered by automated testing?: yes
• Fix verified in Nightly?: yes
• Needs manual QE testing?: no
• Steps to reproduce for manual QE testing:
• Risk associated with taking this patch: low
• Explanation of risk level: The fix is a bit more than a on-liner, but straight forward and existing tests continue to pass + a new one.
• String changes made/needed?: None
• Is Android affected?: no

Comment 16

[Jens Stutte [:jstutte]]

Attachment: Bug 2053962 - Dispatch async backup pref writes as standalone writes instead of sharing the sPendingWriteData slot.

BackupPrefFile writes go through PreferencesImpl::WritePrefFile, which coalesces
all writes through a single sPendingWriteData slot destined for the profile
prefs.js. A backup targets a different file with a filtered pref set and carries
a MozPromise. When the slot was already occupied, the backup took the coalescing
early-return, dropping its MozPromiseHolder without settling it and leaving its
filtered data in the slot. Give writes that carry a promise holder their own
PWRunnable with their own data so they never touch the shared slot.

Original Revision: https://phabricator.services.mozilla.com/D311551

Comment 17

[Pulsebot]

https://github.com/mozilla-firefox/firefox/commit/f2c13c0d9e2c
https://hg.mozilla.org/releases/mozilla-beta/rev/4d4a82b0dcf4

Comment 18

[Pulsebot]

https://hg.mozilla.org/releases/mozilla-esr153/rev/1894f254236d