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.
Original Revision: https://phabricator.services.mozilla.com/D256299
Differential Revision: https://phabricator.services.mozilla.com/D262076
7c81a53f68