1223056 - When using webrtc, Assertion failure: aManagees.Count() == 1, at ../../dist/include/mozilla/ipc/ProtocolUtils.h:344

Status: NEW

(Core :: IPC, defect)

Description

[Byron Campen [:bwc]]

When running a debug build on either linux or OS X, attempting to use webrtc hits the following assertion (100% reproducible):

Assertion failure: aManagees.Count() == 1, at ../../dist/include/mozilla/ipc/ProtocolUtils.h:344

Bisection reveals that this started happening due to the patches on bug 1212027 (somewhere between parts 4 and 7).

It is unclear whether this is a new defect, or a case of a new assertion detecting a pre-existing defect.

Comment 1

[Nathan Froyd [:froydnj]]

Could you include a backtrace?  The assert on its own isn't really helpful.

We added the assert in bug 1212027 because a lot of code was doing something like x->ManagedPFoo()[0], and it wasn't clear whether the author was trying to grab the first and only managed PFoo, or whether they were trying to grab a random one.  The former seemed more common, so the assert was added to catch the latter case.  Best to analyze the crashing code and figure out what it's really trying to do.

Comment 2

[Byron Campen [:bwc]]

Here you go:

#0  0x00002b43767a31bd in nanosleep () at /lib64/libc.so.6
#1  0x00002b43767a3054 in sleep () at /lib64/libc.so.6
#2  0x00002b438fc7cf22 in ah_crap_handler(int) (signum=11) at /home/bcampen/checkouts/mozilla-central/toolkit/xre/nsSigHandlers.cpp:103
#3  0x00002b438fc52aa4 in nsProfileLock::FatalSignalHandler(int, siginfo_t*, void*) (signo=11, info=<optimized out>, context=<optimized out>) at /home/bcampen/checkouts/mozilla-central/toolkit/profile/nsProfileLock.cpp:195
#4  0x00002b4392d2bcb2 in AsmJSFaultHandler(int, siginfo_t*, void*) (signum=<optimized out>, info=<optimized out>, context=<optimized out>) at /home/bcampen/checkouts/mozilla-central/js/src/asmjs/AsmJSSignalHandlers.cpp:1158
#5  0x00002b43758990d0 in <signal handler called> () at /lib64/libpthread.so.0
#6  0x00002b438d78198c in mozilla::LoneManagedOrNull<mozilla::dom::PBrowserParent>(nsTHashtable<nsPtrHashKey<mozilla::dom::PBrowserParent> > const&) (aManagees=...) at ../../dist/include/mozilla/ipc/ProtocolUtils.h:344
#7  0x00002b438d76dead in mozilla::dom::TCPSocketParent::RecvOpenBind(nsCString const&, unsigned short const&, nsCString const&, unsigned short const&, bool const&, bool const&) (this=<optimized out>, aRemoteHost=..., aRemotePort=<optimized out>, aLocalAddr=..., aLocalPort=<optimized out>, aUseSSL=<optimized out>, aUseArrayBuffers=<optimized out>) at /home/bcampen/checkouts/mozilla-central/dom/network/TCPSocketParent.cpp:226
#8  0x00002b4389730d02 in mozilla::net::PTCPSocketParent::OnMessageReceived(IPC::Message const&) (this=<optimized out>, msg__=...) at ./PTCPSocketParent.cpp:318
#9  0x00002b4389ab952a in mozilla::dom::PContentParent::OnMessageReceived(IPC::Message const&) (this=<optimized out>, msg__=...) at ./PContentParent.cpp:3556
#10 0x00002b438915e9a9 in mozilla::ipc::MessageChannel::DispatchAsyncMessage(IPC::Message const&) (this=0x61e0001d58e8, aMsg=...) at /home/bcampen/checkouts/mozilla-central/ipc/glue/MessageChannel.cpp:1389
#11 0x00002b438915cd57 in mozilla::ipc::MessageChannel::DispatchMessage(IPC::Message const&) (this=<optimized out>, aMsg=...) at /home/bcampen/checkouts/mozilla-central/ipc/glue/MessageChannel.cpp:1309
#12 0x00002b4389152d98 in mozilla::ipc::MessageChannel::OnMaybeDequeueOne() (this=0x61e0001d58e8) at /home/bcampen/checkouts/mozilla-central/ipc/glue/MessageChannel.cpp:1280
#13 0x00002b438906855f in MessageLoop::RunTask(Task*) (this=<optimized out>, task=0x6030000a0990) at /home/bcampen/checkouts/mozilla-central/ipc/chromium/src/base/message_loop.cc:364
#14 0x00002b4389069242 in MessageLoop::DeferOrRunPendingTask(MessageLoop::PendingTask const&) (this=0x744a00 <InitializeCommonInterceptors()::metadata_mem>, pending_task=...)
    at /home/bcampen/checkouts/mozilla-central/ipc/chromium/src/base/message_loop.cc:372
