DCHECK fails in WriteStreamData in iOS client

[Han]

Hi,

I'm using Cronet from Chromium 83 (83.0.4103.88) for an iOS app, and
using "h3-27" as quic_version.

I encountered a crash due to DCHECK failure in
QuicChromiumClientStream::WriteStreamData() :

```
[1107/162857.869263:FATAL:quic_chromium_client_stream.cc(561)] Check
failed: !HasBufferedData().
```
My question is: is this expected to crash if there is any buffered
data? is it basically a problem of backpressure?

In my case, the stream is a new stream of a HTTP3 request (JSON body)
just about sending the request yet, is it "buffered" because other
streams in the same connection used up the capacity?

Here are related events with other streams (stream 2, and stream 76)
before the crash. We can see that both streams are starting to have
"buffered data".

The new stream was stream 80, and the loading URL is for stream 80:

and at the end I included the "send_buffer_": Thanks! - Han

2020-11-07 16:28:57.856738-0800 -[CRNHTTPProtocolHandler
startLoading]: https://<my-ip>:4433/assets
[1107/162857.857827:WARNING:quic_stream.cc(1068)] Client: stream 2
sends 185 bytes and has buffered data 0 bytes. fin is sent: 0 fin is
buffered: 0
[1107/162857.858692:WARNING:quic_stream.cc(1068)] Client: stream 76
sends 3 bytes and has buffered data 0 bytes. fin is sent: 0 fin is
buffered: 0
[1107/162857.859116:WARNING:quic_stream.cc(1068)] Client: stream 76
sends 216 bytes and has buffered data 0 bytes. fin is sent: 0 fin is
buffered: 0
[1107/162857.859598:WARNING:quic_stream.cc(1068)] Client: stream 76
sends 221 bytes and has buffered data 0 bytes. fin is sent: 0 fin is
buffered: 0
[1107/162857.863593:WARNING:quic_stream.cc(1068)] Client: stream 76
sends 15666 bytes and has buffered data 12066 bytes. fin is sent: 0
fin is buffered: 1
[1107/162857.868443:WARNING:quic_stream.cc(1068)] Client: stream 2
sends 185 bytes and has buffered data 8 bytes. fin is sent: 0 fin is
buffered: 0
[1107/162857.869263:FATAL:quic_chromium_client_stream.cc(561)] Check
failed: !HasBufferedData().

(lldb) p stream_->id()
(quic::QuicStreamId) $5 = 80

(lldb) p stream_->IsOpen()
(bool) $6 = true

(lldb) p stream_->stream_bytes_read()
(uint64_t) $7 = 0

(lldb) p stream_->stream_bytes_written()
(uint64_t) $8 = 0

(lldb) p stream_->NumBytesConsumed()
(size_t) $9 = 0

(lldb) p stream_->HasBytesToRead()
(bool) $10 = false

(lldb) p send_buffer_

(quic::QuicStreamSendBuffer) $14 = {

current_end_offset_ = 3

interval_deque_ = {

container_ = {

begin_ = 0

end_ = 2

allocator_and_data_ = {

data = 0x0000000281d4de60

data_capacity = 4

}

}

cached_index_ = {

base::internal::OptionalBase<unsigned long> = {

storage_ = {

base::internal::OptionalStorageBase<unsigned long, true> = {

is_populated_ = true

= (dummy_ = base::internal::DummyUnionMember @
0x00007ff86c408e60, value_ = 0)

}

}

}

}

}

stream_offset_ = 162

allocator_ = 0x0000000106207d88

stream_bytes_written_ = 0

stream_bytes_outstanding_ = 0

bytes_acked_ = {

intervals_ = size=0 {}

}

pending_retransmissions_ = {

intervals_ = size=0 {}

}

write_index_ = -1

}

(lldb)

[Fan Yang]

Hi Han,

  This crash is not expected, but I agree it is likely related to HTTP3. 

  In HTTP2, headers are sent on the dedicated header stream while body is sent on the corresponding SPDY stream. This DCHECK makes sure chrome does not send body while there is buffered data in the spdy stream. However, HTTP3 sends header and body on the same stream, so I suspect this DCHECK may be out of date. In your example, stream 76 does not send the whole header (likely because of cwnd limited), while chrome tries to write body and hit the DCHECK. Would you please help to verify that?

  Thank you,

  Fan

