1988015 - Open storage connection of messaging system sqlite db leads to debug crash in new profile manager

Status: NEW

(Firefox :: Messaging System, defect)

Description

[Jared Hirsch [:jhirsch] (he/him) (Needinfo please)]

I'm seeing a crash when running a full debug build on win11 that launches into a profile with multiple profiles enabled and the startup-time profile selector window enabled.

Steps to reproduce this state:

1. Create a full debug build from current main branch
2. launch with ./mach run -P, create a new profile, check the "Use the selected profile without asking at startup" checkbox so we start into it by default.
3. create a second profile: app menu > profiles > new profile, give it whatever name.
4. close both instances of firefox.
5. relaunch using ./mach run -n
6. Firefox will start up into the profile selector window. Similar to the profile manager window shown when launching with ./mach run -P or firefox -P, this is a startup into limited XPCOM where we do not have a profile available (see nsAppRunner::ShowProfileSelector here).
7. Click either profile card.

Expected: XPCOM cleanly shuts down and restarts into the selected profile.

Actual: crash with the following stack trace shown in the terminal:

[Parent 8452, Main Thread] WARNING: NS_ENSURE_SUCCESS(rv, rv) failed with result 0x80004005 (NS_ERROR_FAILURE): file C:/mozilla-source/firefox/toolkit/components/antitracking/bouncetrackingprotection/BounceTrackingProtectionStorage.cpp:699
[Parent 8452, Main Thread] WARNING: NS_ENSURE_SUCCESS(rv, rv) failed with result 0x80004005 (NS_ERROR_FAILURE): file C:/mozilla-source/firefox/toolkit/components/antitracking/bouncetrackingprotection/BounceTrackingProtection.cpp:141
[Parent 8452, Main Thread] WARNING: 'NS_FAILED(rv)', file C:/mozilla-source/firefox/toolkit/components/antitracking/bouncetrackingprotection/BounceTrackingProtection.cpp:93
[Parent 8452, Main Thread] WARNING: NS_ENSURE_TRUE(aWindowContext) failed: file C:/mozilla-source/firefox/toolkit/components/antitracking/bouncetrackingprotection/BounceTrackingProtection.cpp:465
Storage connection not closed: 7f7daa35.sqlite[8452] Hit MOZ_CRASH() at C:/mozilla-source/firefox/storage/mozStorageService.cpp:737
#01: mozilla::storage::Service::Observe (C:\mozilla-source\firefox\storage\mozStorageService.cpp:737)
#02: nsObserverList::NotifyObservers (C:\mozilla-source\firefox\xpcom\ds\nsObserverList.cpp:70)
#03: nsObserverService::NotifyObservers (C:\mozilla-source\firefox\xpcom\ds\nsObserverService.cpp:291)
#04: mozilla::AppShutdown::AdvanceShutdownPhaseInternal (C:\mozilla-source\firefox\xpcom\base\AppShutdown.cpp:445)
#05: mozilla::AppShutdown::AdvanceShutdownPhase (C:\mozilla-source\firefox\xpcom\base\AppShutdown.cpp:467)
#06: mozilla::ShutdownXPCOM (C:\mozilla-source\firefox\xpcom\build\XPCOMInit.cpp:634)
#07: NS_ShutdownXPCOM (C:\mozilla-source\firefox\xpcom\build\XPCOMInit.cpp:586)
#08: ScopedXPCOMStartup::~ScopedXPCOMStartup (C:\mozilla-source\firefox\toolkit\xre\nsAppRunner.cpp:2022)
#09: ShowProfileDialog (C:\mozilla-source\firefox\toolkit\xre\nsAppRunner.cpp:2960)
#10: ShowProfileSelector (C:\mozilla-source\firefox\toolkit\xre\nsAppRunner.cpp:3004)
#11: XREMain::XRE_mainStartup (C:\mozilla-source\firefox\toolkit\xre\nsAppRunner.cpp:5174)
#12: XREMain::XRE_main (C:\mozilla-source\firefox\toolkit\xre\nsAppRunner.cpp:6117)
#13: XRE_main (C:\mozilla-source\firefox\toolkit\xre\nsAppRunner.cpp:6215)
#14: mozilla::BootstrapImpl::XRE_main (C:\mozilla-source\firefox\toolkit\xre\Bootstrap.cpp:46)
#15: do_main (C:\mozilla-source\firefox\browser\app\nsBrowserApp.cpp:229)
#16: NS_internal_main (C:\mozilla-source\firefox\browser\app\nsBrowserApp.cpp:461)
#17: wmain (C:\mozilla-source\firefox\toolkit\xre\nsWindowsWMain.cpp:150)
#18: __scrt_common_main_seh (D:\a\_work\1\s\src\vctools\crt\vcstartup\src\startup\exe_common.inl:288)
#19: BaseThreadInitThunk[C:\Windows\System32\KERNEL32.DLL +0x2e8d7]
#20: RtlUserThreadStart[C:\Windows\SYSTEM32\ntdll.dll +0x3c34c]

Comment 1

[Jared Hirsch [:jhirsch] (he/him) (Needinfo please)]

The fix here might be to wait to initialize until profile-after-change has fired.

Comment 2

[Tim Huang[:timhuang]]

Emma, could you take a look? Thanks.

Comment 3

[Emma Zühlcke [:emz]]

Looking!

Comment 4

[Emma Zühlcke [:emz]]

After debuggin this for a while, I think the BTP messages in the crash log are a red herring. The open SQLite DB that causes the crash, e.g. 7f7daa35.sqlite in the log above, seems to be associated with the messaging system. I see the following tables in the file:

• Heartbeats
• MessagingSystemMessageBlocklist
• MessagingSystemMessageImpressions
• NimbusEnrollments
• Profiles
• SharedPrefs

BTP shows warnings, but none of these should lead to the actual crash. On the BTP side we could still make sure that we don't init before profile-after-change.