Chrome bugs

[Luke Curley]

Hey folks,

I FINALLY got my QUIC server implementation to a working state and I'm trying to iron out some of the bugs. These seem specific to the Chrome QuicTransport implementation as I've tested most things with aioquic.

Chrome Version 85.0.4183.83 (Official Build) (64-bit)

1. Stream finish on a server-initiated bidirectional stream crashes the browser.

Establish the QuicTransport connection and have the server create a bidirectional stream. The server can write any amount of data but once it sends a STREAM frame with the FIN bit, the browser crashes. (aww snap error code: 11) 

2. Stream reset on a server-initiated bidirectional stream is ignored.

Probably related to above, but the reader just hangs. I was hoping this would be a work-around to the FIN crash...

I'm slowly working through other issues and will reply if I find more!

[Yutaka Hirano]

Thank you for the feedback!

On Mon, Aug 31, 2020 at 6:00 AM Luke Curley <kixe...@gmail.com> wrote:

Hey folks,

I FINALLY got my QUIC server implementation to a working state and I'm trying to iron out some of the bugs. These seem specific to the Chrome QuicTransport implementation as I've tested most things with aioquic.

Chrome Version 85.0.4183.83 (Official Build) (64-bit)

1. Stream finish on a server-initiated bidirectional stream crashes the browser.

Establish the QuicTransport connection and have the server create a bidirectional stream. The server can write any amount of data but once it sends a STREAM frame with the FIN bit, the browser crashes. (aww snap error code: 11) 

Isn't this https://crbug.com/1112734? I fixed the bug in M86, but I failed to merge the fix to M85. Can you test with M86?

 

2. Stream reset on a server-initiated bidirectional stream is ignored.

Probably related to above, but the reader just hangs. I was hoping this would be a work-around to the FIN crash...

Thank you. Can you file a bug via https://crbug.com/new?

 

I'm slowly working through other issues and will reply if I find more!

--
You received this message because you are subscribed to the Google Groups "web-transport-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to web-transport-...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/web-transport-dev/538ad310-32d8-4cb4-b9c1-78fdba7d6b48n%40chromium.org.

[Luke Curley]

Hey Yutaka,

I've still got more work to do, but my QUIC server is working with QuicTransport! The most annoying issue was an off-by-one error, causing the occasional packet to go 1 byte above the MaxUdpPayloadSize, but I was able to figure it out with Chromium debug logs.

The crash is fixed in M86 but bidirectional streams are still broken. I haven't tested everything yet, nor confirmed against another implementation, but here's some issues I noticed with 87.0.4249.0. I filed these bugs but I figure this mailing list could always use more messages. ;)

1. Client-initiated unidirectional stream is reset on close.

Valid but any lost packets mean a reset stream. There should not be a RESET_STREAM unless the stream is aborted.

2. Client-initiated bidirectional stream is one-way.

The client is fine creating a bidirectional stream and sending data, but absolutely panics when it receives any data. This includes reporting the wrong final stream size which I think Lucas encountered.

3. Server-initiated bidirectional streams are broken.

The server is immediately met with a STOP_SENDING and RESET_STREAM upon sending data on a bidirectional stream. This seems similar to #2 and could be the same issue.

Server-initiated unidirectional streams seem to work just fine, and fortunately that's what my application uses the most.