--
You received this message because you are subscribed to the Google Groups "QUIC Prototype Protocol Discussion group" group.
To unsubscribe from this group and stop receiving emails from it, send an email to proto-quic+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/proto-quic/CAEjGaqeNvn2iiodrfk%3D4c3JsBy-QOt4h_a%2B-KQEXUuDOHE-vZQ%40mail.gmail.com.

[Han]

Thanks Fan for your response!

The logs might being a bit confusing, but let me clarify a bit, and highlight some parts of the logs.

stream 76 is for a different (earlier) request, and has already sent out headers, and in the process of sending out / finishing its body.

[1107/162857.863593:WARNING:quic_stream.cc(1068)] Client: stream 76 sends 15666 bytes  and has buffered data 12066 bytes. fin is sent: 0 fin is buffered: 1

stream 80 is just starting and seems to be the one that crashed. I found out its stream id by checking `stream_` in LLDB frame:

(lldb) p stream_->id()
(quic::QuicStreamId) $5 = 80

And it seems stream 80 was only able to send things into "buffered", nothing actually sent out: 

stream_offset_ = 162

stream_bytes_written_ = 0

Regarding you said: 

>> does not send the whole header (likely because of cwnd limited), while chrome tries to write body and hit the DCHECK

Since ` stream_bytes_written_` was 0,  I think the header was not sent out.  (Server side also did not receive any stream 80 headers). So chrome hits the DCHECK as it still trying to follow the logic of HTTP2?

thanks

Han

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/proto-quic/CAD_8i%2BTx%2B%3DDGzPpSqGaMbJmmJff3g391%2B_wng%2BEELnk%3DUCUsGA%40mail.gmail.com.

[Fan Yang]

Ah, I see. Indeed, it seems stream 76 cannot finish the sending (but fin has been buffered), so stream 80 cannot send anything out. If I understand correctly, the DCHECK is hit when stream 80 tries to send the body while the header is buffered?

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/proto-quic/CAEjGaqf4dAYtrHD1zjK1TqsdjAt9C58eXrjUW9SYjgKv9buhMQ%40mail.gmail.com.

[Han]

>> the DCHECK is hit when stream 80 tries to send the body while the header is buffered?

Yes, that's the case.

Another question I have is that, I was wondering why the stream 76 was so "slow".  Based on the logs on the server side, it was getting only 1 packet (1350 bytes) per round trip (~ 10ms). This is a HTTP POST request, does chrome QUIC have a very small flow-control window?  I didn't see problems with GET requests downloading a large body from the server.

If I can speed up the streams outgoing packets, maybe this problem will go away?  Is there anything else I should do? Or is this a bug should be fixed?

Thanks

Han

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/proto-quic/CAD_8i%2BTisAALbSbCyU0pSiaWjLsh0m27wbR4eQ4OM%3DNZcqSWZg%40mail.gmail.com.

[Fan Yang]

Hi Han,

  From the existing log, it is not obvious to me whether the client is blocked by connection level flow control or congestion window. How frequent is the server sending back acknowledgements? It should be obvious if you can collect and attach the net-log.

  Cheers,

 

  Fan

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/proto-quic/CAEjGaqdbLT7%3DbxjKA_6taWnUSURYx3aP6ePJisH5BkFNqUQ9XA%40mail.gmail.com.

[Han]

Thanks Fan.  How do I collect the net-log?  So far, I manually change some QUIC_DLOG to WARNING level so I can get them in Xcode log.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/proto-quic/CAD_8i%2BRCU9PPwAGn6TA54a69He3BKwUDMgJxL48TYQ9TJwonkQ%40mail.gmail.com.

[Fan Yang]

This is what I find publicly available: https://chromium.googlesource.com/chromium/src/+/master/components/cronet/README.md. See the Debugging section. If that doesn't work, you can get the verbose logs (DVLOG(1) would be sufficient) and we can see the packets (and frames) being exchanged.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/proto-quic/CAEjGaqemrabhw%2BRDaXbcP9Xrw8%2B6TJPY7%2BEtLbVTFRb_7%2B6%3D-Q%40mail.gmail.com.

