2069800 - [new in release] Crash in [@ AsyncShutdownTimeout | profile-before-change | CookiePersistentStorage: cookies.sqlite closing]

Status: RESOLVED FIXED

(Core :: Networking: Cookies, defect, P2)

Description

[Clouseau (:calixte)]

Crash report: https://crash-stats.mozilla.org/report/index/8d0e6d7c-e482-4d85-a176-ec0880260904

MOZ_CRASH Reason:

[Parent 33648, Main Thread] ###!!! ABORT: file checkouts\gecko\netwerk\cookie\CookiePersistentStorage.cpp:909

Top 10 frames of the hung main thread (nothing crashed here — a watchdog killed the process; these are what the main thread is waiting on):

0  xul.dll  Abort(char const*)  xpcom/base/nsDebugImpl.cpp:528
1  xul.dll  NS_DebugBreak(unsigned int, char const*, char const*, char const*, int)  xpcom/base/nsDebugImpl.cpp:511
2  xul.dll  nsDebugImpl::Abort(char const*, int)  xpcom/base/nsDebugImpl.cpp:127
3  xul.dll  _NS_InvokeByIndex()
4  xul.dll  XPCWrappedNative::CallMethod(XPCCallContext&, XPCWrappedNative::CallMode)  js/xpconnect/src/XPCWrappedNative.cpp:1118
5  xul.dll  XPC_WN_CallMethod(JSContext*, unsigned int, JS::Value*)  js/xpconnect/src/XPCWrappedNativeJSOps.cpp:962
6  xul.dll  js::Interpret(JSContext*, js::RunState&)  js/src/vm/Interpreter.cpp:3300
7  xul.dll  js::Call(JSContext*, JS::Handle<JS::Value>, JS::Handle<JS::Value>, js::AnyInvoke...  js/src/vm/Interpreter.cpp:711
8  xul.dll  JS::RunJSMicroTask(JSContext*, JS::Handle<JSObject *>)  js/src/builtin/Promise.cpp:8441
9  xul.dll  mozilla::RunMicroTask(JSContext*, mozilla::CycleCollectedJSContext*, JS::Mutable...  xpcom/base/CycleCollectedJSContext.cpp:747

There are 96 crashes (from 76 installations) in 155.0.1 starting with buildid 20260903215306.

This signature is not new: its first report anywhere is in build 20260304092935 (2026-03-04), 184 days before the build above.

Timing check: this signature was already being reported in build 20260325090410, 162 days before the changeset named below landed, so that changeset cannot be what INTRODUCED this SIGNATURE. It may still be relevant, and it may still be the cause of the crash in this particular report — an old signature can acquire a new cause, and a rare crash can be made frequent by a change that did not create it — but the signature's own history is not evidence that it is.

Clouseau analysis (automated). The mechanism below fits the evidence but is not proven end-to-end:

ab9673b0a48d (bug 2066155) quadruples wal_autocheckpoint frequency for cookies.sqlite by shrinking network.cookie.db.maxWalBytes from 2MB to 512KB; each checkpoint costs two fsyncs, and checkpoint-bearing commits share the exact serial "sqldb:cookies.sqlite" thread that Connection::AsyncClose() must also queue behind, so more-frequent checkpoints plausibly delay the CookiePersistentStorage AsyncShutdown blocker's resolution during profile-before-change, worsening a pre-existing (184-day-old) timeout signature rather than creating it.

The change lands exactly inside this crash's own candidate window (2026-09-03, between the 155.0 and 155.0.1 builds), and it is a 4x tightening of the checkpoint threshold relative to 155.0's baseline (which already carried a prior, out-of-window increase from 16 to ~500 pages), consistent with the observed 5x crash-rate step from 155.0 (4.8/day) to 155.0.1 (24.0/day) for this exact signature; hardware/bit-flip share for the signature is ~0-1%, arguing against a hardware-artefact explanation.

Suspected regressor: ab9673b0a48d (gh) (bug 2066155) by :baku.

Code references:

• CookiePersistentStorage::InitDBConnInternal
• mozilla::storage::Connection::AsyncClose
• modules/libpref/init/StaticPrefList.yaml:14640

What the automated skeptic pass checked (its own words — a pass means the check succeeded, which is not always support for the conclusion):

• unverifiable exact sqlite3_step/COMMIT->wal_hook synchronous execution frame — Relies on documented SQLite wal_autocheckpoint semantics rather than a frame-by-frame in-tree trace of AsyncExecuteStatements::Run().
• unverifiable cookie write queue depth actually nonzero at shutdown — Plausible given async dispatch and no explicit write-drain before Close(), but not empirically measured.
• pass thread-sharing (sqldb: thread used by both writes and AsyncClose) — Confirmed same getAsyncExecutionTarget() thread for both, and thread name matches this crash's own thread list entry "sqldb:cookies.sqlite #2".
• pass WAL cap reduced ~4x, in-window — Diff confirms 2048000 -> 524288; changeset lands 2026-09-03, inside the 155.0->155.0.1 build window.
• pass blocker gated on AsyncClose completion — HandleDBClosed()/RemoveShutdownBlocker() only run after the close event executes on the shared thread.

:baku, can you have a look please?

Filed automatically by Clouseau, which analyses release crashes with an LLM. Nothing above was written or checked by a human. Please close it as INVALID if it is wrong — that is useful feedback, not a nuisance.

This is not an independent Mozilla discovery: the crash is known here only because somebody submitted the crash report linked at the top. If this duplicates an existing report, please resolve THIS bug as the duplicate and leave the credit with the earlier reporter.

Comment 1

[Sylvestre Ledru [:Sylvestre]]

[Tracking Requested - why for this release]: seems that it is spiking in 155 (low volume for now)

Comment 2

[BugBot [:suhaib / :marco]]

The bug has a crash signature, thus the bug will be considered confirmed.

Comment 3

[BugBot [:suhaib / :marco]]

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

Comment 4

[Pascal Chevrel (relman team) -> :pascalc]

@baku, this is too late for 155 but do you think we could plan a fix for the 156 dot release?

Comment 5

[Andrea Marchesini [:baku]]

Attachment: Bug 2069800 - Buffer cookie database writes and flush them in batched transactions

Comment 6

[Andrea Marchesini [:baku]]

I just submitted a fix.

Comment 7

[Andrea Marchesini [:baku]]

The fix is about to land, but I would not recommend an uplift because that code changes how we write cookies on disk drastically. I would like to have the entire beta period to test regressions. If the number of crashes are acceptable, we can run the train for the fix.

Comment 8

[Pulsebot]

Pushed by [e-mail]:
https://github.com/mozilla-firefox/firefox/commit/39c451810398
https://hg.mozilla.org/integration/autoland/rev/cd67488aca11
Buffer cookie database writes and flush them in batched transactions r=cookie-reviewers,valentin

Comment 9

[Silaghi Andreea]

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

Comment 11

[BugBot [:suhaib / :marco]]

Copying crash signatures from duplicate bugs.

Comment 13

[BugBot [:suhaib / :marco]]

Copying crash signatures from duplicate bugs.

Comment 15

[BugBot [:suhaib / :marco]]

Copying crash signatures from duplicate bugs.

Comment 16

[Performance Sheriff Bot]

Perfherder has detected a talos performance change from push cd67488aca11a52f81a4f8013134af3098c15aee.

No action is required from the author; this comment is provided for informational purposes only.

Improvement	Test	Platform	Options	Absolute values [old vs new]
2%	tp5n nonmain_normal_fileio (doc)	windows11-64-25h2-shippable	e10s fission stylo webrender-sw	573,613,950.71 -> 559,514,880.58

Need Help or Information?

If you have any questions, please reach out to [e-mail]. Alternatively, you can find help on Slack by joining #perf-help, and on Matrix you can find help by joining #perftest.

Details of the alert can be found in the alert summary, including links to graphs and comparisons for each of the affected tests.