1761652 - Shutdown crash [IOUtils: waiting for profileBeforeChange IO to complete | CrashMonitor: Writing notifications to file after receiving profile-before-change and awaiting all checkpoints written] -- when disabling permanent private browsing from settings

Status: VERIFIED FIXED

(Firefox :: Session Restore, defect)

Description

[Matt Fagnani]

I started Firefox Nightly 100.0a1 (2022-03-26) on Wayland in Plasma 5.24.3 in a Fedora 36 KDE Plasma installation. I selected Edit > Settings > Privacy & Security. I had previously selected Always use private browsing mode. I clicked to remove the check for Always use private browsing mode. A box with the message "Nightly must restart to enable this feature. " appeared. I selected Restart Nightly now. Firefox closed. Firefox didn't reappear. The Crash reporter appeared after about a minute. I reported the crash. The crash reason was "[Parent 3982, Main Thread] ###!!! ABORT: file resource://gre/modules/CrashMonitor.jsm:175"

I reproduced this crash once using the same procedure. I saw the same problem with Nightly 100.0a1 from 2022-03-25. The problem didn't appear when doing those steps with Nightly before the last day or so.

Maybe Fission related. (DOMFissionEnabled=1)

Crash report: https://crash-stats.mozilla.org/report/index/d642d20e-cf1c-4b37-84e1-ac7ff0220327

MOZ_CRASH Reason: [Parent 3982, Main Thread] ###!!! ABORT: file resource://gre/modules/CrashMonitor.jsm:175

Top 10 frames of crashing thread:

0 libxul.so NS_DebugBreak xpcom/base/nsDebugImpl.cpp:433
1 libxul.so nsDebugImpl::Abort xpcom/base/nsDebugImpl.cpp:132
2 libxul.so NS_InvokeByIndex 
3 libxul.so XPCWrappedNative::CallMethod js/xpconnect/src/XPCWrappedNative.cpp:1130
4 libxul.so XPC_WN_CallMethod js/xpconnect/src/XPCWrappedNativeJSOps.cpp:963
5 libxul.so Interpret js/src/vm/Interpreter.cpp:3302
6 libxul.so js::Call js/src/vm/Interpreter.cpp:589
7 libxul.so PromiseReactionJob js/src/builtin/Promise.cpp:2067
8 libxul.so js::Call js/src/vm/Interpreter.cpp:589
9 libxul.so JS::Call js/src/vm/CallAndConstruct.cpp:117

Comment 1

[Matt Fagnani]

I ran mozregression --good 2022-03-24 --bad 2022-03-26 --profile ~/.mozilla/firefox/z8d4nvrc.default-nightly
I used my profile so that Always use private browsing mode was already selected. The end of the bisection process showed the first bad revision as 2a8633af0279379685ba781c6c469e8b07ec13f4 Mathew Hodson — Bug 1752853 - Stop using a worker to write session store. r=Gijs,Standard8

15:00.67 INFO: Narrowed integration regression window from [dd81d58d, 25a863d8] (3 builds) to [dd81d58d, 2a8633af] (2 builds) (~1 steps left)
15:00.68 INFO: No more integration revisions, bisection finished.
15:00.68 INFO: Last good revision: dd81d58d9d5fa4f82b3400e40fa39b2c00d5df11
15:00.68 INFO: First bad revision: 2a8633af0279379685ba781c6c469e8b07ec13f4
15:00.68 INFO: Pushlog:
https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=dd81d58d9d5fa4f82b3400e40fa39b2c00d5df11&tochange=2a8633af0279379685ba781c6c469e8b07ec13f4

I'm changing the component to Session Restore since that's the component of Bug 1752853

Comment 2

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

Set release status flags based on info from the regressing bug 1752853

Comment 3

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

:mathew.hodson, since you are the author of the regressor, bug 1752853, could you take a look?
For more information, please visit auto_nag documentation.

Comment 4

[Mathew Hodson]

This looks similar to bug 1743674.

Comment 5

[Mathew Hodson]

@barret do you have an idea? You did some work on the "profile-before-change" checkpoint in bug 1749996.

Comment 6

[:Gijs (he/him)]

I can reproduce locally on macOS using the steps in comment 0. I'll keep my needinfo in case I have more time to investigate further. The stack in the crash report is pretty weird, because it indicates that we somehow hit JS code from mozilla::net::CookieStorage::Release(), which feels like it should not be possible...

Comment 7

[Beth Rennie [:beth] (she/her)]

I'm actively investigating this now.

Comment 8

[Beth Rennie [:beth] (she/her)]

Attachment: Bug 1761652 - Fail to write session file more gracefully if we started in permanent private browsing r?gijs

Comment 9

[:Gijs (he/him)]

Barret bailed me out here so clearing needinfo.

Comment 10

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/49c52d61b306
Fail to write session file more gracefully if we started in permanent private browsing r=Gijs

Comment 11

[Norisz Fay [:noriszfay]]

https://hg.mozilla.org/mozilla-central/rev/49c52d61b306

Comment 12

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

The patch landed in nightly and beta is affected.
:barret, is this bug important enough to require an uplift?
If not please set status_beta to wontfix.

For more information, please visit auto_nag documentation.

Comment 13

[Beth Rennie [:beth] (she/her)]

Comment on attachment 9271174 [details]
Bug 1761652 - Fail to write session file more gracefully if we started in permanent private browsing r?gijs

Beta/Release Uplift Approval Request

• User impact if declined: Any user that disables permanent browsing mode will get a crash.
• Is this code covered by automated tests?: No
• Has the fix been verified in Nightly?: Yes
• Needs manual test from QE?: No
• If yes, steps to reproduce:
• List of other uplifts needed: None
• Risk to taking this patch: Low
• Why is the change risky/not risky? (and alternatives if risky): This patch adds more error handling around shutdown to ensure we always mark writing the session file as complete (especially during the final write), even when it fails, which will avoid us crashing due to not having written the file.
• String changes made/needed:

Comment 14

[Dianna Smith [:diannaS]]

Comment on attachment 9271174 [details]
Bug 1761652 - Fail to write session file more gracefully if we started in permanent private browsing r?gijs

Approved for 100.0b5

Comment 15

[Dianna Smith [:diannaS]]

https://hg.mozilla.org/releases/mozilla-beta/rev/d2c0e1b1b27d

Comment 16

[Vlad Lucaci, Thunderbird QA (:vlucaci)]

Hello

Managed to reproduce this issue with the provided steps from Description on 100.0b4(20220410195727) with macOS 11.6.5.

Confirming this issue as verified fixed on macOS 11.6.5, Ubuntu 20, Fedora 35, KDE Neon, Windows 11 with 101.0a1(20220414092955) and 100.0b5(20220412185818).

Comment 17

[Dianna Smith [:diannaS]]

:barret though the volume is significantly less, there are still a few crashes that occurred after the patch. should there be another ticket for it ?

Comment 18

[Beth Rennie [:beth] (she/her)]

There is https://bugzilla.mozilla.org/show_bug.cgi?id=1743674, which has crashes with this assertion going back ~5 mo.