Loading
Bug 1563825: Don't assert on failure to decode message after OOM. r=mccr8
Ideally, we don't want to continue running a child process if it fails to handle a message from the parent, since that could mean child and parent state could get out of sync. But since this assertion is only a diagnostic assert, it isn't guaranteeing that in release builds anyway. And since the vast majority of the crashes we are seeing in builds with diagnostic asserts enabled appear to be OOMs, we can't really use crash reports to diagnose other issues. Ideally (again), we'd determine if the failure was caused by an OOM based on the failure code returned by the structured clone decode call. Unfortunately, though, since the spec requires that we return a generic `DataCloneError` on failure, the structured clone code intentionally hides the specifics of failure from callers. Propagating out more specific failure reasons for use by privileged callers is nontrivial. So this patch essentially does the same thing as crash reports do, and checks whether an OOM was reported recently, and hasn't been recovered from by a successful GC. Differential Revision: https://phabricator.services.mozilla.com/D176288