didFailToSendSyncMessage exists to guarantee that a sync call in a client process never returns null, which is important because client code is unlikely to handle such a return properly. But it's a client call, and client pointer can be null, so the code has become nonsensical after having been introduced.
Created attachment 87995 [details] proposed patch
Comment on attachment 87995 [details] proposed patch View in context: https://bugs.webkit.org/attachment.cgi?id=87995&action=review > Source/WebKit2/Platform/CoreIPC/Connection.cpp:422 > + exit(0); Funny that this error condition exits 0. I guess that's to mean that the process intended to end itself?
Comment on attachment 87995 [details] proposed patch View in context: https://bugs.webkit.org/attachment.cgi?id=87995&action=review >> Source/WebKit2/Platform/CoreIPC/Connection.cpp:422 > > Funny that this error condition exits 0. I guess that's to mean that the process intended to end itself? This is a fatal condition (most likely, the server process has exited already) - but if we return a super rare null result, we can crash instead if cleanly exiting a moment later.
We don't want all client connections to do this, so I think this should be a callback function on the connection instead.
<rdar://problem/9251669>
Anders landed this patch in another bug, with one difference being that we only set the flag on Web to UI process connection. *** This bug has been marked as a duplicate of bug 58923 ***