To reproduce: 1. Launch a WebKit2 browser You'll hit an assertion in Connection::setDidCloseOnConnectionWorkQueueCallback in the web process: ASSERT(!m_isConnected); This is happening because the Connection constructor on Windows synchronously sets m_isConnected to true. Here's the backtrace: > WebKit.dll!CoreIPC::Connection::setDidCloseOnConnectionWorkQueueCallback(void (WorkQueue &, CoreIPC::Connection *)* callback=0x1001108b) Line 74 + 0x29 bytes C++ WebKit.dll!WebKit::WebProcess::initialize(void * serverIdentifier=0x0000abcc, RunLoop * runLoop=0x02296ec0) Line 132 C++ WebKit.dll!WebKit::WebProcessMain(const WebKit::CommandLine & commandLine={...}) Line 80 C++ WebKit.dll!WebKitMain(const WebKit::CommandLine & commandLine={...}) Line 48 + 0x9 bytes C++ WebKit.dll!WebKitMain(HINSTANCE__ * hInstance=0x00400000, HINSTANCE__ * hPrevInstance=0x00000000, wchar_t * lpstrCmdLine=0x0002114c, int nCmdShow=10) Line 172 + 0x9 bytes C++ WebKit2WebProcess.exe!wWinMain(HINSTANCE__ * hInstance=0x00400000, HINSTANCE__ * hPrevInstance=0x00000000, wchar_t * lpstrCmdLine=0x0002114c, int nCmdShow=10) Line 66 + 0x18 bytes C++ WebKit2WebProcess.exe!__tmainCRTStartup() Line 589 + 0x1c bytes C kernel32.dll!_BaseProcessStart@4() + 0x23 bytes
<rdar://problem/8971207>
I think we can fix this by waiting to set m_isConnnected=true until open() is called, like on Mac. Even though the pipe is already connected by that point, we won't actually receive anything from it until open() is called, so this should be safe.
Created attachment 81630 [details] Don't mark a Connection as connected until open() is called on Windows
Committed r77938: <http://trac.webkit.org/changeset/77938>