mirror of
https://github.com/mozilla/gecko-dev.git
synced 2025-10-30 15:58:03 +02:00
b5f5840129
Before this patch if we failed to launch the crash helper client then we would either freeze or crash Firefox, which is not what we want. This makes sure that errors when launching the crash helper are not catastrophic. Additionally, this problem was triggered on a machine that launched more than 64 child processes at startup during session restore. That was a hard limit on Windows because of the limitations of WaitForMultipleObjects(). I adjusted the code to also handle that gracefully even though we don't support more than 64 child processes at the moment. That's not a big deal because we're not yet using that particular IPC channel, so ignoring every child process above the 63rd doesn't change anything at the moment. Last but not least there was a small race in the crash helper rendez-vous that might cause Linux to attempt to generate a minidump before we had allowed a child process to allow the crash helper to ptrace() it. This was also fixed. Differential Revision: https://phabricator.services.mozilla.com/D256299 |
||
|---|---|---|
| .. | ||
| app | ||
| chromium | ||
| docs | ||
| glue | ||
| gtest | ||
| ipdl | ||
| mscom | ||
| rust/ipdl_utils | ||
| testshell | ||
| metrics.yaml | ||
| moz.build | ||
| pull-chromium.py | ||