1601997 - Crash in [@ neqo_http3conn_reset_stream] assertion failed: self.state_active()

Status: RESOLVED FIXED

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

Description

[[e-mail]]

This bug is for crash report bp-47a54ef4-843a-4220-84d6-92c2c0191206.
Also: https://crash-stats.mozilla.org/report/index/bdb3a7ed-eac9-4b4a-9eb5-e05f20191206

With pref network.http.http3.enabled enabled on the latest Fx Developer Edition (72) on Mac OS 10.14.6

Top 10 frames of crashing thread:

0 XUL RustMozCrash mozglue/static/rust/wrappers.cpp:17
1 XUL mozglue_static::panic_hook mozglue/static/rust/lib.rs:89
2 XUL core::ops::function::Fn::call src/libcore/ops/function.rs:69
3 XUL std::panicking::rust_panic_with_hook src/libstd/panicking.rs:481
4 XUL std::panicking::begin_panic src/libstd/panicking.rs:411
5 XUL neqo_http3conn_reset_stream netwerk/socket/neqo_glue/src/lib.rs:417
6 XUL mozilla::net::Http3Session::CloseStream netwerk/protocol/http/Http3Session.cpp:935
7 XUL mozilla::net::Http3Session::CloseTransaction netwerk/protocol/http/Http3Session.cpp:927
8 XUL mozilla::net::nsHttpConnectionMgr::OnMsgCancelTransaction netwerk/protocol/http/nsHttpConnectionMgr.cpp:2479
9 XUL mozilla::net::ConnEvent::Run netwerk/protocol/http/nsHttpConnectionMgr.cpp:261

Comment 1

[Kershaw Chang [:kershaw]]

Dragana, could you take a look? Thanks.

Comment 2

[Chris Peterson [:cpeterson]]

Windows has a slightly different crash signature in bp-119a239a-a4ff-44ad-a418-c8ea30191210.

This crash is the same self.state_active() assertion failed as neqo bug 1595779.

I have manually enabled the network.http.http3.enabled pref and Fission (fission.autostart pref). I hit this neqo crash seven times in 30 minutes today. I don't know if it's related, but I have a YouTube tab playing in the background.

Top 10 frames of crashing thread:

MOZ_CRASH Reason (Raw) 	assertion failed: self.state_active() 

0 xul.dll RustMozCrash mozglue/static/rust/wrappers.cpp:16
1 xul.dll static void mozglue_static::panic_hook mozglue/static/rust/lib.rs:89
2 xul.dll static void core::ops::function::Fn::call<fn src/libcore/ops/function.rs:69
3 xul.dll static void std::panicking::rust_panic_with_hook src/libstd/panicking.rs:477
4 xul.dll static <NoType> std::panicking::begin_panic<str*> src/libstd/panicking.rs:407
5 xul.dll struct nserror::nsresult neqo_glue::neqo_http3conn_reset_stream netwerk/socket/neqo_glue/src/lib.rs:421
6 xul.dll void mozilla::net::Http3Session::CloseStream netwerk/protocol/http/Http3Session.cpp:935
7 xul.dll void mozilla::net::Http3Session::CloseTransaction netwerk/protocol/http/Http3Session.cpp:927
8 xul.dll void mozilla::net::nsHttpConnectionMgr::OnMsgCancelTransaction netwerk/protocol/http/nsHttpConnectionMgr.cpp:2483
9 xul.dll nsresult mozilla::net::ConnEvent::Run netwerk/protocol/http/nsHttpConnectionMgr.cpp:259

Comment 3

[Chris Peterson [:cpeterson]]

I am 99% certain that this YouTube video is causing my crash:

https://www.youtube.com/watch?v=TvUHt54Ucrg

I had that video playing in a background tab, but I can hit the crash immediately when loading that page in a foreground tab (even before I can see or hear the video playing).

Strangely (like my comments in bug 1595779 comment 13), I still hit this crash even though I set my network.http.http3.enabled and fission.autostart prefs back to false. ?!

