1258553 - Shutdown crash in FailedAsyncOpenEvent::Run, because its HttpChannelChild* mChild has already been deleted

Status: RESOLVED DUPLICATE of bug 1256336

(Core :: Networking, defect)

Description

[Daniel Holbert [:dholbert]]

I just ran into a shutdown crash in my debug build.  I don't have STR; I suspect it's a race condition of some sort & might be difficult to reproduce reliably.


The crash backtrace is:
{
#5  0x00007f725e6b5d10 in <signal handler called> ()
    at /lib/x86_64-linux-gnu/libpthread.so.0
#6  0x00007f7254b3b764 in RefPtr<mozilla::net::HttpChannelChild>::assign_assuming_AddRef(mozilla::net::HttpChannelChild*) (this=0xe5e5e5e5e5e5e5f5, aNewPtr=0x0)
    at $OBJ/dist/include/mozilla/RefPtr.h:61
#7  0x00007f7254b3b749 in RefPtr<mozilla::net::HttpChannelChild>::assign_with_AddRef(mozilla::net::HttpChannelChild*) (this=0xe5e5e5e5e5e5e5f5, aRawPtr=0x0)
    at $OBJ/dist/include/mozilla/RefPtr.h:55
#8  0x00007f7254b2b99f in RefPtr<mozilla::net::HttpChannelChild>::operator=(mozilla::net::HttpChannelChild*) (this=0xe5e5e5e5e5e5e5f5, aRhs=0x0)
    at $OBJ/dist/include/mozilla/RefPtr.h:174
#9  0x00007f7254afcdc7 in mozilla::net::InterceptStreamListener::Cleanup() (this=0xe5e5e5e5e5e5e5e5)
    at $SRC/netwerk/protocol/http/HttpChannelChild.cpp:145
#10 0x00007f7254b00eee in mozilla::net::HttpChannelChild::DoNotifyListenerCleanup() (this=0x7f722da63000)
    at $SRC/netwerk/protocol/http/HttpChannelChild.cpp:1101
#11 0x00007f7254af7ce3 in mozilla::net::HttpBaseChannel::DoNotifyListener() (this=0x7f722da63030)
    at $SRC/netwerk/protocol/http/HttpBaseChannel.cpp:2625
#12 0x00007f7254b2c8e9 in mozilla::net::HttpAsyncAborter<mozilla::net::HttpChannelChild>::HandleAsyncAbort() (this=0x7f722da634a8)
    at $SRC/netwerk/protocol/http/HttpBaseChannel.h:575
#13 0x00007f7254b00d8c in mozilla::net::HttpChannelChild::HandleAsyncAbort() (this=0x7f722da63000)
    at $SRC/netwerk/protocol/http/HttpChannelChild.cpp:1080
#14 0x00007f7254b00e28 in mozilla::net::HttpChannelChild::FailedAsyncOpen(nsresult const&) (this=0x7f722da63000, status=@0x7f722da0dc90: nsresult::NS_ERROR_NOT_AVAILABLE)
    at $SRC/netwerk/protocol/http/HttpChannelChild.cpp:1091
#15 0x00007f7254b36cd8 in mozilla::net::FailedAsyncOpenEvent::Run() (this=0x7f722da0dc80)
    at $SRC/netwerk/protocol/http/HttpChannelChild.cpp:1060
#16 0x00007f7254a9fa05 in mozilla::net::ChannelEventQueue::RunOrEnqueue(mozilla::net::ChannelEvent*, bool) (this=0x7f722da9ea10, aCallback=0x7f722da0dc80, aAssertionWhenNotQueued=false)
    at $OBJ/dist/include/mozilla/net/ChannelEventQueue.h:133
#17 0x00007f7254b00d56 in mozilla::net::HttpChannelChild::RecvFailedAsyncOpen(nsresult const&) (this=0x7f722da63000, status=@0x7ffcc42d0744: nsresult::NS_ERROR_NOT_AVAILABLE)
    at $SRC/netwerk/protocol/http/HttpChannelChild.cpp:1070
#18 0x00007f7254f72c0a in mozilla::net::PHttpChannelChild::OnMessageReceived(IPC::Message const&) (this=0x7f722da63000, msg__=...)
    at $OBJ/ipc/ipdl/PHttpChannelChild.cpp:718
#19 0x00007f725547cd40 in mozilla::dom::PContentChild::OnMessageReceived(IPC::Message const&) (this=0x7f7247f85030, msg__=...)
    at $OBJ/ipc/ipdl/PContentChild.cpp:6241
#20 0x00007f7254de6cc3 in mozilla::ipc::MessageChannel::DispatchAsyncMessage(IPC::Message const&) (this=0x7f7247f85098, aMsg=...)
    at $SRC/ipc/glue/MessageChannel.cpp:1630
#21 0x00007f7254de5ebe in mozilla::ipc::MessageChannel::DispatchMessage(IPC::Message const&) (this=0x7f7247f85098, aMsg=...)
    at $SRC/ipc/glue/MessageChannel.cpp:1568
#22 0x00007f7254de0cb2 in mozilla::ipc::MessageChannel::OnMaybeDequeueOne() (this=0x7f7247f85098)
    at $SRC/ipc/glue/MessageChannel.cpp:1535
#23 0x00007f7254e0427a in details::CallMethod<, mozilla::ipc::MessageChannel, bool (mozilla::ipc::MessageChannel::*)()>(mozilla::IndexSequence<>, mozilla::ipc::MessageChannel*, bool (mozilla::ipc::MessageChannel::*)(), mozilla::Tuple<>&) (obj=0x7f7247f85098, method=(bool (mozilla::ipc::MessageChannel::*)(mozilla::ipc::MessageChannel * const)) 0x7f7254de0b90 <mozilla::ipc::MessageChannel::OnMaybeDequeueOne()>, arg=...)
    at $SRC/ipc/chromium/src/base/task.h:28
#24 0x00007f7254e041f5 in DispatchTupleToMethod<mozilla::ipc::MessageChannel, bool (mozilla::ipc::MessageChannel::*)()>(mozilla::ipc::MessageChannel*, bool (mozilla::ipc::MessageChannel::*)(), mozilla::Tuple<>&) (obj=0x7f7247f85098, method=(bool (mozilla::ipc::MessageChannel::*)(mozilla::ipc::MessageChannel * const)) 0x7f7254de0b90 <mozilla::ipc::MessageChannel::OnMaybeDequeueOne()>, arg=...) at $SRC/ipc/chromium/src/base/task.h:46
#25 0x00007f7254e0412b in RunnableMethod<mozilla::ipc::MessageChannel, bool (mozilla::ipc::MessageChannel::*)(), mozilla::Tuple<> >::Run() (this=
    0x7f7247f1bf40)
    at $SRC/ipc/chromium/src/base/task.h:307
