We would want --run-by-dir to be more reliable and we can see that there is a crash in windows xp debug : https://treeherder.mozilla.org/#/jobs?repo=try&revision=351ba2066462&filter-resultStatus=testfailed&filter-resultStatus=busted&filter-resultStatus=exception&filter-resultStatus=retry&filter-resultStatus=usercancel&filter-resultStatus=running&filter-resultStatus=pending&exclusion_profile=false&filter-searchStr=win%20xp%20debug%20mochitest-2 On further investigation, it was found out that test_ipc.html was the cause of it. Getting it skipped from the manifest has led to a greener try : https://treeherder.mozilla.org/#/jobs?repo=try&revision=1bc4ffde2862&filter-searchStr=windows%20xp%20debug

:poiru, can you take a look at this and see why we crash on windows xp when only running the media directory (instead of many directories in a larger chunk)? for reference this test has a lot of related bug: https://bugzilla.mozilla.org/buglist.cgi?quicksearch=test_ipc.html&list_id=12384066 Most likely this is caused by: 1) we are depending on something to be initialized in the browser asynchronously and it isn't ready 2) we shutdown faster and don't cleanup fully 3) a previous test is setting a pref or a browser state which we depend on

(In reply to Joel Maher (:jmaher) from comment #1) > :poiru, can you take a look at this and see why we crash on windows xp when > only running the media directory (instead of many directories in a larger > chunk)? I presume I was ni?'d because `hg log` shows me as the first author? I merely moved test_ipc.html from a directory to another, so redirecting ni? to schien. (FWIW, you can use `git/hg log --follow` to track a file beyond renames.)

Gecko hit an assertion during shutdown procedure after test_ipc.html passed (I saw "OK" in log). @jesup might have better insight than me. 23:38:22 INFO - Assertion failure: aHandling == DispatchFailureHandling::IgnoreFailure, at c:/builds/moz2_slave/try-w32-d-00000000000000000000/build/src/dom/base/nsContentUtils.cpp:5177 23:38:35 INFO - #01: mozilla::MediaStreamGraphImpl::EnsureRunInStableState() [dom/media/MediaStreamGraph.cpp:1849] 23:38:35 INFO - #02: mozilla::MediaStreamGraphImpl::AppendMessage(mozilla::ControlMessage *) [dom/media/MediaStreamGraph.cpp:1903] 23:38:35 INFO - #03: mozilla::MediaStream::RemoveListener(mozilla::MediaStreamListener *) [dom/media/MediaStreamGraph.cpp:2322] 23:38:35 INFO - #04: mozilla::dom::HTMLMediaElement::EndSrcMediaStreamPlayback() [dom/html/HTMLMediaElement.cpp:3149] 23:38:35 INFO - #05: nsCycleCollector::CollectWhite() [xpcom/base/nsCycleCollector.cpp:3276] 23:38:35 INFO - #06: nsCycleCollector::Collect(ccType,js::SliceBudget &,nsICycleCollectorListener *,bool) [xpcom/base/nsCycleCollector.cpp:3631] 23:38:35 INFO - #07: nsCycleCollector::ShutdownCollect() [xpcom/base/nsCycleCollector.cpp:3549] 23:38:35 INFO - #08: nsCycleCollector_shutdown() [xpcom/base/nsCycleCollector.cpp:4165] 23:38:35 INFO - #09: mozilla::ShutdownXPCOM(nsIServiceManager *) [xpcom/build/XPCOMInit.cpp:944] 23:38:35 INFO - #10: XRE_TermEmbedding [toolkit/xre/nsEmbedFunctions.cpp:210] 23:38:35 INFO - #11: content_process_main(int,char * * const) [ipc/contentproc/plugin-container.cpp:237] 23:38:35 INFO - #12: wmain [toolkit/xre/nsWindowsWMain.cpp:138] 23:38:35 INFO - #13: __tmainCRTStartup [f:/dd/vctools/crt/crtw32/startup/crt0.c:255] 23:38:35 INFO - #14: kernel32 + 0x17067

I've filed a bug on this already; I hit it once while testing some e10s stuff that uses MSG. Clearly some type of shutdown race condition in MSG under e10s. Paul, this may provide a useful way to reproduce this crash