571710 - Crash [@ nsDocumentOpenInfo::TryContentListener]

Status: RESOLVED DUPLICATE of bug 559200

(Core :: IPC, defect)

Description

[Mark Finkle (:mfinkle) (use needinfo?)]

I am building Fennec using mobile-browser and electrolysis. While chrome:// pages are loading fine, I get a crash while loading http:// web pages:

#0  0xb77c7832 in ?? () from /lib/ld-linux.so.2
#1  0xb563ea76 in nanosleep () from /lib/tls/i686/cmov/libc.so.6
#2  0xb563e891 in sleep () from /lib/tls/i686/cmov/libc.so.6
#3  0xb5b2f2d9 in ah_crap_handler (signum=11) at /home/mfinkle/Source/mozilla-e10s/mozilla/toolkit/xre/nsSigHandlers.cpp:132
#4  0xb5b2f332 in child_ah_crap_handler (signum=11) at /home/mfinkle/Source/mozilla-e10s/mozilla/toolkit/xre/nsSigHandlers.cpp:145
#5  <signal handler called>
#6  0xb6f57a66 in NS_LogCOMPtrAddRef_P (aCOMPtr=0xb41a8800, aObject=0x65646e75)
    at /home/mfinkle/Source/mozilla-e10s/mozilla/xpcom/base/nsTraceRefcntImpl.cpp:1173
#7  0xb5b5aabd in ~nsGetterAddRefs (this=0xbfe95dec, __in_chrg=<value optimized out>) at ../../../dist/include/nsCOMPtr.h:1329
#8  0xb690f633 in nsDocumentOpenInfo::TryContentListener (this=0xb41a87f0, aListener=0xb1908850, aChannel=0xb16d9644)
    at /home/mfinkle/Source/mozilla-e10s/mozilla/uriloader/base/nsURILoader.cpp:757
#9  0xb690e3c6 in nsDocumentOpenInfo::DispatchContent (this=0xb41a87f0, request=0xb16d9644, aCtxt=0x0)
    at /home/mfinkle/Source/mozilla-e10s/mozilla/uriloader/base/nsURILoader.cpp:455
#10 0xb690d9a5 in nsDocumentOpenInfo::OnStartRequest (this=0xb41a87f0, request=0xb16d9644, aCtxt=0x0)
    at /home/mfinkle/Source/mozilla-e10s/mozilla/uriloader/base/nsURILoader.cpp:295
#11 0xb5c68d3e in mozilla::net::HttpChannelChild::RecvOnStartRequest (this=0xb16d9600, responseHead=...)
    at /home/mfinkle/Source/mozilla-e10s/mozilla/netwerk/protocol/http/HttpChannelChild.cpp:113
#12 0xb6e86b89 in mozilla::net::PHttpChannelChild::OnMessageReceived (this=0xb16d9600, __msg=...) at PHttpChannelChild.cpp:165
#13 0xb6e7167e in mozilla::dom::PContentProcessChild::OnMessageReceived (this=0xb412d038, __msg=...) at PContentProcessChild.cpp:536
#14 0xb6dab8fd in mozilla::ipc::AsyncChannel::OnDispatchMessage (this=0xb412d040, msg=...)
    at /home/mfinkle/Source/mozilla-e10s/mozilla/ipc/glue/AsyncChannel.cpp:262
#15 0xb6db3e1f in mozilla::ipc::RPCChannel::OnMaybeDequeueOne (this=0xb412d040) at /home/mfinkle/Source/mozilla-e10s/mozilla/ipc/glue/RPCChannel.cpp:438
#16 0xb6db9865 in void DispatchToMethod<mozilla::ipc::RPCChannel, bool (mozilla::ipc::RPCChannel::*)()>(mozilla::ipc::RPCChannel*, bool (mozilla::ipc::RPCChannel::*)(), Tuple0 const&) () from /home/mfinkle/Source/mozilla-e10s/mobile-debug/dist/bin/libxul.so
#17 0xb6db97f1 in RunnableMethod<mozilla::ipc::RPCChannel, bool (mozilla::ipc::RPCChannel::*)(), Tuple0>::Run() ()
   from /home/mfinkle/Source/mozilla-e10s/mobile-debug/dist/bin/libxul.so
