1987606 - Crash in [@ quinn_udp::imp::decode_recv]

Status: ASSIGNED

(Core :: Networking, defect, P3)

Description

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

Crash report: https://crash-stats.mozilla.org/report/index/4d87e8bc-e446-4a5f-981c-c69510250909

MOZ_CRASH Reason:

internal error: entered unreachable code

Top 10 frames:

0  XUL  MOZ_CrashSequence(void*, long)  mfbt/Assertions.h:248
0  XUL  MOZ_Crash(char const*, int, char const*)  mfbt/Assertions.h:381
0  XUL  RustMozCrash  mozglue/static/rust/wrappers.cpp:18
1  XUL  mozglue_static::panic_hook  mozglue/static/rust/lib.rs:99
2  XUL  core::ops::function::Fn::call  /builds/worker/fetches/rustc/lib/rustlib/src/rust/library/core/src/ops/function.rs:79
3  XUL  <alloc::boxed::Box<F, A> as core::ops::function::Fn<Args>>::call  library/alloc/src/boxed.rs:1990
3  XUL  std::panicking::rust_panic_with_hook  library/std/src/panicking.rs:839
4  XUL  std::panicking::begin_panic_handler::{{closure}}  library/std/src/panicking.rs:697
5  XUL  std::sys::backtrace::__rust_end_short_backtrace  library/std/src/sys/backtrace.rs:168
6  XUL  rust_begin_unwind  library/std/src/panicking.rs:695

macOS only crash since 142.0, looks like all crashes are from OSX 10.15, mostly French and Japanese users.

Reported in French community forums:
https://forums.mozfr.org/viewtopic.php?t=157316

Tracking as the volume is important for macOS.

Comment 1

[Kershaw Chang [:kershaw]]

Hi Max, could you take a look?
Thanks.

Comment 2

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

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

:ghess, could you please find an assignee for this tracked bug? If you disagree with the tracking decision, please talk with the release managers.

For more information, please visit BugBot documentation.

Comment 3

[Max Inden]

Thank you Pascal for bringing this to our attention!

I have created https://github.com/quinn-rs/quinn/issues/2383 to track this upstream.

If you want to share a remedy with the reporters above, they can set network.http.http3.use_nspr_for_io to true.

Comment 4

[Max Inden]

For the record, https://github.com/quinn-rs/quinn/pull/2387, which fixes the panic upstream, is merged. Note that this will prevent the panic only, the underlying QUIC connection would still close, though now with a proper error.

The patch returns the address family (not IPv4, not IPv6) value. I am curious what it is on the devices reporting the panic.

Comment 5

[Ryan VanderMeulen [:RyanVM]]

Hi Max, what's the status on getting a quinn update vendored into Firefox?

Comment 6

[Rares Doghi, Desktop QA]

I tried to reproduce this issue on a MacOS 10.15.7 with Firefox 142, 143 and 144 but without success, I tried a handfull of websites as well as letting the macbook go into sleep mode but I couldnt reproduce any crashes. I also tried FR and JP builds but without specific websites or test cases I dont think we can reproduce this issue on our side. Can someone from our dev team give us a python script or a website that would help us reproduce this issue ?

Comment 7

[Max Inden]

@Ryan given that we see a small number of crash reports only and given that this only affects an old operating system version, we gave this bug a low priority. Please let me know if you disagree with that categorization.

Given its low priority, I am not prioritizing a quinn-udp release, prioritizing other work instead. Again, please correct me if I am missing something. Without prioritization, I expect a quinn-udp to trickle down into Firefox in the next couple of months.

@Rares thank you for trying to reproduce. I don't know of a way to reproduce either.