This bug is for crash report bp-79157f17-cb2a-4ac4-b402-2aa6b0200312.

Top 10 frames of crashing thread:

0 libxul.so RustMozCrash mozglue/static/rust/wrappers.cpp:17
1 libxul.so mozglue_static::panic_hook mozglue/static/rust/lib.rs:89
2 libxul.so core::ops::function::Fn::call src/libcore/ops/function.rs:72
3 libxul.so std::panicking::rust_panic_with_hook src/libstd/panicking.rs:475
4 libxul.so rust_begin_unwind src/libstd/panicking.rs:375
5 libxul.so core::panicking::panic_fmt src/libcore/panicking.rs:84
6 libxul.so core::slice::slice_index_len_fail src/libcore/slice/mod.rs:2674
7 libxul.so neqo_transport::send_stream::TxBuffer::next_bytes 
8 libxul.so neqo_transport::send_stream::SendStream::next_bytes 
9 libxul.so neqo_transport::connection::Connection::output 

upstream fix https://github.com/mozilla/neqo/pull/503

Fixed by bug 1623185

Andy, it looks like the issue is still present.

This happens reliably with the current Nightly Windows 10 x64 build (Build ID 20200409095500) when I open media in Whatsapp Web.

I'm having trouble reproducing the issue. I recorded a video status for myself on my phone and was able to watch it via Whatsapp web. This issue should really come up when sending data. Are you uploading or sending data to the webapp? Can you describe what exactly you're doing a little more? (I'm not previously a whatsapp user).

I'm using the same build on Windows 10 x64, I see whatsapp web using http 1.1 for the majority of its requests, with just a few http/3 requests for small "wam" resources, and these appear to succeed.

This is crash in trying to read data from a stream (OnWriteSegment may confuse you but that is writing into a pipe form a socket).

Sorry, this doesn't happen anymore, so I guess it was just a coincidence yesterday.