972623 - Crash while trying to establish a video P2P call (FxOS --> Desktop Firefox Nightly) on the FxOS device

Status: RESOLVED FIXED

(Core :: WebRTC: Audio/Video, defect)

Description

[Jason Smith [:jsmith]]

Build:

* Version: 1.4
* Device: Flame & ZTE Open C
* Build ID: 20140212131705

STR

1. Go to apprtc.appspot.com on ZTE Open C
2. Accept permissions to your camera & mic
3. On Desktop Firefox Nightly, go to the apprtc URL given on the ZTE Open C device
4. Accept permissions to your camera & mic

Expected

The connection should establish, allowing you to see the other peer & communicate with them via audio.

Actual

The ZTE Open C device experiences a crash when establishing a connection with Desktop Firefox Nightly.

Additional Notes

This only reproduces on JB-based devices. I can't reproduce this on a Buri & Leo device running 1.4. I also don't have crash symbols for either of these devices, so I don't have a stack.

Comment 1

[Michael Wu [:mwu]]

#0  0xb56e5d96 in nsArray::Release (this=0xb1bfd75c)
    at ../../../gecko/xpcom/ds/nsArray.cpp:41
#1  0xb5d4e894 in mozilla::dom::UDPSocketChild::Release (this=0xb1bfd740)
    at ../../../../gecko/dom/network/src/UDPSocketChild.cpp:41
#2  0xb56cb76e in nsCOMPtr_base::~nsCOMPtr_base (this=this@entry=0xb1b35f88, 
    __in_chrg=<optimized out>) at ../../../dist/include/nsCOMPtr.h:433
#3  0xb598eff6 in ~nsCOMPtr (this=0xb1b35f88, __in_chrg=<optimized out>)
    at ../../../dist/include/nsCOMPtr.h:472
#4  mozilla::NrSocketIpc::~NrSocketIpc (this=0xb1b35ec0, 
    __in_chrg=<optimized out>)
    at ../../../../gecko/media/mtransport/nr_socket_prsock.h:199
#5  0xb598f01c in mozilla::NrSocketIpc::~NrSocketIpc (this=0xb1b35ec0, 
    __in_chrg=<optimized out>)
    at ../../../../gecko/media/mtransport/nr_socket_prsock.h:199
#6  0xb598ecea in nr_socket_local_create (addr=addr@entry=0xb3afcbf0, 
    sockp=sockp@entry=0xb3afcbe4)
    at ../../../../gecko/media/mtransport/nr_socket_prsock.cpp:1114
#7  0xb614f01c in nr_ice_component_initialize_tcp (ctx=ctx@entry=0xb3bf51ac, 
    component=component@entry=0xb2ba1d6c, addrs=addrs@entry=0xb377cc1c, 
    addr_ct=addr_ct@entry=1, lufrag=lufrag@entry=0xb37fc50c "6773bc65", 
    pwd=pwd@entry=0xb3afcd90)
    at ../../../../../../gecko/media/mtransport/third_party/nICEr/src/ice/ice_component.c:322
#8  0xb614f322 in nr_ice_component_initialize (ctx=ctx@entry=0xb3bf51ac, 
    component=component@entry=0xb2ba1d6c)
    at ../../../../../../gecko/media/mtransport/third_party/nICEr/src/ice/ice_component.c:406
#9  0xb615094e in nr_ice_media_stream_initialize (ctx=ctx@entry=0xb3bf51ac, 
    stream=stream@entry=0xb2ba1d0c)
    at ../../../../../../gecko/media/mtransport/third_party/nICEr/src/ice/ice_media_stream.c:133
#10 0xb6150578 in nr_ice_initialize (ctx=0xb3bf51ac, done_cb=<optimized out>, 
    cb_arg=<optimized out>)
    at ../../../../../../gecko/media/mtransport/third_party/nICEr/src/ice/ice_ctx.c:560
#11 0xb599078c in mozilla::NrIceCtx::StartGathering (this=0xb1b2e1d0)
    at ../../../../gecko/media/mtransport/nricectx.cpp:588
#12 0xb58109ce in mozilla::runnable_args_m_0<nsRefPtr<mozilla::DataChannelConnection>, void (mozilla::DataChannelConnection::*)()>::Run (
    this=<optimized out>)
    at ../../../dist/include/mtransport/runnable_utils_generated.h:49
#13 0xb56fe17a in ProcessNextEvent (result=0xb3affddf, 
    mayWait=<optimized out>, this=0xb4802780)
    at ../../../gecko/xpcom/threads/nsThread.cpp:643
#14 nsThread::ProcessNextEvent (this=0xb4802780, mayWait=<optimized out>, 
    result=0xb3affddf) at ../../../gecko/xpcom/threads/nsThread.cpp:567
#15 0xb56d1702 in NS_ProcessNextEvent (thread=<optimized out>, 
    thread@entry=0xb4802780, mayWait=mayWait@entry=true)
    at ../../../gecko/xpcom/glue/nsThreadUtils.cpp:263
#16 0xb572153a in nsSocketTransportService::Run (this=0xb3ddac80)
    at ../../../../gecko/netwerk/base/src/nsSocketTransportService2.cpp:741
#17 0xb56fe17a in ProcessNextEvent (result=0xb3affe57, 
    mayWait=<optimized out>, this=0xb4802780)
    at ../../../gecko/xpcom/threads/nsThread.cpp:643
#18 nsThread::ProcessNextEvent (this=0xb4802780, mayWait=<optimized out>, 
    result=0xb3affe57) at ../../../gecko/xpcom/threads/nsThread.cpp:567
