Open Bug 888748 Opened 7 years ago Updated 3 years ago

crashinject.exe is unreliable; firefox.exe lives on and keeps waiting for it


(Testing :: General, defect, P3)

Windows 7


(Not tracked)


(Reporter: jruderman, Unassigned)


With some DOM fuzzer testcases, crashinject.exe doesn't successfully kill firefox.exe.

Win7 Resource Monitor says firefox.exe is "waiting for network".

I plan to work around this in my harness by deleting crashinject.exe before running  This will make fall back to a simpler mechanism to kill the browser (os.kill, taskkill, or TerminateProcess).

(fuzzer-win1 is running 64-bit Win7, and this testing was all done with Tinderbox debug builds)
Maybe should kill the process harder if it's still around a few seconds after it tries crashinject?
Yeah, probably. I'm actually trying to get rid of crashinject, see bug 885472. That approach has the same problem currently, in that the xpcshell hangs we're seeing on WinXP seem to be shutdown hangs, so Breakpad isn't available to trigger.

I think what I want to do here is just forcibly kill the process if it's still alive after we try to trigger Breakpad. We should probably do this on other platforms, too, by sending a SIGKILL shortly after we SIGABRT on Linux if the process is still alive.
I've changed my approach to that, I implemented a mozcrash.kill_and_get_minidump method that doesn't use crashinject, it simply calls MiniDumpWriteDump using ctypes:

I wired it up to the xpcshell harness in my test, you could probably easily wire it into if you wanted to try it out:
Priority: -- → P3
You need to log in before you can comment on or make changes to this bug.