Running crashtest on m-c rev 3051d82cb64f deadlocks, as far as I can tell. The window ends up completely blank, no CPU is being used. Breaking in gdb indicates that we're sleeping inside the java plug-in. The last test that completely finishes loading in this case is layout/base/crashtests/90205-1.html. The test after that is 99776-1.html, and basically looks like this: <applet style="position:absolute;left:7;top:73;"></applet> This causes the MRJ plug-in to be instantiated; I have no idea why it hangs. Just loading the test file directly does not hang; running firefox -reftest layout/base/crashtests/crashtests.list hangs reliably for me in a Mac debug build. This is keeping me from doing any sort of reasonable testing of my local changes (e.g. making sure they pass crashtest), hence the blocker severity. Note that the tryserver run of crashtest is nearly useless for my purposes, since it doesn't check for assertions triggered by the changes being tested.

I think you need to clobber to get rid of a vestigial JEP plugin. We saw this on Tinderbox and clobbering fixed it.

Sounds like a build system bug, no? Or something?

Well... gmake has rules for noticing when things need to be rebuilt, but not when things need to be removed. It's possible that we should just clobber dist/Minefield.app every time, though, since things tend to linger longer there than anywhere else.

Clobbering did help. Maybe the right solution is to have a treewide clobber file (similar to the way tinderbox works, but as part of our source tree) that code changes that require clobber would modify? That would make little things like bisect across such code changes actually work...

Seems like clobbering dist/bin and dist/$(APPNAME).app would be a better solution. I think we have existing bugs on that...