Closed Bug 846082 Opened 12 years ago Closed 12 years ago

Hang at shutdown after using mozGetUserMedia()

Categories

(Core :: WebRTC: Audio/Video, defect)

x86_64
Linux
defect
Not set
critical

Tracking

()

RESOLVED DUPLICATE of bug 845842
Tracking Status
firefox21 --- unaffected
firefox22 --- affected

People

(Reporter: jesup, Assigned: gps)

References

Details

(Keywords: hang, Whiteboard: [getUserMedia][blocking-gum-])

Attachments

(2 files)

hg bisect says the first bad patch has to be in the range 122579:b831500ca4be (122578 was good) to 122582:6c126d076b0d (bad) (which was a backout of 122579). The other two patches bisect shows were 122580:437c955ff06d (bug 796114 - Inline with type-checked arguments. r=h4writer), and a GPS patch to a bunch of metrics jsm stuff (Bug 841074 - Statically declare fields on FHR measurements; r=rnewman 122581:5054f997ef77)

STR: (Fedora 17 x64)

hg update -r 6c126d076b0d
build
start up
got to http://mozilla.github.com/webrtc-landing/gum_test.html
Click on Video
Tell it you allow capture
Click Stop
Click close-window
Amazingly, this hang on shutdown is due to bug 841074.   Backing it out removes the hang (verified on the first broken build, and on current inbound head).  When I use an all:5 logging, the last non-idle logging I see is the MediaStreamGraph finishing shutting down successfully.

Perhaps there's some oddball interaction with the metrics data in my profile?

CC-ing some people who might have ideas or be peripherally involved (MediaStreamGraph, GC/CC, general XPCOM shutdown).

(To clarify the initial report: Shutdown hangs for me 100% consistently on builds on or after 122581:5054f997ef77, IF (and only if, it appears) I started a getUserMedia stream (and stopped it).  See the STR above.
Assignee: general → gps
Severity: major → critical
Component: JavaScript Engine → WebRTC: Audio/Video
Depends on: 841074
QA Contact: jsmith
Whiteboard: [getUserMedia][blocking-gum-]
The hang was reported in bug 845842. The technical discussion about the underlying problem is there. A treatment of the symptoms (read: no more hang) landed in bug 845966. Unfortunately, it appears nobody performed an inbound to m-c uplift this morning, so I guess it didn't make today's Nightly. Pity.

Please let me know if the patch in bug 845966 does not fix the issue.
Status: NEW → RESOLVED
Closed: 12 years ago
Resolution: --- → DUPLICATE
Verified dup.

Thanks for solving it.  I was afraid it had something to do with MediaStreams, though I had no freaking idea how....  Still weird that creating (and destroying) a mediaStream caused it to hang 100% of the time on shutdown, but only if I did that (apparently).
(In reply to Randell Jesup [:jesup] from comment #4)
> Verified dup.
> 
> Thanks for solving it.  I was afraid it had something to do with
> MediaStreams, though I had no freaking idea how....  Still weird that
> creating (and destroying) a mediaStream caused it to hang 100% of the time
> on shutdown, but only if I did that (apparently).

To be clear, FHR got in a bad state on startup and this caused FHR to hang on shutdown since it was waiting for an event that would never finish.

Your use of MediaStreams is probably just a coincidence or was the tipping point for pushing the stack over the limit.
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: