888748 - crashinject.exe is unreliable; firefox.exe lives on and automation.py keeps waiting for it

Status: NEW

(Testing :: General, defect, P3)

Description

[Jesse Ruderman]

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 automation.py.  This will make automation.py fall back to a simpler mechanism to kill the browser (os.kill, taskkill, or TerminateProcess).

http://hg.mozilla.org/mozilla-central/annotate/614e1793e958/build/automation.py.in#l917

(fuzzer-win1 is running 64-bit Win7, and this testing was all done with Tinderbox debug builds)

Comment 1

[Jesse Ruderman]

Maybe automation.py should kill the process harder if it's still around a few seconds after it tries crashinject?

Comment 2

[(not currently active) Ted Mielczarek]

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.

Comment 3

[(not currently active) Ted Mielczarek]

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:
https://hg.mozilla.org/try/rev/978dc9973bd5

I wired it up to the xpcshell harness in my test, you could probably easily wire it into automation.py if you wanted to try it out:
https://hg.mozilla.org/try/rev/7a9a9dc68bd7