зеркало из https://github.com/mozilla/gecko-dev.git
958361a3fb
On Windows content process minidump generation goes through the following steps: * The child process exception handler invokes the `filter` callback. This is the `ChildFPEFilter()` function in nsExceptionHandler.cpp. * If this callback returns true then the child process sends a request to the crash generation server living in the main process and then waits. * The main process generates a minidump in response to this message. * Once the minidump has been generated the crash generation server calls the `dump_callback` callback with the minidump filename. This is the `OnChildProcessDumpRequested()` function in nsExceptionHandler.cpp. * Once this callback returns the main process signals the child process that it has finished generating the dump. * The child process resumes execution in the exception handler and then terminates. During this process we send crash annotations via a pipe from the child process to the main process. The function responsible for this is `PrepareChildExceptionTimeAnnotations()` in nsExceptionHandler.cpp and it's called within `ChildFPEFilter()`. Because pipe writes are blocking if we send enough annotations to fill the pipe buffer then the child process will get stuck in `ChildFPEFilter()` and never request a dump from the main process. Thus the content process will never shut down and the main process will never see that it has crashed, it will only appear indefinitely stuck. To solve this issue a few changes are necessary: * The crash annotations are not sent from the `filter` callback, they are sent from the `minidump` callback which we did not use before. This callback is executed in the child process **after** signaling the main process. * This is not enough to prevent the deadlock though, because the content process will still wait before the parent process has responded before invoking this new callback. The parent process on the other hand will generate the minidump and then call `OnChildProcessDumpRequest()` which will wait to read the annotations sent by the child process. Thus both processes would be stuck. To solve this other issue we change the order in which the parent process responds: instead of invoking the `dump_callback` first and then signaling the child process it does the opposite. I've also added a new test that covers two separate issues solved by this patch-set: that we don't deadlock when writing too much data (this issue) and that we don't fail to send an annotation if it's too large (previously the shared memory buffer was 16KiB in size so this annotation wouldn't fit). Differential Revision: https://phabricator.services.mozilla.com/D69877 --HG-- extra : moz-landing-system : lando |
||
|---|---|---|
| .. | ||
| test_content_annotation.js | ||
| test_content_exception_time_annotation.js | ||
| test_content_large_annotation.js | ||
| test_content_memory_list.js | ||
| test_content_oom_annotation_windows.js | ||
| test_content_phc.js | ||
| test_content_phc2.js | ||
| test_content_phc3.js | ||
| test_content_rust_panic.js | ||
| test_content_rust_panic_multiline.js | ||
| xpcshell-phc.ini | ||
| xpcshell.ini | ||