#15 0x00002b438906967b in MessageLoop::DoWork() (this=<optimized out>) at /home/bcampen/checkouts/mozilla-central/ipc/chromium/src/base/message_loop.cc:459
#16 0x00002b4389164200 in mozilla::ipc::DoWorkRunnable::Run() (this=<optimized out>) at /home/bcampen/checkouts/mozilla-central/ipc/glue/MessagePump.cpp:220
#17 0x00002b4388780eb8 in nsThread::ProcessNextEvent(bool, bool*) (this=<optimized out>, aMayWait=<optimized out>, aResult=<optimized out>) at /home/bcampen/checkouts/mozilla-central/xpcom/threads/nsThread.cpp:972
#18 0x00002b438881b038 in NS_ProcessNextEvent(nsIThread*, bool) (aThread=<optimized out>, aMayWait=false) at /home/bcampen/checkouts/mozilla-central/xpcom/glue/nsThreadUtils.cpp:297
#19 0x00002b4389163518 in mozilla::ipc::MessagePump::Run(base::MessagePump::Delegate*) (this=<optimized out>, aDelegate=<optimized out>) at /home/bcampen/checkouts/mozilla-central/ipc/glue/MessagePump.cpp:95
#20 0x00002b43890681fa in MessageLoop::RunInternal() (this=<optimized out>) at /home/bcampen/checkouts/mozilla-central/ipc/chromium/src/base/message_loop.cc:234
#21 0x00002b4389067d37 in MessageLoop::Run() (this=0x2b43756a3940) at /home/bcampen/checkouts/mozilla-central/ipc/chromium/src/base/message_loop.cc:227
#22 0x00002b4389067d37 in MessageLoop::Run() (this=<optimized out>) at /home/bcampen/checkouts/mozilla-central/ipc/chromium/src/base/message_loop.cc:201
#23 0x00002b438e0b72c9 in nsBaseAppShell::Run() (this=<optimized out>) at /home/bcampen/checkouts/mozilla-central/widget/nsBaseAppShell.cpp:156
#24 0x00002b438fb87e24 in nsAppStartup::Run() (this=0x60700008cf70) at /home/bcampen/checkouts/mozilla-central/toolkit/components/startup/nsAppStartup.cpp:281
#25 0x00002b438fc6cd36 in XREMain::XRE_mainRun() (this=<optimized out>) at ../../../toolkit/xre/nsAppRunner.cpp:4298
#26 0x00002b438fc6d966 in XREMain::XRE_main(int, char**, nsXREAppData const*) (this=0x7fff483a0760, argc=<optimized out>, argv=<optimized out>, aAppData=<optimized out>) at ../../../toolkit/xre/nsAppRunner.cpp:4391
#27 0x00002b438fc6e5f4 in XRE_main(int, char**, nsXREAppData const*, uint32_t) (argc=4, argv=<optimized out>, aAppData=<optimized out>, aFlags=<optimized out>) at ../../../toolkit/xre/nsAppRunner.cpp:4493
#28 0x00000000004bd79e in main(int, char**) (argc=<optimized out>, argv=<optimized out>, xreDirectory=0x610000005640) at ../../../browser/app/nsBrowserApp.cpp:212
#29 0x00000000004bd79e in main(int, char**) (argc=<optimized out>, argv=<optimized out>) at ../../../browser/app/nsBrowserApp.cpp:352

