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.

#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)

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.

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 on attachment 8376497 [details] [diff] [review] Fix string comparison in PeerConnectionImpl.cpp Review of attachment 8376497 [details] [diff] [review]: ----------------------------------------------------------------- lgtm

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

(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?

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.

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).

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.

(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?

(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.

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