[Han]

Hi, Fan,

Thanks for the pointer. I collected the net-log file (based on Chromium 85.0.4183.109 now) and attached it to this email (some name/IP are replaced without affecting the events).  

I have a question: shouldn't QUIC be able to send out a (new) stream header even if there are other existing streams buffered on the same connection? Otherwise, this looks similar to the "head of the line" blocking problem. 

Thanks

Han

 

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/proto-quic/CAD_8i%2BQWQEcFRvioo%3DcWR70s0wRhWPnXZ5Rmb1-zqBqbqcFM_Q%40mail.gmail.com.

[Fan Yang]

It seems the attached netlog is truncated. I can see the largest sent packet is 25 while the received ACK with largest_observed 12. It is hard to tell what is throttling the sending. Is it possible to gather a complete netlog?

In TCP, HOL blocking refers to when the delay in receiving a single packet holds up the entire line of packets after it. QUIC eliminates HOL blocking with multi-streaming where delay in receiving data from one stream does not hold up the data delivery of other streams. But on the sending side, if a stream gets throttled by connection level flow control or congestion window, other streams would be throttled as well.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/proto-quic/CAEjGaqf-vLEaybKNR3%3DXt2pw%2BtX2gDd5DW7mFg0V7CfSxAHHBQ%40mail.gmail.com.

[Han]

Thanks Fan. The attached file was the full log I got, and I didn't call "stopNetLog", nor truncate the file afterwards. Unless the net-log was not collected by chrome fully for some reason.

Regarding what you noticed: 

>>  I can see the largest sent packet is 25 while the received ACK with largest_observed 12.

I suspect it might be that after sending packet 25, it tries to send the new stream (stream_id 12), and hits DCHECK. I am referring to the new request starting at line 184 in the file. 

and I think the ACK number probably shows the round trip was indeed slow.  Yesterday I also tested in local LAN, it made much more progress but eventually hit the same DCHECK at a later time. 

thanks

Han

 

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/proto-quic/CAD_8i%2BSLYDcqxDQy5E65Mr3dOwJYwxsCKvpd3kb8cYNaRq1gjg%40mail.gmail.com.

[Han]

Hi Fan, 

This seems to be a problem with concurrent POST requests streams when the network throughput is limited. I think It's okay if a new request is rejected / failed or delayed due to buffering, but should not crash.  As a workaround, I tried to ensure all POST requests are sequential, then the problem went away.

thanks,

Han

[Han]

Hi Fan,

It has been almost a year since I hit this issue last time in Chrome 83 (83.0.4103.88).  Now I am using Chrome 87 (87.0.4280.60).  This time, the crash happened with QUIC stream id 0 (i.e. the first stream in the connection), and the body size is small (32 bytes).  Again the stack trace is below.  I was wondering if there are known bugs tracking this issue, or is it already fixed in a later version of Chrome?   Thanks -  Han

(lldb) bt