#18 0xb6db55be in mozilla::ipc::RPCChannel::RefCountedTask::Run() () from /home/mfinkle/Source/mozilla-e10s/mobile-debug/dist/bin/libxul.so
#19 0xb6db56b6 in mozilla::ipc::RPCChannel::DequeueTask::Run() () from /home/mfinkle/Source/mozilla-e10s/mobile-debug/dist/bin/libxul.so
#20 0xb6fb7c92 in MessageLoop::RunTask (this=0xbfe97134, task=0xb16f6c40)
    at /home/mfinkle/Source/mozilla-e10s/mozilla/ipc/chromium/src/base/message_loop.cc:336
#21 0xb6fb7cfb in MessageLoop::DeferOrRunPendingTask (this=0xbfe97134, pending_task=...)
    at /home/mfinkle/Source/mozilla-e10s/mozilla/ipc/chromium/src/base/message_loop.cc:344
#22 0xb6fb80d1 in MessageLoop::DoWork (this=0xbfe97134) at /home/mfinkle/Source/mozilla-e10s/mozilla/ipc/chromium/src/base/message_loop.cc:444
#23 0xb6db11d3 in mozilla::ipc::DoWorkRunnable::Run (this=0xb4101800) at /home/mfinkle/Source/mozilla-e10s/mozilla/ipc/glue/MessagePump.cpp:75
#24 0xb6f43726 in nsThread::ProcessNextEvent (this=0xb4138150, mayWait=1, result=0xbfe964ec)
    at /home/mfinkle/Source/mozilla-e10s/mozilla/xpcom/threads/nsThread.cpp:547
#25 0xb6ed7739 in NS_ProcessNextEvent_P (thread=0xb4138150, mayWait=1) at nsThreadUtils.cpp:250
#26 0xb6db1645 in mozilla::ipc::MessagePump::Run (this=0xb4113130, aDelegate=0xbfe97134)
    at /home/mfinkle/Source/mozilla-e10s/mozilla/ipc/glue/MessagePump.cpp:142
#27 0xb6db1a72 in mozilla::ipc::MessagePumpForChildProcess::Run (this=0xb4113130, aDelegate=0xbfe97134)
    at /home/mfinkle/Source/mozilla-e10s/mozilla/ipc/glue/MessagePump.cpp:232
#28 0xb6fb77ef in MessageLoop::RunInternal (this=0xbfe97134) at /home/mfinkle/Source/mozilla-e10s/mozilla/ipc/chromium/src/base/message_loop.cc:216
#29 0xb6fb776f in MessageLoop::RunHandler (this=0xbfe97134) at /home/mfinkle/Source/mozilla-e10s/mozilla/ipc/chromium/src/base/message_loop.cc:199
#30 0xb6fb7713 in MessageLoop::Run (this=0xbfe97134) at /home/mfinkle/Source/mozilla-e10s/mozilla/ipc/chromium/src/base/message_loop.cc:173

Locals from frame #8:

(gdb) frame 8
#8  0xb690f633 in nsDocumentOpenInfo::TryContentListener (this=0xb41a87f0, aListener=0xb1908850, aChannel=0xb16d9644)
    at /home/mfinkle/Source/mozilla-e10s/mozilla/uriloader/base/nsURILoader.cpp:757
757	                                     &abort);
(gdb) info locals
listenerWantsContent = 1
loadFlags = 6881280
isPreferred = 0
rv = 0
typeToUse = {<nsCString> = {<nsACString_internal> = {mData = 0xb776e110 "", mLength = 0, mFlags = 3}, <No data fields>}, <No data fields>}
newLoadFlags = 1048576
originalListener = {mRawPtr = 0xb1908850}
abort = 0

Comment 1

[Doug Turner (:dougt)]

does this problem exist when you use the pavlov repo?

http://hg.mozilla.org/users/pavlov_mozilla.com/mobile-e10s/

Comment 2

[Mark Finkle (:mfinkle) (use needinfo?)]

