815231 - Crash when reloading testcase [@ CMIOUnits@0x63e4b ]

Status: RESOLVED WORKSFORME

(Core :: WebRTC, defect, P1)

Description

[Henrik Skupin [:whimboo][⌚️UTC+1]]

Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:20.0) Gecko/20.0 Firefox/20.0 ID:20121125030729 crashes when attachment 669440 [details] gets opened and reloaded a couple of times.
 
Crash report: bp-1c2c040f-1bcd-467e-bb30-e269c2121126
 
0	@0x10b6ecb80 	
1 	CMIOUnits 	CMIOUnits@0x63e4b 	
2 	CMIOUnits 	CMIOUnits@0x63d95 	
3 	VDC  		VDC@0x16a73

Comment 1

[Randell Jesup [:jesup] (needinfo me)]

That attachment BTW is from bug 799419

Comment 2

[Henrik Skupin [:whimboo][⌚️UTC+1]]

A quick check with a debug nightly build didn't show up this problem. So it could be only happening for optimized builds.

Comment 3

[Randell Jesup [:jesup] (needinfo me)]

Tried a debug local inbound build (linux), no crashes.  (Did you have the permissions.disabled set to true, or was it asking you each time?)  Building an opt build off m-c

Comment 4

[Henrik Skupin [:whimboo][⌚️UTC+1]]

Yes, permissions have been disabled.

Comment 5

[Randell Jesup [:jesup] (needinfo me)]

Reloaded about 100 times on Linux opt build (non-PGO).  No failures.  (Camera didn't always end up on; there were no debugs to tell me what was happening, but no failures.)

Comment 6

[Henrik Skupin [:whimboo][⌚️UTC+1]]

This should be an OS X specific crash. At least given the CMIOUnits entry in the stack, which is part of the CoreMediaIOServices.framework.

Comment 7

[Randell Jesup [:jesup] (needinfo me)]

I have a mac opt build running a loop of the testcase (reload 2 seconds after load) now.  I'll let it run, but I'm probably over 100 iterations so far.  This is a local opt build from inbound.  (Are mac builds PGO'd?)

Comment 8

[Randell Jesup [:jesup] (needinfo me)]

Ok, mac locked up (perhaps trying to hibernate while playing with the camera).

After re-trying, I got it to fail eventually in an opt build.  I'll try again with a debug build.

You get a lot of errors like this: in many spurts, which may also be a symptom of the same bug that causes the crash.  I got 15000 lines of those over 1/2 hour before it crashed, typically 10-20 (sometimes more) from a specific iteration of the code, maybe 5 seconds apart.  It also might be related to the camera working for one iteration (light on), then not  working for the next (light off), with ~2 seconds per iteration plus overhead, which roughly matches the pacing of the errors.

Tue Nov 27 13:05:43 2012 CMIO_Graph.cpp:8709:HandleRenderNotify CMIOGraph::HandleRenderNotify() called but graph is not initialized!

Comment 9

[Randell Jesup [:jesup] (needinfo me)]

Attachment: Mac crash report from opt build

Comment 10

[Randell Jesup [:jesup] (needinfo me)]

Attachment: Callstack from debug build (slightly different crash)

So I got it to crash in a related way (again CMIOUnits/CoreMedia) on Debug.  I'll also upload the modified testcase.  This time thread 0 crashed.

Comment 11

[Randell Jesup [:jesup] (needinfo me)]

Attachment: Updated testcase, loops until crash. Turn on media.navigator.permission.enabled (to true)

Comment 12

[Randell Jesup [:jesup] (needinfo me)]

Note: this took an hour+ of constant reloads to trigger the problem.  Probably should be retested given how long since it was reproduced, and the number of changes we've made - especially regarding cleanup on reload.

Comment 13

[Randell Jesup [:jesup] (needinfo me)]

If it's easy to hit on retest we can make it blocking+ again; given it's in the OS drivers and how hard, blocking-

Comment 14

[Jason Smith [:jsmith]]

(In reply to Randell Jesup [:jesup] from comment #13)
> If it's easy to hit on retest we can make it blocking+ again; given it's in
> the OS drivers and how hard, blocking-

I was actually going to say also not blocking on this is okay given that the perm prompt existing will slow down the flow to this crash. So the probability of a user hitting this crash probably isn't likely.

Comment 15

[Randell Jesup [:jesup] (needinfo me)]

Believed fixed by bug 837539