* thread #15, name = 'Chrome Network IO Thread', stop reason = EXC_BREAKPOINT (code=EXC_I386_BPT, subcode=0x0)

    frame #0: 0x0000000110be7924 Cronet`base::debug::BreakDebugger() at debugger_posix.cc:361:1

    frame #1: 0x0000000110a1bd54 Cronet`logging::LogMessage::~LogMessage(this=0x00007f8378617e90) at logging.cc:875:7

    frame #2: 0x0000000110a1c3a5 Cronet`logging::LogMessage::~LogMessage(this=0x00007f8378617e90) at logging.cc:549:27

    frame #3: 0x0000000110a1c3cc Cronet`logging::LogMessage::~LogMessage(this=0x00007f8378617e90) at logging.cc:549:27

    frame #4: 0x00000001109d633e Cronet`logging::CheckError::~CheckError(this=0x000070000a0ab718) at check.cc:104:3

    frame #5: 0x00000001109d5e15 Cronet`logging::CheckError::~CheckError(this=0x000070000a0ab718) at check.cc:100:27

    frame #6: 0x00000001110eab0b Cronet`net::QuicChromiumClientStream::WriteStreamData(this=0x00007f837882c600, data=(ptr_ = "{\"cluster_name\":\"a_new_cluster\"}\x80\xaa_", length_ = 32), fin=true) at quic_chromium_client_stream.cc:562:3

    frame #7: 0x00000001110ea9c7 Cronet`net::QuicChromiumClientStream::Handle::WriteStreamData(this=0x00006000005f0fa0, data=(ptr_ = "{\"cluster_name\":\"a_new_cluster\"}\x80\xaa_", length_ = 32), fin=true, callback=net::CompletionOnceCallback @ 0x000070000a0ab828)>) at quic_chromium_client_stream.cc:220:16

  * frame #8: 0x0000000111121c18 Cronet`net::QuicHttpStream::DoSendBody(this=0x00007f8378641ad0) at quic_http_stream.cc:649:21

    frame #9: 0x000000011111eaca Cronet`net::QuicHttpStream::DoLoop(this=0x00007f8378641ad0, rv=0) at quic_http_stream.cc:515:14

    frame #10: 0x000000011111f783 Cronet`net::QuicHttpStream::SendRequest(this=0x00007f8378641ad0, request_headers=0x00007f837a08d870, response=0x00007f837a08d0e0, callback=net::CompletionOnceCallback @ 0x000070000a0abb48)>) at quic_http_stream.cc:262:8

    frame #11: 0x0000000110f9322d Cronet`net::HttpNetworkTransaction::DoSendRequest(this=0x00007f837a08d000) at http_network_transaction.cc:1039:19

    frame #12: 0x0000000110f8e5f7 Cronet`net::HttpNetworkTransaction::DoLoop(this=0x00007f837a08d000, result=0) at http_network_transaction.cc:752:14

    frame #13: 0x0000000110f8d7d9 Cronet`net::HttpNetworkTransaction::OnIOComplete(this=0x00007f837a08d000, result=0) at http_network_transaction.cc:690:12

    frame #14: 0x0000000110f96eea Cronet`void base::internal::FunctorTraits<void (net::HttpNetworkTransaction::*)(int), void>::Invoke<void (method=b0 d7 f8 10 01 00 00 00 00 00 00 00 00 00 00 00, receiver_ptr=0x000070000a0abe18, args=0x000070000a0abe74)(int), net::HttpNetworkTransaction*, int>(void (net::HttpNetworkTransaction::*)(int), net::HttpNetworkTransaction*&&, int&&) at bind_internal.h:498:12

    frame #15: 0x0000000110f96dd6 Cronet`void base::internal::InvokeHelper<false, void>::MakeItSo<void (functor=0x00006000021689e0, args=0x000070000a0abe18, args=0x000070000a0abe74)(int), net::HttpNetworkTransaction*, int>(void (net::HttpNetworkTransaction::* const&)(int), net::HttpNetworkTransaction*&&, int&&) at bind_internal.h:637:12

    frame #16: 0x0000000110f96d67 Cronet`void base::internal::Invoker<base::internal::BindState<void (net::HttpNetworkTransaction::*)(int), base::internal::UnretainedWrapper<net::HttpNetworkTransaction> >, void (int)>::RunImpl<void (functor=0x00006000021689e0, bound=size=1, (null)=std::__1::index_sequence<0UL> @ 0x000070000a0abe38, unbound_args=0x000070000a0abe74)(int), std::__1::tuple<base::internal::UnretainedWrapper<net::HttpNetworkTransaction> > const&, 0ul>(void (net::HttpNetworkTransaction::* const&)(int), std::__1::tuple<base::internal::UnretainedWrapper<net::HttpNetworkTransaction> > const&, std::__1::integer_sequence<unsigned long, 0ul>, int&&) at bind_internal.h:710:12

    frame #17: 0x0000000110f96cfb Cronet`base::internal::Invoker<base::internal::BindState<void (net::HttpNetworkTransaction::*)(int), base::internal::UnretainedWrapper<net::HttpNetworkTransaction> >, void (int)>::Run(base=0x00006000021689c0, unbound_args=0) at bind_internal.h:692:12

    frame #18: 0x0000000110448a2a Cronet`base::OnceCallback<void (int)>::Run(this=0x00007f8378641ce8, args=0) && at callback.h:100:12

    frame #19: 0x0000000111121001 Cronet`net::QuicHttpStream::DoCallback(this=0x00007f8378641ad0, rv=0) at quic_http_stream.cc:469:24

    frame #20: 0x000000011111ee75 Cronet`net::QuicHttpStream::OnIOComplete(this=0x00007f8378641ad0, rv=0) at quic_http_stream.cc:458:5

    frame #21: 0x0000000111122f5c Cronet`void base::internal::FunctorTraits<void (net::QuicHttpStream::*)(int), void>::Invoke<void (method=20 ee 11 11 01 00 00 00 00 00 00 00 00 00 00 00, receiver_ptr=0x000060000215e530, args=0x000070000a0ac094)(int), base::WeakPtr<net::QuicHttpStream>, int>(void (net::QuicHttpStream::*)(int), base::WeakPtr<net::QuicHttpStream>&&, int&&) at bind_internal.h:498:12

    frame #22: 0x0000000111122e1c Cronet`void base::internal::InvokeHelper<true, void>::MakeItSo<void (functor=0x000060000215e520, weak_ptr=0x000060000215e530, args=0x000070000a0ac094)(int), base::WeakPtr<net::QuicHttpStream>, int>(void (net::QuicHttpStream::*&&)(int), base::WeakPtr<net::QuicHttpStream>&&, int&&) at bind_internal.h:657:5

    frame #23: 0x0000000111122d77 Cronet`void base::internal::Invoker<base::internal::BindState<void (net::QuicHttpStream::*)(int), base::WeakPtr<net::QuicHttpStream> >, void (int)>::RunImpl<void (functor=0x000060000215e520, bound=size=1, (null)=std::__1::index_sequence<0UL> @ 0x000070000a0ac058, unbound_args=0x000070000a0ac094)(int), std::__1::tuple<base::WeakPtr<net::QuicHttpStream> >, 0ul>(void (net::QuicHttpStream::*&&)(int), std::__1::tuple<base::WeakPtr<net::QuicHttpStream> >&&, std::__1::integer_sequence<unsigned long, 0ul>, int&&) at bind_internal.h:710:12

    frame #24: 0x0000000111122d0b Cronet`base::internal::Invoker<base::internal::BindState<void (net::QuicHttpStream::*)(int), base::WeakPtr<net::QuicHttpStream> >, void (int)>::RunOnce(base=0x000060000215e500, unbound_args=0) at bind_internal.h:679:12

    frame #25: 0x0000000110448a2a Cronet`base::OnceCallback<void (int)>::Run(this=0x000060000215e590, args=0) && at callback.h:100:12

    frame #26: 0x00000001110c24b8 Cronet`net::QuicChromiumClientSession::StreamRequest::DoCallback(this=0x000060000215e580, rv=0) at quic_chromium_client_session.cc:701:24

    frame #27: 0x00000001110c2765 Cronet`net::QuicChromiumClientSession::StreamRequest::OnIOComplete(this=0x000060000215e580, rv=0) at quic_chromium_client_session.cc:691:5

    frame #28: 0x00000001110d8c3c Cronet`void base::internal::FunctorTraits<void (net::QuicChromiumClientSession::StreamRequest::*)(int), void>::Invoke<void (method=10 27 0c 11 01 00 00 00 00 00 00 00 00 00 00 00, receiver_ptr=0x000060000215e770, args=0x000070000a0ac294)(int), base::WeakPtr<net::QuicChromiumClientSession::StreamRequest>, int>(void (net::QuicChromiumClientSession::StreamRequest::*)(int), base::WeakPtr<net::QuicChromiumClientSession::StreamRequest>&&, int&&) at bind_internal.h:498:12

    frame #29: 0x00000001110d8acc Cronet`void base::internal::InvokeHelper<true, void>::MakeItSo<void (functor=0x000060000215e760, weak_ptr=0x000060000215e770, args=0x000070000a0ac294)(int), base::WeakPtr<net::QuicChromiumClientSession::StreamRequest>, int>(void (net::QuicChromiumClientSession::StreamRequest::*&&)(int), base::WeakPtr<net::QuicChromiumClientSession::StreamRequest>&&, int&&) at bind_internal.h:657:5

    frame #30: 0x00000001110d9637 Cronet`void base::internal::Invoker<base::internal::BindState<void (net::QuicChromiumClientSession::StreamRequest::*)(int), base::WeakPtr<net::QuicChromiumClientSession::StreamRequest> >, void (int)>::RunImpl<void (functor=0x000060000215e760, bound=size=1, (null)=std::__1::index_sequence<0UL> @ 0x000070000a0ac258, unbound_args=0x000070000a0ac294)(int), std::__1::tuple<base::WeakPtr<net::QuicChromiumClientSession::StreamRequest> >, 0ul>(void (net::QuicChromiumClientSession::StreamRequest::*&&)(int), std::__1::tuple<base::WeakPtr<net::QuicChromiumClientSession::StreamRequest> >&&, std::__1::integer_sequence<unsigned long, 0ul>, int&&) at bind_internal.h:710:12

    frame #31: 0x00000001110d95cb Cronet`base::internal::Invoker<base::internal::BindState<void (net::QuicChromiumClientSession::StreamRequest::*)(int), base::WeakPtr<net::QuicChromiumClientSession::StreamRequest> >, void (int)>::RunOnce(base=0x000060000215e740, unbound_args=0) at bind_internal.h:679:12

    frame #32: 0x0000000110448a2a Cronet`base::OnceCallback<void (int)>::Run(this=0x0000600003a3e210, args=0) && at callback.h:100:12

    frame #33: 0x000000011090142b Cronet`void base::internal::FunctorTraits<base::OnceCallback<void (int)>, void>::Invoke<base::OnceCallback<void (callback=0x0000600003a3e210, args=0x0000600003a3e218)>, int>(base::OnceCallback<void (int)>&&, int&&) at bind_internal.h:597:49

    frame #34: 0x0000000110901382 Cronet`void base::internal::InvokeHelper<false, void>::MakeItSo<base::OnceCallback<void (functor=0x0000600003a3e210, args=0x0000600003a3e218)>, int>(base::OnceCallback<void (int)>&&, int&&) at bind_internal.h:637:12

    frame #35: 0x0000000110901342 Cronet`void base::internal::Invoker<base::internal::BindState<base::OnceCallback<void (int)>, int>, void ()>::RunImpl<base::OnceCallback<void (functor=0x0000600003a3e210, bound=size=1, (null)=std::__1::index_sequence<0UL> @ 0x000070000a0ac378)>, std::__1::tuple<int>, 0ul>(base::OnceCallback<void (int)>&&, std::__1::tuple<int>&&, std::__1::integer_sequence<unsigned long, 0ul>) at bind_internal.h:710:12

    frame #36: 0x00000001109012f7 Cronet`base::internal::Invoker<base::internal::BindState<base::OnceCallback<void (int)>, int>, void ()>::RunOnce(base=0x0000600003a3e1f0) at bind_internal.h:679:12

    frame #37: 0x00000001101e5b8f Cronet`base::OnceCallback<void ()>::Run(this=0x00007f8378823000) && at callback.h:100:12

    frame #38: 0x0000000110aeb3a0 Cronet`base::TaskAnnotator::RunTask(this=0x00007f837840e470, trace_event_name="SequenceManager RunTask", pending_task=0x00007f8378823000) at task_annotator.cc:163:33

    frame #39: 0x0000000110b2cf16 Cronet`base::sequence_manager::internal::ThreadControllerWithMessagePumpImpl::DoWorkImpl(this=0x00007f837840e290, continuation_lazy_now=0x000070000a0ac990) at thread_controller_with_message_pump_impl.cc:332:23

    frame #40: 0x0000000110b2c69a Cronet`base::sequence_manager::internal::ThreadControllerWithMessagePumpImpl::DoWork(this=0x00007f837840e290) at thread_controller_with_message_pump_impl.cc:252:36

    frame #41: 0x0000000110b2d2cc Cronet`non-virtual thunk to base::sequence_manager::internal::ThreadControllerWithMessagePumpImpl::DoWork() at thread_controller_with_message_pump_impl.cc:0

    frame #42: 0x0000000110c177d4 Cronet`base::MessagePumpCFRunLoopBase::RunWork(this=0x00006000008f4100) at message_pump_mac.mm:358:54

    frame #43: 0x0000000110c178ec Cronet`invocation function for block in base::MessagePumpCFRunLoopBase::RunWorkSource(.block_descriptor=0x000070000a0acab8) at message_pump_mac.mm:335:11

    frame #44: 0x0000000110c0ea62 Cronet`base::mac::CallWithEHFrame(void () block_pointer) + 10

    frame #45: 0x0000000110c16eb5 Cronet`base::MessagePumpCFRunLoopBase::RunWorkSource(info=0x00006000008f4100) at message_pump_mac.mm:334:3

    frame #46: 0x00007fff20390ede CoreFoundation`__CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE0_PERFORM_FUNCTION__ + 17

    frame #47: 0x00007fff20390dd6 CoreFoundation`__CFRunLoopDoSource0 + 180

    frame #48: 0x00007fff2039029e CoreFoundation`__CFRunLoopDoSources0 + 242

    frame #49: 0x00007fff2038a9f7 CoreFoundation`__CFRunLoopRun + 875

    frame #50: 0x00007fff2038a1a7 CoreFoundation`CFRunLoopRunSpecific + 567

    frame #51: 0x00007fff20834204 Foundation`-[NSRunLoop(NSRunLoop) runMode:beforeDate:] + 209

    frame #52: 0x0000000110c1837c Cronet`base::MessagePumpNSRunLoop::DoRun(this=0x00006000008f4100, delegate=0x00007f837840e290) at message_pump_mac.mm:604:5

    frame #53: 0x0000000110c166d6 Cronet`base::MessagePumpCFRunLoopBase::Run(this=0x00006000008f4100, delegate=0x00007f837840e290) at message_pump_mac.mm:149:3

    frame #54: 0x0000000110b2da8b Cronet`base::sequence_manager::internal::ThreadControllerWithMessagePumpImpl::Run(this=0x00007f837840e290, application_tasks_allowed=true, timeout=(delta_ = 9223372036854775807)) at thread_controller_with_message_pump_impl.cc:446:12

    frame #55: 0x0000000110a9e55c Cronet`base::RunLoop::Run(this=0x000070000a0adec8) at run_loop.cc:124:14

    frame #56: 0x0000000110ba2022 Cronet`base::Thread::Run(this=0x00007f837840e100, run_loop=0x000070000a0adec8) at thread.cc:311:13

    frame #57: 0x0000000110ba25e4 Cronet`base::Thread::ThreadMain(this=0x00007f837840e100) at thread.cc:382:3

    frame #58: 0x0000000110c05e77 Cronet`base::(anonymous namespace)::ThreadFunc(params=0x00006000036f0660) at platform_thread_posix.cc:87:13

    frame #59: 0x00007fff603438fc libsystem_pthread.dylib`_pthread_start + 224

    frame #60: 0x00007fff6033f443 libsystem_pthread.dylib`thread_start + 15

(lldb) 

[Fan Yang]

I think this should have been fixed since 89.0.4331.0.

See the DCHECK now: https://source.chromium.org/chromium/chromium/src/+/main:net/quic/quic_chromium_client_stream.cc;drc=0176ff9a6d28f07c9a80f08a44a22d99c04c1c71;l=637

Thank you, Fan

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/proto-quic/CAEjGaqe%2BATNGgX%2BfuUuN2_uVp7493%2BptYLHPD2TA2RqOR4kh3A%40mail.gmail.com.

[Han]

That looks great! Thanks for the info!

Han

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/proto-quic/CAD_8i%2BRBVZzcaT9evF2Dwo%2BuQtrsZd%3DrnFvThAKu1nheV2eW-Q%40mail.gmail.com.