To reproduce: 1. run-webkit-tests --webkit-test-runner You'll hit an ASSERT_NOT_REACHED() on launch in Connection::readEventHandler because GetOverlappedResult returned FALSE and GetLastError returned ERROR_MORE_DATA.
<rdar://problem/8197571>
MSDN says: The results reported by the GetOverlappedResult function are those of the specified handle's last overlapped operation to which the specified OVERLAPPED structure was provided, and for which the operation's results were pending. <http://msdn.microsoft.com/en-us/library/ms683209(VS.85).aspx> and: If a named pipe is being read in message mode and the next message is longer than the nNumberOfBytesToRead parameter specifies, ReadFile returns FALSE and GetLastError returns ERROR_MORE_DATA. The remainder of the message can be read by a subsequent call to the ReadFile or PeekNamedPipe function. <http://msdn.microsoft.com/en-us/library/aa365467(VS.85).aspx> So we must be sending a message that's more than inlineMessageMaxSize (4096) bytes.
Indeed, we're sending a message that's 9128 bytes.
I added an (incorrect, but useful for debugging) assertion to Connection::sendOutGoingMessage: ASSERT(arguments->bufferSize() < inlineMessageMaxSize); This assertion does get hit. It looks like the message being sent has an ID of 0x00050003, which I think corresponds to WebProcessProxyMessage::PostMessage. Sam thinks that this is likely the render tree dump being sent from the web process to the UI process.
I think our existing ReadFile code is a little wrong. MSDN says: Use NULL for [lpNumberOfBytesRead] if this is an asynchronous operation to avoid potentially erroneous results. <http://msdn.microsoft.com/en-us/library/aa365467(VS.85).aspx> But we're not doing that. I think we're supposed to call GetOverlappedResult to get the number of bytes read even if ReadFile returns TRUE.
Created attachment 62224 [details] Patch
Committed r63852: <http://trac.webkit.org/changeset/63852>