New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.

Issue 810883 link

Starred by 1 user

Issue metadata

Status: Untriaged
Owner: ----
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Android
Pri: 2
Type: Bug



Sign in to add a comment

|writer_| is null in QuicConnection::WriteIfNotBlocked()

Project Member Reported by kapishnikov@chromium.org, Feb 9 2018

Issue description

********** Crash dump: **********
signal 11 (SIGSEGV), code 1 (SEGV_MAPERR), fault addr 0x0
Stack frame #00 pc 0010e1c8  libcronet.65.0.3322.0.so: Routine net::QuicConnection::WriteIfNotBlocked() at net/quic/core/quic_connection.cc:1394
Stack frame #01 pc 0010e9c9  libcronet.65.0.3322.0.so: Routine net::QuicConnection::OnRetransmissionTimeout() at net/quic/core/quic_connection.cc:1981
Stack frame #02 pc 000f1671  libcronet.65.0.3322.0.so: Routine net::(anonymous namespace)::QuicChromeAlarm::OnAlarm() at net/quic/chromium/quic_chromium_alarm_factory.cc:76
Stack frame #03 pc 00028cb7  libcronet.65.0.3322.0.so: Routine base::OnceCallback<void ()>::Run() && at base/callback.h:65
Stack frame #04 pc 0003427b  libcronet.65.0.3322.0.so: Routine base::MessageLoop::RunTask(base::PendingTask*) at base/message_loop/message_loop.cc:399
Stack frame #05 pc 00034691  libcronet.65.0.3322.0.so: Routine base::MessageLoop::DeferOrRunPendingTask(base::PendingTask) at base/message_loop/message_loop.cc:411
Stack frame #06 pc 000353c7  libcronet.65.0.3322.0.so: Routine base::MessagePumpLibevent::Run(base::MessagePump::Delegate*) at base/message_loop/message_pump_libevent.cc:230
Stack frame #07 pc 0003fa21  libcronet.65.0.3322.0.so: Routine base::RunLoop::Run() at base/run_loop.cc:130
Stack frame #08 pc 00054ba5  libcronet.65.0.3322.0.so: Routine base::Thread::ThreadMain() at base/threading/thread.cc:338
Stack frame #09 pc 000527d5  libcronet.65.0.3322.0.so: Routine base::(anonymous namespace)::ThreadFunc(void*) at base/threading/platform_thread_posix.cc:75
Stack frame #10 pc 00047653  /system/lib/libc.so (_ZL15__pthread_startPv+22)
Stack frame #11 pc 00019ded  /system/lib/libc.so (__start_thread+6)


Internal bug: b/73129963

 

Comment 1 by mef@chromium.org, Feb 27 2018

Cc: rch@chromium.org zhongyi@chromium.org
ping
Summarizing discussions with rch@ and kapishnikov@. 

*About the crash stack
the crash happens in 
QuicConnection::WriteIfNotBlocked() {
                                            <-------------crash
  if (!writer_->IsWriteBlocked()) {
    // ....
  }
}

The writer_ is nulled, and IsWriteBlocked is a virtual method, it cannot resolve the function from the vtable and thus crashes before calling it.  

* What's the state of connection and writer: possibly both are null.
In chromium, QuicConnection always owns writer_.
writer_ gets set to a new value in MigrateToNewSocket, which is only used connection migration/server migration which is not running other than in AGSA.
writer_ will be deleted in connection destructor but still never sets to null.
In other words, it seems the connection_ is also nulled, which might explains the stack as both QuicConnection::OnRetransmissionTimeout and QuicConnection::WriteIfNotBlocked are non-virtual. 

* How could the rtxmission alarm fires?
That's something needs more investigation, the connection owns the alarm, the alarm posted delayed task with a WeakPtr. Destructing connection should automatically cleans up the alarm, and the alarm shouldn't fire after connection being destructed. I wonder whether this was from devices that has corrupted memory. 

* Rate of the bug:
Chrome crash stats indicated this issue is also present in Chrome_Android.
64.0.3282.137	16.67%	1
63.0.3239.111	16.67%	1
62.0.3202.84	33.33%	2
61.0.3163.98	16.67%	1
43.0.2357.93	16.67%	1
Total:	100.00%	6
Labels: -Pri-1 Pri-2
Lower down the priority since this crash rate is low, feel free to change if the crash rate goes up. 
Might have same cause with http://crbug.com/822433.

Comment 5 by mef@chromium.org, Apr 26 2018

Blockedon: 835425
Cherie, WDYT, is this dup of https://bugs.chromium.org/p/chromium/issues/detail?id=835425 that was fixed recently?
Blockedon: -835425
Most likely not, this crash is caused by writer being nulled out when we call WriteIfNotBlocked. The one we fixed was a writer blocked check. 

Sign in to add a comment