Comment 3

[Nathan Froyd [:froydnj]]

Thanks for the backtrace.

Look like TCPSocketParent:

http://mxr.mozilla.org/mozilla-central/source/dom/network/TCPSocketParent.cpp#226

I would expect PContent to only be managing a single PBrowser?  Josh, are you still familiar with this code?  What is RecvOpenBind really trying to do here?

Comment 4

[Josh Matthews [:jdm]]

Jesup will be in a better position to answer that question than me.

Comment 5

[Josh Matthews [:jdm]]

Why do we expect PContent to only manage a single PBrowser, though? There's a separate PBrowser for each tab in a content process.

Comment 6

[Nathan Froyd [:froydnj]]

(In reply to Josh Matthews [:jdm] from comment #5)
> Why do we expect PContent to only manage a single PBrowser, though? There's
> a separate PBrowser for each tab in a content process.

OK, so I am ignorant of our IPC setup!  But this code was just grabbing the first managed PBrowser before...is the first PBrowser in the managed list guaranteed to have the app ID?  Or was the first one simply convenient, and all the other ones also have the app ID?

Comment 7

[Josh Matthews [:jdm]]

When it comes to b2g, I believe we do app-per-process so it's reasonable to assume that any PBrowser will provide the appropriate info.

Comment 8

[Jed Davis [:jld] ⟨⏰|UTC-7⟩ ⟦he/him⟧]

Back in bug 1212027 comment #14 I commented on this assertion:
> I wonder if we'll discover anything “interesting” that way, especially about the PBrowser instances.

B2G is app-per-process, and if I understand correctly that also implies only one PBrowser per PContent.  Desktop can have a lot of unrelated PBrowsers in the same PContent, so that assertion failure would be pointing out an actual bug, and from comment #0 it sounds like this was desktop.  But… since when do we use mozTCPSocket on desktop?

Comment 9

[Josh Matthews [:jdm]]

We use it for something related to WebRTC.

Comment 10

[Randell Jesup [:jesup] (needinfo me)]

(In reply to Jed Davis [:jld] from comment #8)
> Back in bug 1212027 comment #14 I commented on this assertion:
> > I wonder if we'll discover anything “interesting” that way, especially about the PBrowser instances.
> 
> B2G is app-per-process, and if I understand correctly that also implies only
> one PBrowser per PContent.  Desktop can have a lot of unrelated PBrowsers in
> the same PContent, so that assertion failure would be pointing out an actual
> bug, and from comment #0 it sounds like this was desktop.  But… since when
> do we use mozTCPSocket on desktop?

We use TCPSocket for WebRTC (media/mtransport in particular) when using TCP TURN (and will be using it for ICE-TCP).  Sometimes UDP is blocked, and we need to use TCP (bounced off a TURN (relay) server) to connect.  TCP sucks for audio/video in realtime, but it's better than no connection.  For e10s, we had to use (and modify) TCPSocket so we can create these connections.  (We do something similar for UDPSocket for most WebRTC connections).  

UDPSocket has been modified to run over PBackground (touching MainThread is bad bad bad for realtime).  We plan to do something similar to TCPSocket, but step one was to get it working at all on e10s (and TCP is our fallback to begin with; we always prefer UDP).

As to the details about RecvOpenBind... I'll have to go back and check.  I ported the code originally written by Patrick to the updated c++ impl done by jdm, but I didn't write it.

Comment 11

[Jed Davis [:jld] ⟨⏰|UTC-7⟩ ⟦he/him⟧]

TCPSocket::SetAppIdAndBrowser is a no-op on non-MOZ_WIDGET_GONK, so the values that TCPSocketParent::RecvOpenBind wants to get from the TabParent are unused, which means I think the LoneManagee part could be ifdef'ed the same way.  (I'd have expected MOZ_CHILD_PERMISSIONS as the ifdef, but no: TcpSocket uses it only for tracking network usage statistics, apparently?)