Closed Bug 846082 Opened 11 years ago Closed 11 years ago
Hang at shutdown after using moz
Get User Media()
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.
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: 11 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.