Closed Bug 1697895 Opened 6 months ago Closed 3 months ago

Register the WER runtime exception module at runtime in child processes

Categories

(Toolkit :: Crash Reporting, task)

Unspecified
Windows
task

Tracking

()

RESOLVED FIXED
91 Branch
Tracking Status
firefox91 --- fixed

People

(Reporter: gsvelto, Assigned: gsvelto)

References

(Blocks 1 open bug)

Details

Attachments

(1 file)

This is like bug 1682514 but for all child processes. Child processes currently write out their crash annotations at exception time; if we reached WER however the exception handler will have already been bypassed so we need another way to extract annotations and write them to the .extra file. One possibility is to have the runtime exception module write a minimal .extra file like it does for main process crashes plus the process type. This won't be great but should be enough if push comes to shove.

I've got this pretty much done but there's a lot more surgery involved for implementing bug 1682518.

Assignee: nobody → gsvelto
Status: NEW → ASSIGNED

This patch sets up a few different things that will be used by the WER runtime
exception module when it needs to notify the main process of a child process
crash.

For every child process we allocate a structure in the main process called
WindowsErrorReportingData that contains three things:

  • The address of the function used to notify the main process that there's a
    pending minidump for a given child process
  • The PID of said child process
  • The name of the minidump that has been generated

The first field is filled up by the main process and will be read by the WER
process when running the runtime exception module, the second and third fields
on the other hand start empty and will be written into by the runtime exception
module after it has generated a minidump.

I know this sounds scary. It is. But bear with me please.

When we register the runtime exception module we can pass it a single
pointer-sized parameter but we need to pass it at least another pointer that
includes data coming from the child process itself (this one is called
InProcessWindowsErrorReportingData). This data currently includes only the
process type but will also include certain annotations in the future
(e.g. bug 1711418). So here's what we do: we store a pointer to the parent
data structure in the child process command-line (cringe) and we read it
from the runtime exception module by reading the crashed process command-line
arguments and parsing them (double-cringe).

Armed with this information the WER runtime exception module can populate
the info for the generated minidump and then push it into the main process
by calling CreateRemoteThread() (which creates a new thread in the main
process, triple-cringe at this point).

Pushed by gsvelto@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/d75aef90ac53
Register the WER runtime exception module in child processes r=KrisWright

I forgot to stub the new WerNotifyProc() function in the dummy exception handler that gets used when crash reporting is off... which is the default in ASAN builds.

Flags: needinfo?(gsvelto)
Pushed by gsvelto@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/a9be55acfd91
Register the WER runtime exception module in child processes r=KrisWright

Backed out for causing build bustages on nsEmbedFunctions.cpp.

Push with failures

Failure log

Backout link

Flags: needinfo?(gsvelto)

Ah, a parameter change to SetRemoteExceptionHandler()... I wonder why it only broke in no-opt builds, I thought only ASAN would be affected. Well, no matter, fix incoming.

Flags: needinfo?(gsvelto)
Pushed by gsvelto@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/3dc9c315f3b6
Register the WER runtime exception module in child processes r=KrisWright
Status: ASSIGNED → RESOLVED
Closed: 3 months ago
Resolution: --- → FIXED
Target Milestone: --- → 91 Branch
You need to log in before you can comment on or make changes to this bug.