1931684 - Crash in [@ mozilla::net::CookieServiceChild::RecordDocumentCookie]

Status: RESOLVED FIXED

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

Description

[Sebastian Hengst [:aryx] (needinfo me if it's about an intermittent or backout)]

5 crashes from 3 installs of Firefox 134.0a1 20241115210754 on Windows.

Crash report: https://crash-stats.mozilla.org/report/index/da246e3f-0bac-4b68-ad42-8489d0241116

MOZ_CRASH Reason:

MOZ_DIAGNOSTIC_ASSERT(false)

Top 10 frames:

0  xul.dll  mozilla::net::CookieServiceChild::RecordDocumentCookie(mozilla::net::Cookie*,...  netwerk/cookie/CookieServiceChild.cpp:318
1  xul.dll  mozilla::net::CookieServiceChild::SetCookieStringFromHttp(nsIURI*, nsTSubstri...  netwerk/cookie/CookieServiceChild.cpp:528
2  xul.dll  mozilla::net::HttpChannelChild::OnStartRequest(mozilla::net::nsHttpResponseHe...  netwerk/protocol/http/HttpChannelChild.cpp:493
2  xul.dll  mozilla::net::HttpChannelChild::ProcessOnStartRequest::<lambda_16>::operator(...  netwerk/protocol/http/HttpChannelChild.cpp:358
2  xul.dll  std::invoke(mozilla::net::HttpChannelChild::ProcessOnStartRequest::<lambda_16>&)  /builds/worker/fetches/vs/VC/Tools/MSVC/14.39.33519/include/type_traits:1729
2  xul.dll  std::_Func_impl_no_alloc<`lambda at /builds/worker/checkouts/gecko/netwerk/pr...  /builds/worker/fetches/vs/VC/Tools/MSVC/14.39.33519/include/functional:905
3  xul.dll  mozilla::net::ChannelEventQueue::FlushQueue()  netwerk/ipc/ChannelEventQueue.cpp:82
4  xul.dll  mozilla::net::ChannelEventQueue::MaybeFlushQueue()  netwerk/ipc/ChannelEventQueue.h:343
4  xul.dll  mozilla::net::ChannelEventQueue::CompleteResume()  netwerk/ipc/ChannelEventQueue.h:328
4  xul.dll  mozilla::net::ChannelEventQueue::ResumeInternal::CompleteResumeRunnable::Run()  netwerk/ipc/ChannelEventQueue.cpp:141

Comment 1

[Randell Jesup [:jesup] (needinfo me)]

Permacrashes on https://www.theregister.com/AMP/2024/11/16/rusthaters_unite_filc/

Comment 2

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

The bug is linked to a topcrash signature, which matches the following criteria:

• Top 10 desktop browser crashes on nightly
• Top 10 AArch64 and ARM crashes on nightly

:kershaw, could you consider increasing the severity of this top-crash bug?

For more information, please visit BugBot documentation.

Comment 3

[Kershaw Chang [:kershaw]]

(In reply to BugBot [:suhaib / :marco/ :calixte] from comment #2)

The bug is linked to a topcrash signature, which matches the following criteria:

• Top 10 desktop browser crashes on nightly
• Top 10 AArch64 and ARM crashes on nightly

:kershaw, could you consider increasing the severity of this top-crash bug?

For more information, please visit BugBot documentation.

This is MOZ_DIAGNOSTIC_ASSERT, so won't affect release users.
This can be stayed at S3 for now, but we definitely need to fix this soon.

Comment 4

[Andrew McCreight [:mccr8]]

It would also be good if you added a string to the diagnostic assert. Just having "false" as the condition and no string means it will be harder to distinguish from other crashes when searching by crash reason.

Comment 5

[Pascal Chevrel:pascalc]

This is affecting our nightly population todayand will affect Devedition users next week, tracking given the volume.

Comment 6

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

The bug is marked as tracked for firefox134 (nightly). We have limited time to fix this, the soft freeze is in 2 days. However, the bug still isn't assigned and has low severity.

:ghess, could you please find an assignee and increase the severity for this tracked bug? Given that it is a regression and we know the cause, we could also simply backout the regressor. If you disagree with the tracking decision, please talk with the release managers.

For more information, please visit BugBot documentation.

Comment 7

[Tim Huang[:timhuang]]

The diagnostic asserts has been changed to regular moz assert in Bug 1931893. We should no longer see the crash in the wild after Bug 1931893 lands.

Comment 8

[Daniel Holbert [:dholbert]]

If we're looking for a way to repro this, we've got one by following the STR over in bug 1884131.

(But I see this should be good in nightly going forward, per comment 7 - hooray!)

(Edit: aha, I see we've also got a repro'ing URL in comment 1)

Comment 9

[Polly [:polly]]

i could also repro this in 2024-11-17 nightly - ran into it doing my xmas shopping, but can confirm it now works fine on 2024-11-19 nightly :)
(pixel 8, android 15)

Comment 10

[Sebastian Hengst [:aryx] (needinfo me if it's about an intermittent or backout)]

Fixed by bug 1931893.

Comment 11

[Daniel Holbert [:dholbert]]

(In reply to Polly McEldowney [:pollymce] from comment #9)

it now works fine on 2024-11-19 nightly :)

Not sure why we'd be getting different results, but for what it's worth, I'm still seeing the crash (diagnostic assert) on Nightly 2024-11-19. I'm on the latest Nightly that the play store currently offers me (which reports itself as 2024-11-19 in About Firefox Nightly).

But I think that's fine/expected -- it looks like the patch that addressed this (in bug 1931893) made it into mozilla-central on Nov 19, so probably it won't be in builds until the 11-20 Nightly (or maybe the later-in-the-day 2024-11-19 Nightly which the play store isn't offering me yet).

Comment 12

[Polly [:polly]]

Yes you're quite right - I spoke too soon - I just got the crash on the 19th's nightly
Possibly an intermittent thing or I did something wrong - sorry for the misinformation (: