net::QuicHttpStream::DoCallback crash when there is an upload |
||||||
Issue description
In Cronet release builds, QUIC sometimes crashes at net::QuicHttpStream::DoCallback with the following stack trace.
#00 pc libcronet.so: 00181950: base::internal::CallbackBase<(base::internal::CopyMode)1>::CallbackBase(base::internal::CallbackBase<(base::internal::CopyMode)1> const&)+16
#01 pc libcronet.so: 000c43a6: net::QuicHttpStream::DoCallback(int)+286
#02 pc libcronet.so: 00096b6c: base::internal::Invoker<base::IndexSequence<0u>, base::internal::BindState<base::internal::RunnableAdapter<void (net::QuicHttpStream::*)(int)>, void (net::QuicHttpStream*, int), base::WeakPtr<net::QuicHttpStream> >, base::internal::InvokeHelper<true, void, base::internal::RunnableAdapter<void (net::QuicHttpStream::*)(int)> >, void (int)>::Run(base::internal::BindStateBase*, int&&)+84
#03 pc libcronet.so: 000497b0: net::UploadDataStream::OnReadCompleted(int)+74
#04 pc libcronet.so: 0001c8ec: base::internal::Invoker<base::IndexSequence<0u, 1u, 2u>, base::internal::BindState<base::internal::RunnableAdapter<void (cronet::CronetUploadDataStream::*)(int, bool)>, void (cronet::CronetUploadDataStream*, int, bool), base::WeakPtr<cronet::CronetUploadDataStream>&, int&, bool&>, base::internal::InvokeHelper<true, void, base::internal::RunnableAdapter<void (cronet::CronetUploadDataStream::*)(int, bool)> >, void ()>::Run(base::internal::BindStateBase*)+76
#05 pc libcronet.so: 00182e48: base::debug::TaskAnnotator::RunTask(char const*, base::PendingTask const&)+112
#06 pc libcronet.so: 0018cd0c: base::MessageLoop::RunTask(base::PendingTask const&)+92
#07 pc libcronet.so: 0018d152: base::MessageLoop::DeferOrRunPendingTask(base::PendingTask const&)+130
#08 pc libcronet.so: 0018d3e4: base::MessageLoop::DoWork()+132
#09 pc libcronet.so: 0018e340: base::MessagePumpLibevent::Run(base::MessagePump::Delegate*)+112
#10 pc libcronet.so: 00197680: base::RunLoop::Run()+68
#11 pc libcronet.so: 0018c74c: base::MessageLoop::Run()+12
#12 pc libcronet.so: 001a25d4: base::Thread::ThreadMain()+184
#13 pc libcronet.so: 001a052a: base::(anonymous namespace)::ThreadFunc(void*)+50
#14 pc 0000d278 /system/lib/libc.so (__thread_entry+72)
#15 pc 0000d410 /system/lib/libc.so (pthread_create+240)
This happens in M52, see internal bug 29549523 for more details.
,
Jul 11 2016
I just realized that Raman is OOO for three weeks. I will try investigating this issue.
,
Jul 11 2016
The latest crash is reported in Cronet v53_0_2768_0. I am having a hard time in figuring out the code path that would lead to this crash stack. The synchronous write failure Bug 577377 is handled by Raman's fix. I don't see an edge case where that isn't covered. Quic folks and Matt: any possible way that would lead to this?
,
Jul 11 2016
Happy to help dig into this, but I have a lot of catching up to do this week, so may be a couple days (Or even next week) before I can dig into this.
,
Jul 11 2016
This accounts for 30% of Cronet crashers for our embedder. Is it okay to prioritize? Thanks a lot for the help! I will keep looking into this, but would really appreciate someone who knows the QUIC code or the Upload code could take a look too. Thanks!
,
Jul 11 2016
Unfortunately, I have a bunch of codereviews on my plate that have waited more than long enough, and HTTP/0.9 deprecation due to a security issue on my plate, both of which seem higher priority than investigating a non-regression issue that we can work around by disabling QUIC, until we can figure it out. I do agree that this is high priority, but just have too much in my queue.
,
Jul 12 2016
Spent a day looking at this, but I didn't find anything useful. I looked in QuicHttpStream and the layer above it. I also didn't see anything in UploadDataStream or CronetUploadDataStream.
,
Jul 13 2016
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/1f48e6ebda2ca94af20d049aff0863244232ffc5 commit 1f48e6ebda2ca94af20d049aff0863244232ffc5 Author: xunjieli <xunjieli@chromium.org> Date: Wed Jul 13 22:53:04 2016 Add CHECK to make sure QuicHttpStream does not get destroyed during DoLoop A fewer crashers on QuicHttpStream::DoReadRequestBody indicate that QuicHttpStream might be destroyed in the middle of DoLoop. The crashers are pretty rare. This CL adds a bool so that if QuicHttpStream gets destroyed during DoLoop, we will get the call stack which will tell us how it is being destroyed. BUG= 627099 Review-Url: https://codereview.chromium.org/2140673006 Cr-Commit-Position: refs/heads/master@{#405328} [modify] https://crrev.com/1f48e6ebda2ca94af20d049aff0863244232ffc5/net/quic/quic_http_stream.cc [modify] https://crrev.com/1f48e6ebda2ca94af20d049aff0863244232ffc5/net/quic/quic_http_stream.h
,
Jul 20 2016
We are getting a few CHECK crashers from Mac Canary. Attaching the bug number here for record keeping.
,
Dec 19 2016
,
Dec 19 2016
|
||||||
►
Sign in to add a comment |
||||||
Comment 1 by xunji...@chromium.org
, Jul 11 2016