#26 0x00007f7254e022b8 in mozilla::ipc::MessageChannel::RefCountedTask::Run() (this=0x7f7247f17750)
    at $OBJ/dist/include/mozilla/ipc/MessageChannel.h:475
#27 0x00007f7254e02191 in mozilla::ipc::MessageChannel::DequeueTask::Run() (this=0x7f7234a390e0)
    at $OBJ/dist/include/mozilla/ipc/MessageChannel.h:492
#28 0x00007f7254d2d550 in MessageLoop::RunTask(Task*) (this=0x7ffcc42d4018, task=0x7f7234a390e0)
    at $SRC/ipc/chromium/src/base/message_loop.cc:364
#29 0x00007f7254d2daaf in MessageLoop::DeferOrRunPendingTask(MessageLoop::PendingTask const&) (this=0x7ffcc42d4018, pending_task=...)
    at $SRC/ipc/chromium/src/base/message_loop.cc:372
#30 0x00007f7254d2dcc5 in MessageLoop::DoWork() (this=0x7ffcc42d4018)
    at $SRC/ipc/chromium/src/base/message_loop.cc:459
#31 0x00007f7254de9c6e in mozilla::ipc::DoWorkRunnable::Run() (this=0x7f7247f72760)
    at $SRC/ipc/glue/MessagePump.cpp:222
#32 0x00007f72547341b8 in nsThread::ProcessNextEvent(bool, bool*) (this=0x7f7246fafd00, aMayWait=false, aResult=0x7ffcc42d3c5e)
    at $SRC/xpcom/threads/nsThread.cpp:994
#33 0x00007f72547ac98c in NS_ProcessNextEvent(nsIThread*, bool) (aThread=0x7f7246fafd00, aMayWait=false)
}


Note the "this=0xe5e5e5e5e5e5e5e5" in stack level 9. Everything inside of that is toast.  This is presumably because at stack level 10, we're working with an object (a HttpChannelChild instance) whose memory has been freed & overwritten.  So we make a function-call to one of its member variables, but the member variable has a bogus pointer address.

Comment 1

[Daniel Holbert [:dholbert]]

Attachment: backtrace of crash

Comment 2

[Daniel Holbert [:dholbert]]

My STR here was basically:
 1) Start my Firefox debug build (built from mozilla-inbound tip from this morning, with a few layout/CSS gecko patches applied on top)
 2) Visit a Baidu search page in responsive design mode: http://m.baidu.com/s?word=Firefox
 3) File|Quit
 4) Notice that my terminal indicates that I've crashed. Attach GDB, capture backtrace, file bug.

(I have low confidence that this is reproducible with those STR; just posting them for the record.)

Comment 3

[Daniel Holbert [:dholbert]]

At stack level 14 (the outermost HttpChannelChild function-call), if I do "p *this" in gdb, it looks like every single member-var is 0xe5e5...e5:
> (gdb) p *this
>   <mozilla::net::PHttpChannelChild> = {
>     <mozilla::ipc::IProtocol> = {
>       <mozilla::ipc::MessageListener> = {
>         <mozilla::ipc::HasResultCodes> = {<No data fields>}, 
>         <mozilla::SupportsWeakPtr<mozilla::ipc::MessageListener>> = {
>           mSelfReferencingWeakPtr = {
>             mRef = {
>               mRawPtr = 0xe5e5e5e5e5e5e5e5
>             }
>           }
>         }, 
>         members of mozilla::ipc::MessageListener: 
>         _vptr$MessageListener = 0xe5e5e5e5e5e5e5e5
>       }, <No data fields>}, 
>     <mozilla::ipc::IProtocolManager<mozilla::ipc::IProtocol>> = {
>       _vptr$IProtocolManager = 0xe5e5e5e5e5e5e5e5
> [...]

Up one level from that (in Run), our FailedAsyncOpenEvent object seems to be alive -- it has valid member-data.

Note that FailedAsyncOpenEvent's "HttpChannelChild* mChild" pointer is a raw pointer (it's not a RefPtr).  So, superficially, it's not clear to me that we currently have any assurance that mChild must still be alive when the event fires.  And clearly, it's not alive in this instance when the event fired.

Comment 4

[Andrew McCreight [:mccr8]]

Oops, looks like that is for top crashes, so I'll remove the blocking.

Comment 6

[Patrick McManus [:mcmanus]]

(In reply to Dragana Damjanovic [:dragana] from comment #5)
> 
> *** This bug has been marked as a duplicate of bug 1256336 ***

that's what I was hoping :)