(In reply to comment #1)
> does this problem exist when you use the pavlov repo?
> 
> http://hg.mozilla.org/users/pavlov_mozilla.com/mobile-e10s/

No, it does not. I'll work on figuring out the difference. It's a bit troubling that a JS difference is causing a crash, in any case.

Comment 3

[Boris Zbarsky [:bzbarsky]]

Mark, when you see this, what's the concrete type of aListener?

Comment 4

[Mark Finkle (:mfinkle) (use needinfo?)]

Boris, here is the info on aListener:

(gdb) info args
this = 0xb101d820
aListener = 0xb10438b0
aChannel = 0xaf007244
(gdb) p aListener
$1 = (class nsIURIContentListener *) 0xb10438b0
(gdb) x/wa *(void**)aListener
0xb763a028 <_ZTV22nsDSURIContentListener+8>:	0xb6863396 <_ZN22nsDSURIContentListener14QueryInterfaceERK4nsIDPPv>
(gdb) p *(nsDSURIContentListener*)aListener
$2 = {<nsIURIContentListener> = {<nsISupports> = {
      _vptr.nsISupports = 0xb763a028}, <No data fields>}, <nsSupportsWeakReference> = {<nsISupportsWeakReference> = {<nsISupports> = {
        _vptr.nsISupports = 0xb763a064}, <No data fields>}, mProxy = 0x0}, mRefCnt = {mValue = 2}, _mOwningThread = {mThread = 0xb4111060}, 
  mDocShell = 0xb17c64f0, mWeakParentContentListener = {mRawPtr = 0x0}, mParentContentListener = 0x0, mNavInfo = {mRawPtr = 0xb10427a0}}

Comment 5

[Boris Zbarsky [:bzbarsky]]

Ok, and in NS_LogCOMPtrAddRef_P what can you tell me about aObject?

Comment 6

[Mark Finkle (:mfinkle) (use needinfo?)]

(gdb) frame 6
#6  0xb6e99cda in NS_LogCOMPtrAddRef_P (aCOMPtr=0xb41d6b60, aObject=0x5a5a5a5a)
    at /home/mfinkle/Source/mozilla-e10s/mozilla/xpcom/base/nsTraceRefcntImpl.cpp:1173
1173	  void *object = dynamic_cast<void *>(aObject);
(gdb) info args
aCOMPtr = 0xb41d6b60
aObject = 0x5a5a5a5a
(gdb) p aObject
$1 = (nsISupports *) 0x5a5a5a5a
(gdb) x/wa *(void**)aObject
Cannot access memory at address 0x5a5a5a5a

Comment 7

[Boris Zbarsky [:bzbarsky]]

OK.  Can someone point me to the relevant impl of nsDSURIContentListener (that is point me at the correct branch on hg.mozilla.org, or better yet in mxr)?

Though given that 0x5a5a5a5a is "jemalloc freed junk memory" according to firebot, it sounds likely that someone is just messing up refcounting somewhere and the problem isn't actually in nsDSURIContentListener

Comment 8

[Mark Finkle (:mfinkle) (use needinfo?)]

DougT says that using NECKO_SEPARATE_STACKS=1 stops the crash.

Comment 9

[Boris Zbarsky [:bzbarsky]]

ok, but does doing an http:// load in a chrome docshell bring it back?

Comment 10

[Doug Turner (:dougt)]

http://mxr.mozilla.org/projects-central/source/electrolysis/netwerk/protocol/http/HttpChannelChild.cpp#169

Do we want to clear the context here or in the destructor?

Comment 11

[Boris Zbarsky [:bzbarsky]]

There, if you don't want to leak.

Comment 12

[Josh Matthews [:jdm]]

We've established that this is just the old RPC/necko fiasco biting us again.

Comment 13

[Doug Turner (:dougt)]

just to add what we are seeing:

Basically what is happening is fennec calls sendSyncMessage from its necko
callbacks.  sendSyncMessage spins an event loop, and processes all IPC messages
until it hears back that the sync call was successful.  One of these messages,
sometimes, is onStopRequest which is dispatched.  The handler releases the
listener and the context which both are deleted.  At some point later, the sync
ack is received, and we leave the nested loop.  Now, we are in a hosed state
because the listener has been deleted.