mirror of
https://github.com/chromium/crashpad.git
synced 2025-03-09 22:26:06 +00:00
76ef9b5c2b
Second follow up to https://chromium-review.googlesource.com/c/400015/ The ideal would be that if we fail to start the handler, then we don't end up passing through our unhandled exception filter at all. In the case of the non-initial client (i.e. renderers) we can do this by not setting our UnhandledExceptionFilter until after we know we've connected successfully (because those connections are synchronous from its point of view). We also change WaitForNamedPipe in the connection message to block forever, so as long as the precreated pipe exists, they'll wait to connect. After the initial client has passed the server side of that pipe to the handler, the handler has the only handle to it. So, if the handler has disappeared for whatever reason, pipe-connecting clients will fail with FILE_NOT_FOUND, and will not stick around in the connection loop. This means non-initial clients do not need additional logic to avoid getting stuck in our UnhandledExceptionFilter. For the initial client, it would be ideal to avoid passing through our UEF too, but none of the 3 options are great: 1. Block until we find out if we started, and then install the filter. We don't want to do that, because we don't want to wait. 2. Restore the old filter if it turns out we failed to start. We can't do that because Chrome disables ::SetUnhandledExceptionFilter() immediately after StartHandler/SetHandlerIPCPipe returns. 3. Don't install our filter until we've successfully started. We don't want to do that because we'd miss early crashes, negating the benefit of deferred startup. So, we do need to pass through our UnhandledExceptionFilter. I don't want more Win32 API calls during the vulnerable filter function. So, at any point during async startup where there's a failure, set a global atomic that allows the filter function to abort without trying to signal a handler that's known to not exist. One further improvement we might want to look at is unexpected termination of the handler (as opposed to a failure to start) which would still result in a useless Sleep(60s). This isn't new behaviour, but now we have a clear thing to do if we detect the handler is gone. (Also a missing DWORD/size_t cast for the _x64 bots.) R=mark@chromium.org BUG=chromium:567850,chromium:656800 Change-Id: I5be831ca39bd8b2e5c962b9647c8bd469e2be878 Reviewed-on: https://chromium-review.googlesource.com/400985 Reviewed-by: Mark Mentovai <mark@chromium.org>