Comment 4

[[e-mail]]

Hi,

Just updated to 72.0b5 and crashed again after enabling HTTP/3, but with another signature this time.

https://crash-stats.mozilla.org/report/index/63285095-ef8e-4a6d-afe9-52b400191211

Most of my testing is done on cloudflare sites, not sure if that helps, maybe their http/3 implementation and firefox's don't like each other. Also sites are slooooow with HTTP/3 on whenever firefox doesn't crash :)

Comment 5

[Chris Peterson [:cpeterson]]

https://crash-stats.mozilla.org/report/index/63285095-ef8e-4a6d-afe9-52b400191211

That looks like a different bug. Both the crash signature function and assertion reason are different. Probably worth filing a new bug for that crash.

[@ neqo_transport::send_stream::TxBuffer::mark_as_acked]
assertion failed: self.ranges.highest_offset() >= offset + len as u64

Comment 6

[[e-mail]]

Cool,

Created https://bugzilla.mozilla.org/show_bug.cgi?id=1603240.

Comment 7

[Dragana Damjanovic [:dragana]]

Chris, can you still reproduce it? If yes, can you capture a http log from me?
I think I know in which scenarion this can happen and I am going to fix it, but I would like to be sure I am not missing something.

Comment 8

[Chris Peterson [:cpeterson]]

Attachment: neqo-youtube-crash.log.txt-main.9080.moz_log.zip

(In reply to Dragana Damjanovic [:dragana] from comment #7)

Chris, can you still reproduce it? If yes, can you capture a http log from me?
I think I know in which scenarion this can happen and I am going to fix it, but I would like to be sure I am not missing something.

Yes. I'm still able to easily reproduce this crash by enabling http3 and playing this YouTube video: https://www.youtube.com/watch?v=TvUHt54Ucrg

I've attached an HTTP log.

Here are some of my crash reports:

bp-848d67e7-aa79-471c-861f-e4f150191220
bp-628a7534-b32b-4e76-9a85-486f90191220

Comment 9

[[e-mail]]

So, little update now that I'm on Fx 72.0b10.

I haven't crashed with b9 or b10 yet, but I think that is because Fx likes to use HTTP/2 a lot more lately even though the flag is on in about:config.

DevTools says HTTP/2 most of the time and only sometimes HTTP/3.

When it uses HTTP/3 it still sloooooow tho.

Comment 10

[[e-mail]]

Well that didn't last long, crashed again but with a new signature so created a new bug here: https://bugzilla.mozilla.org/show_bug.cgi?id=1605751

Comment 11

[Chris Peterson [:cpeterson]]

I can still reproduce this crash (in 74 Nightly) after playing a couple seconds of the following YouTube video with network.http.http3.enabled enabled:

https://www.youtube.com/watch?v=TvUHt54Ucrg

bp-f7c98e51-db1a-46d6-b7f4-0ad300200110

Comment 12

[[:philipp]]

the signature is also spiking up on beta currently. are we running experiments with http/3 there currently (perhaps it's also users flipping the pref on their own)?

Comment 13

[Ryan VanderMeulen [:RyanVM]]

Do you have any idea why we'd be seeing this in the wild on non-Nightly channels? Is there any way to hit this crash without the pref set?

Comment 14

[Dragana Damjanovic [:dragana]]

(In reply to Ryan VanderMeulen [:RyanVM] from comment #13)

Do you have any idea why we'd be seeing this in the wild on non-Nightly channels? Is there any way to hit this crash without the pref set?

no this can only happen whe QUIC/HTTP3 is on. Probably people are trying out quic..

Comment 15

[Chris Peterson [:cpeterson]]

I can no longer reproduce this crash. I assume it was fixed by a recent Neqo update.

There haven't been any neqo_http3conn_reset_stream crash reports since 73.0b6. There was only one neqo_http3::connection_client::Http3Client::stream_reset crash report in 74.0a1.

Comment 17

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

Bugbug thinks this bug is a regression, but please revert this change in case of error.