crash in vcmTxStartICE

RESOLVED FIXED in mozilla20

Status

()

Core
WebRTC: Signaling
P1
critical
RESOLVED FIXED
6 years ago
6 years ago

People

(Reporter: Scoobidiver (away), Assigned: jesup)

Tracking

({crash})

19 Branch
mozilla20
x86
Windows 7
crash
Points:
---
Bug Flags:
in-testsuite -

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [WebRTC] [blocking-webrtc+] [qa-], crash signature)

Attachments

(1 attachment)

(Reporter)

Description

6 years ago
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

6 years ago
May well be caused by bug 799419, now fixed
Keywords: qawanted
Priority: -- → P1
Whiteboard: [WebRTC] [blocking-webrtc+]

Updated

6 years ago
Flags: in-testsuite-

Comment 2

6 years ago
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.
Keywords: needURLs
(Assignee)

Comment 4

6 years ago
Created attachment 686017 [details] [diff] [review]
additional checks for failure for a Conduit be created
(Assignee)

Updated

6 years ago
Assignee: nobody → rjesup
(Assignee)

Comment 5

6 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

6 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

6 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

Comment 8

6 years ago
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

6 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).
(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?
Keywords: needURLs, qawanted
(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

6 years ago
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.
https://hg.mozilla.org/mozilla-central/rev/57b33c0ff8bd
Status: NEW → RESOLVED
Last Resolved: 6 years ago
Resolution: --- → FIXED

Updated

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