#19 0xb56d1702 in NS_ProcessNextEvent (thread=<optimized out>, 
    mayWait=mayWait@entry=false)
    at ../../../gecko/xpcom/glue/nsThreadUtils.cpp:263
#20 0xb582ae40 in mozilla::ipc::MessagePumpForNonMainThreads::Run (
    this=0xb48ea670, aDelegate=0xb48d11a0)
    at ../../../gecko/ipc/glue/MessagePump.cpp:303
#21 0xb5821556 in MessageLoop::RunInternal (this=this@entry=0xb48d11a0)
    at ../../../gecko/ipc/chromium/src/base/message_loop.cc:226
#22 0xb5821608 in RunHandler (this=0xb48d11a0)
    at ../../../gecko/ipc/chromium/src/base/message_loop.cc:219
#23 MessageLoop::Run (this=this@entry=0xb48d11a0)

Comment 2

[Eric Rescorla (:ekr)]

Oh, I see the problem here. We shouldn't be trying to do TURN TCP
on FirefoxOS.

This should be disabled by the following code:

http://dxr.mozilla.org/mozilla-central/source/media/webrtc/signaling/src/peerconnection/PeerConnectionImpl.cpp#662

Can we verify that MOZ_WIDGET_GONK is being defined for this file.

Comment 3

[Eric Rescorla (:ekr)]

OK, here is the problem. See:

#ifdef MOZ_WIDGET_GONK
      if (transport.get() == kNrIceTransportTcp)
          continue;
#endif

kNrIceTransportTcp used to be a std::string and now
it's a char *, so this comparison fails, even if the
strings are the same.

transport is an nsAutoCString. Can we just compare it to
a char *? Or do we need strcmp()

Comment 4

[Michael Wu [:mwu]]

Attachment: Fix string comparison in PeerConnectionImpl.cpp

Comment 5

[Eric Rescorla (:ekr)]

Comment on attachment 8376497 [details] [diff] [review]
Fix string comparison in PeerConnectionImpl.cpp

Review of attachment 8376497 [details] [diff] [review]:
-----------------------------------------------------------------

lgtm

Comment 6

[Michael Wu [:mwu]]

https://hg.mozilla.org/integration/b2g-inbound/rev/d9c3937698f1

Comment 7

[Sotaro Ikeda [:sotaro]]

After applying attachment 8376497 [details] [diff] [review], the b2g process crashes at GrallocTextureSourceOGL::BindTexture(). It is happened by mCompositableBackendData is nullptr.

Comment 8

[Jason Smith [:jsmith]]

(In reply to Sotaro Ikeda [:sotaro] from comment #7)
> After applying attachment 8376497 [details] [diff] [review], the b2g process
> crashes at GrallocTextureSourceOGL::BindTexture(). It is happened by
> mCompositableBackendData is nullptr.

Ah - that's what mwu mentioned in IRC. Can we get a followup bug filed for the gfx crash here?

Comment 9

[Sotaro Ikeda [:sotaro]]

Attachment: patch - Call SetCompositableBackendSpecificData() in ImageHost::Composite()

Comment 10

[Sotaro Ikeda [:sotaro]]

By applying attachment 8376643 [details] [diff] [review], the b2g process crash in nexus-4 is fixed. One TextureHost was used by 2 ImageHosts. After One ImageHost removed TextureHost, other ImageLayer start to use the TextureHost to render. Current gecko does not handle correctly it.

Comment 11

[Jason Smith [:jsmith]]

I'm marking leave open here to indicate that we need the patch Sotaro is working on to fix the bug here as well (the first patch on inbound is only resolving the first crash hit).

Comment 12

[Sotaro Ikeda [:sotaro]]

By applying attachment 8376497 [details] [diff] [review] and attachment 8376643 [details] [diff] [review], WebRTC works. But when nexus-4 connects the webrtc session long time, nexus-4's all UIs was freezed. The GLContext::fEGLImageTargetTexture2D() seems to get stuck.

Comment 13

[Jason Smith [:jsmith]]

(In reply to Sotaro Ikeda [:sotaro] from comment #12)
> By applying attachment 8376497 [details] [diff] [review] and attachment
> 8376643 [details] [diff] [review], WebRTC works. But when nexus-4 connects
> the webrtc session long time, nexus-4's all UIs was freezed. The
> GLContext::fEGLImageTargetTexture2D() seems to get stuck.

Was that a bz conflict or would you just rather open a new bug here?

Comment 14

[Sotaro Ikeda [:sotaro]]

(In reply to Jason Smith [:jsmith] from comment #13)
> (In reply to Sotaro Ikeda [:sotaro] from comment #12)
> > By applying attachment 8376497 [details] [diff] [review] and attachment
> > 8376643 [details] [diff] [review], WebRTC works. But when nexus-4 connects
> > the webrtc session long time, nexus-4's all UIs was freezed. The
> > GLContext::fEGLImageTargetTexture2D() seems to get stuck.
> 
> Was that a bz conflict or would you just rather open a new bug here?

Created Bug 973147 to handle nexus-4 freeze.

Comment 15

[Jason Smith [:jsmith]]

Looks like we're still fixing the crash in this bug though, so I'll leave open here still

Comment 16

[Phil Ringnalda (:philor)]

https://hg.mozilla.org/mozilla-central/rev/d9c3937698f1

Comment 17

[Sotaro Ikeda [:sotaro]]

https://hg.mozilla.org/integration/b2g-inbound/rev/5babbad317ea

Comment 18

[Phil Ringnalda (:philor)]

https://hg.mozilla.org/mozilla-central/rev/5babbad317ea