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.

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.