1758673 - Enable the stack overflow crash test on Windows

Status: ASSIGNED

(Toolkit :: Crash Reporting, task)

Description

[Gabriele Svelto [:gsvelto] (PTO)]

While investigating bug 1752696 I figured out that the same system could be used to use WER to intercept crashes in tests too. For now I'd like to restrict this to the test_crash_stack_overflow.js test, but eventually we could use it in all tests.

Unfortunately writing the appropriate registry key is insufficient because of a bug in my original WER implementation: we write out the minidump and extra file in the pending directory directly, while the correct procedure would be to write it out in the minidump directory and then let Firefox or the crash reporter client to move it to the pending directory. That needs to be addressed too if we want the test to function properly.

Comment 1

[Gabriele Svelto [:gsvelto] (PTO)]

Attachment: Bug 1758673 - Enable the stack overflow crash test on Windows r=KrisWright

This patch is complicated. The limitation we're working against is that we can
pass only a pointer per process to the WER runtime exception module and that's
the only that it has when processing a crash in addition to a handle to the
crashed process.

We put in every process an instance of the InProcessWindowsReportingData
structure. This structure contains the data that will allow the WER runtime
exception module to gather information about the crashed process. Additionally
this structure contains two pointers, both of which always point into the
main process' memory: the first one is a pointer to the
WindowsErrorReportingData structure. This structure contains global data that
is needed to write out the minidump (such as the path where it needs to be
stored) as well as the address of the procedure used to inform the main process
of a child process crash. The second pointer is only populated in child
processes and it points to a WindowsErrorReportingOutput structure. There is
one such structure per child process, and when one crashes we fill it up with
information that will be needed in the main process to retrieve the minidump.

So far so good. The WER crash reporting flow become thus the following.

For main process crashes:

1. Read the InProcessWindowsReportingData structure from the main process (which crashed)
2. Use the information read in 1. to read the WindowsErrorReportingData from the main process
3. Use the information read in 2 to write the minidump and launch the crash reporter client

For child process crashes:

1. Read the InProcessWindowsReportingData structure from the child process (which crashed)
2. Use the information read in 1. to read the WindowsErrorReportingData from the main process
3. Use the information read in 2 to write the minidump
4. Write the minidump information in the WindowsErrorReportingOutput structure in the main process. We also read this in 2
5. Inform the main process that we generated a minidump, this also relies on the information we read in 2

For this magic dance to work this patch includes another change: we pass both
the pointer to the WindowsErrorReportingData structure and the one to the
WindowsErrorReportingOutput structure to each child process, on the
command-line. When the child process starts it pops both addresses and stores
them in its InProcessWindowsReportingData structure for use later.

Comment 2

[BugBot [:suhaib / :marco/ :calixte]]

There's a r+ patch which didn't land and no activity in this bug for 2 weeks.
:gsvelto, could you have a look please?
If you still have some work to do, you can add an action "Plan Changes" in Phabricator.
For more information, please visit auto_nag documentation.

Comment 3

[Gabriele Svelto [:gsvelto] (PTO)]

I need to further test this before I land it.