Closed
Bug 812636
Opened 13 years ago
Closed 13 years ago
crash in vcmTxStartICE
Categories
(Core :: WebRTC: Signaling, defect, P1)
Tracking
()
RESOLVED
FIXED
mozilla20
People
(Reporter: scoobidiver, Assigned: jesup)
Details
(Keywords: crash, Whiteboard: [WebRTC] [blocking-webrtc+] [qa-])
Crash Data
Attachments
(1 file)
1.96 KB,
patch
|
ehugg
:
review+
|
Details | Diff | Splinter Review |
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: 8.15.10.2418
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
Assignee | ||
Comment 1•13 years ago
|
||
May well be caused by bug 799419, now fixed
Updated•13 years ago
|
Flags: in-testsuite-
Is this still open an Issue .. Referring to jesup's comment above on a dependent bug being fixing this issue ...
Comment 3•13 years ago
|
||
Needs URLs - I need to know what test URL caused this crash if that's available.
Keywords: needURLs
Assignee | ||
Comment 4•13 years ago
|
||
Assignee | ||
Updated•13 years ago
|
Assignee: nobody → rjesup
Assignee | ||
Comment 5•13 years ago
|
||
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 6•13 years ago
|
||
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+
Assignee | ||
Comment 7•13 years ago
|
||
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 ..
Assignee | ||
Comment 9•13 years ago
|
||
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).
Comment 10•13 years ago
|
||
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.
Comment 11•13 years ago
|
||
(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?
Comment 12•13 years ago
|
||
(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.
Assignee | ||
Comment 13•13 years ago
|
||
I already landed the patch (though it hasn't uplifted yet I think). It's clearly needed for safety in any case.
Comment 14•13 years ago
|
||
(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.
Comment 15•13 years ago
|
||
Status: NEW → RESOLVED
Closed: 13 years ago
Resolution: --- → FIXED
Updated•13 years ago
|
Whiteboard: [WebRTC] [blocking-webrtc+] → [WebRTC] [blocking-webrtc+] [qa-]
You need to log in
before you can comment on or make changes to this bug.
Description
•