I've determined this to be the cause of the backout in Bug 907352 comment 36, and am filing this as evidence that this problem existed prior. The non-fake audio code appears not to like running on the linux builders, causing intermittent crashes on shutdown. Here's a try showing this using the attached STR1 patch https://tbpl.mozilla.org/?tree=Try&rev=3045b34dd2e8 : > 10:57:57 INFO - -1220131072[b721a240]: [main|CallControlManager] CallControlManagerImpl.cpp:48: ~CallControlManagerImpl() > 10:57:57 INFO - -1220131072[b721a240]: [main|CallControlManager] CallControlManagerImpl.cpp:54: destroy() > 10:57:57 INFO - -1220131072[b721a240]: [main|CallControlManager] CallControlManagerImpl.cpp:227: disconnect() > 10:57:57 INFO - pure virtual method called > 10:57:57 INFO - terminate called without an active exception > 10:57:58 INFO - TEST-INFO | Main app process: killed by out-of-range signal, number 122 > 10:57:58 WARNING - TEST-UNEXPECTED-FAIL | Shutdown | application terminated with exit code -6 All the patch does is enable the same gUM test-run for audio that we currently use for video, that is: test a gUM success-path using fake:true, but test the a gUM failure path without fake:true. Audio does not like the latter. The workaround is simple enough: always use fake:true on builders: https://tbpl.mozilla.org/?tree=Try&rev=19ff8fd7f2a3 (all green) However, there may be real problem to hunt down here, hence this bug.

I've already dug into this locally; it appears to be the webrtc media "Process" threads not shutting down, and causing a pure virtual hit trying to convert the current time into ms. Something seems to have made them start doing this recently (I've seen this failure before, but it was a while ago. I see this on pc_test calls.

I believe this is fixed by bug 1008619 (which requires also bug 988877)