quic_bug_12724_4: Tried to add writer into blocked list when it shouldn't be added

[Wain-1]

I sometimes see quic_bug_12724_4 thrown when stress-testing with large (6 MB) writes and not awaiting writer.ready.

[martenrichter]

If you have a reproducible, simple test case, then please report it.
It is a nug in the underlying library, so the team of the quiche library at google seems to be aware of it (therefore the quic bug).
If you can reproduce it and I can reproduce it (this is often harder than it sounds, as these things are usually timing dependent and thus machine and os dependent...), I may have a look and try to find the cause and/or report it upstream.

Without a test case, there is not much I can do.

[Wain-1]

socketjswriter might need to set writeBlocked_ = true

[martenrichter]

Well I can set it. But there is node.js side no mechanism which signals that the socket is unblocked (though test run through). Also I currently do not see that it is related. Only a test case ( or at least a call stack where the quic_bug is triggered) can help.

[Wain-1]

It doesn't seem to do it on a localhost connection, only over the internet from a different machine (which had at least 15 ms ping).
Use an Ubuntu server and Firefox or Chrome to maybe match my conditions.
It still does it if I await writer.ready.
This does it within a few minutes for me, hope it repros for you.
vrep.zip
Confirm browser says "Connected", then watch for error on server.

[martenrichter]

Thanks, I have ported the client side also to node.js, so that I can run it in my development Docker container. So far it did not crash, but as you said, it only happened with 15 ms delay over the internet, and this is not the case in my container. I may have to alter the lib to simulate the delay.

[Wain-1]

I can also say I had it happen with simulated delay up to 100 ms, but not with 200 ms, maybe due to the bandwidth restriction.
I reproduced it while using as little as 10 MB/s sustained or one write of 6 MB, but on machines that can transfer over 50 MB/s. Might be irrelevant except for increasing throughput of the probabilistic test ofc.
Maybe the 15 ms minimum delay matters, or maybe it has to be a different machine.

[Wain-1]

Note, it doesn't crash, it just adds to the error log.

[martenrichter]

Note, it doesn't crash, it just adds to the error log.

So, what should I see? Just something on stderr? (Can you post an example?)
P.S: adding an setTimeout to received packages of 40 ms does not trigger anything. (Debugging such errors is hopeless sometime).
It may be, that you have to compile the binary part yourself, if some debug code.

[martenrichter]

It can also be that it depends on the browser (which I have replaced), as the data might be sent in different packets.

[martenrichter]

No, luck I have switched from debug lib to release lib.

So you do not see a crash? Then it is likely a quiche_bug which is harmless, but should be fixed by upstream eventually.

[Wain-1]

I assume it's stderr. It shows in the console similar to regular output.
E0103 06:31:14.563072 241526 quic_blocked_writer_list.cc:18] quic_bug_12724_4: Tried to add writer into blocked list when it shouldn't be added
It didn't happen on my windows pc connecting to itself even with simulated lag.
The write does seem to go through, so that's harmless if it does that every time.

[martenrichter]

Ok, I thought it was a quic bug command is, that is terminating (I have confused it with another quic bug command). Then ignore and may be post this issue to https://github.com/[google/quiche](https://github.com/google/quiche). They may want to investigate, if they can reproduce it this way. Currently, it is only showing a programming error, which is catched before it can make damages.