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

NEW
Unassigned

Status

defect
P3
normal
6 years ago
2 years ago

People

(Reporter: jruderman, Unassigned)

Tracking

Trunk
x86_64
Windows 7
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

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)
Maybe automation.py 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:
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
Priority: -- → P3
You need to log in before you can comment on or make changes to this bug.