UserAgent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_12_6) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/12.0.1 Safari/605.1.15

Example URL:

Steps to reproduce the problem:
We have noticed that the DCHECK keeps triggering for us in some scenarios:

https://chromium.googlesource.com/chromium/src/+/master/net/third_party/quic/core/quic_session.cc#451

What happens is:

1. the lost data is retransmitted here: https://chromium.googlesource.com/chromium/src/+/master/net/third_party/quic/core/quic_session.cc#398
2. stream frames remain buffered in the packet creator
3. the check  https://chromium.googlesource.com/chromium/src/+/master/net/third_party/quic/core/quic_session.cc#437 is successful, CWND makes it possible to send 1 packet
4. packet generator flushes the creator: https://chromium.googlesource.com/chromium/src/+/master/net/third_party/quic/core/quic_packet_generator.cc#77 and CWND is full
5. as a consequence, nothing can be consumed and the busy loop counter is incremented

What is the expected behavior?

What went wrong?
The packet flushed/sent in this scenario has type NOT_RETRANSMISSION, although it is a retransmission effectively, see  https://chromium.googlesource.com/chromium/src/+/master/net/third_party/quic/core/quic_session.cc#406

Even if functions like QuicConnection::CanWriteStreamData()  return true, it might not be possible to send any packets.

Did this work before? N/A 

Chrome version:   Channel: n/a
OS Version: OS X 10.12.6
Flash Version: 

See the discussion at proto-quic, subject "busy loop DCHECK in quic_session".