Closed Bug 812636 Opened 10 years ago Closed 10 years ago
crash in vcm
Tx Start ICE
It could be a dupe of bug 811758 according to the stack trace. Signature vcmTxStartICE More Reports Search UUID 8c8d506e-1cf3-482b-8fa1-a45fc2121116 Date Processed 2012-11-16 20:14:27 Uptime 814 Last Crash 20.8 minutes before submission Install Age 3.5 hours since version was first installed. Install Time 2012-11-16 16:44:38 Product Firefox Version 19.0a1 Build ID 20121116030725 Release Channel nightly OS Windows NT OS Version 6.1.7601 Service Pack 1 Build Architecture x86 Build Architecture Info GenuineIntel family 6 model 37 stepping 2 Crash Reason EXCEPTION_ACCESS_VIOLATION_READ Crash Address 0x0 App Notes AdapterVendorID: 0x8086, AdapterDeviceID: 0x0046, AdapterSubsysID: 040a1028, AdapterDriverVersion: 18.104.22.1688 D2D? D2D+ DWrite? DWrite+ D3D10 Layers? D3D10 Layers+ EMCheckCompatibility True Adapter Vendor ID 0x8086 Adapter Device ID 0x0046 Total Virtual Memory 4294836224 Available Virtual Memory 3424706560 System Memory Use Percentage 52 Available Page File 12022611968 Available Physical Memory 4085813248 Frame Module Signature Source 0 xul.dll vcmTxStartICE media/webrtc/signaling/src/media/VcmSIPCCBinding.cpp:1784 1 xul.dll lsm_tx_start media/webrtc/signaling/src/sipcc/core/gsm/lsm.c:1272 2 xul.dll lsm_update_media media/webrtc/signaling/src/sipcc/core/gsm/lsm.c:3873 3 xul.dll lsm_call_state_media media/webrtc/signaling/src/sipcc/core/gsm/lsm.c:3916 4 xul.dll lsm_connected media/webrtc/signaling/src/sipcc/core/gsm/lsm.c:4009 5 xul.dll cc_call_state media/webrtc/signaling/src/sipcc/core/gsm/lsm.c:5146 6 xul.dll fsmdef_ev_setlocaldesc media/webrtc/signaling/src/sipcc/core/gsm/fsmdef.c:3168 7 xul.dll sm_process_event media/webrtc/signaling/src/sipcc/core/gsm/sm.c:48 8 xul.dll fim_process_event media/webrtc/signaling/src/sipcc/core/gsm/fim.c:636 9 xul.dll gsm_process_msg media/webrtc/signaling/src/sipcc/core/gsm/gsm.c:132 10 xul.dll GSMTask media/webrtc/signaling/src/sipcc/core/gsm/gsm.c:324 11 xul.dll cprStartThread media/webrtc/signaling/src/sipcc/cpr/win32/cpr_win_threads.c:38 12 msvcr100.dll _callthreadstartex f:\dd\vctools\crt_bld\self_x86\crt\src\threadex.c:314 13 msvcr100.dll _threadstartex f:\dd\vctools\crt_bld\self_x86\crt\src\threadex.c:292 14 kernel32.dll BaseThreadInitThunk 15 ntdll.dll __RtlUserThreadStart 16 ntdll.dll _RtlUserThreadStart More reports at: https://crash-stats.mozilla.com/report/list?signature=vcmTxStartICE
May well be caused by bug 799419, now fixed
Priority: -- → P1
Whiteboard: [WebRTC] [blocking-webrtc+]
Is this still open an Issue .. Referring to jesup's comment above on a dependent bug being fixing this issue ...
Needs URLs - I need to know what test URL caused this crash if that's available.
Comment on attachment 686017 [details] [diff] [review] additional checks for failure for a Conduit be created r? to ehugg as ekr is busy Note other instances of blahConduit::Create() check for null returns; two were missing.
Attachment #686017 - Flags: review?(ethanhugg)
Comment on attachment 686017 [details] [diff] [review] additional checks for failure for a Conduit be created Review of attachment 686017 [details] [diff] [review]: ----------------------------------------------------------------- Good patch to have, but unclear to me that we aren't going to have a different symptom now if we can't create the conduits.
Attachment #686017 - Flags: review?(ethanhugg) → review+
https://hg.mozilla.org/integration/mozilla-inbound/rev/57b33c0ff8bd Perhaps, but a bunch of other things return that same error. As to *why* the conduit can't be created - I don't know and don't have a testcase (big lock?) but it doesn't matter to this.
Target Milestone: --- → mozilla20
I am bit concerned the reason for Conduit creation failure which happens when its Init Failed . Is there a way to know the logs from the conduit code ..
I agree, but without a testcase we'll need to wait to see if it shows up again. You could look through Init to see, or add MOZ_ASSERTs. It's very possible this is caused by the Big Lock problem (tearing it down while being created; that sort of thing).
Locations we have are: http://masweb.ics.es.osaka-u.ac.jp/~k-nkgwj/webrtc/test/multihost-datachannel/ https://github.com/anantn/socialapi-demo http://mozilla.github.com/webrtc-landing/data_test.html I have tried those but can't get the crash to reproduce.
(In reply to Henrik Skupin (:whimboo) from comment #10) > Locations we have are: > > http://masweb.ics.es.osaka-u.ac.jp/~k-nkgwj/webrtc/test/multihost- > datachannel/ > https://github.com/anantn/socialapi-demo > http://mozilla.github.com/webrtc-landing/data_test.html > > I have tried those but can't get the crash to reproduce. Sounds good. Sounds like we're okay then, although it could be worth to land the attached patch for safety. Randell - What do you think?
(In reply to Jason Smith [:jsmith] from comment #11) > Sounds good. Sounds like we're okay then, although it could be worth to land > the attached patch for safety. Well, this was without the patch attached. So I can't say anything about it. I just tested those pages. So far I don't have a reproducible testcase.
I already landed the patch (though it hasn't uplifted yet I think). It's clearly needed for safety in any case.
(In reply to Randell Jesup [:jesup] from comment #13) > I already landed the patch (though it hasn't uplifted yet I think). It's > clearly needed for safety in any case. That's correct. It's still in inbound and todays nightly doesn't have it included, which I was using here.
Status: NEW → RESOLVED
Closed: 10 years ago
Resolution: --- → FIXED
Whiteboard: [WebRTC] [blocking-webrtc+] → [WebRTC] [blocking-webrtc+] [qa-]
You need to log in before you can comment on or make changes to this bug.