Comment #48 on issue 26754 by [email protected]: Chrome crash : AppCacheDispatcherHost::Initialize(IPC::Message::Sender*, int, int) http://code.google.com/p/chromium/issues/detail?id=26754
I omitted this additional information because it's obvious to me where 3 is coming from, but it's probably not obvious to anyone else. 3 comes from Singleton<base::GlobalDescriptors>()->Get(kPrimaryIPCChannel) in IPC::Channel::ChannelImpl::CreatePipe. It's the initial IPC channel in the renderer process. It doesn't have to be 3, but it usually is. In the affected renderer process (58027 in the example above), 58037.r17 starts out hooked up to fd 25, but when that's closed due to recvmsg returning 0, the mapping for 58037.r17 is removed from the pipe map. The next time something tries to use 58037.r17, ChannelNameToFD(pipe_name_) doesn't find fd 25 because it's been closed; since it's in MODE_CLIENT, it assumes that it needs to grab the initial IPC channel. Of course, the initial IPC channel is already up and it's totally wrong to try to co-opt it for 58037.r17. It's wrong to send a new HELLO, and it's wrong to use it for anything else. Just for completeness' sake, fd 3 in this case, the renderer's initial IPC channel, is associated with pipe name 58009.11e492c0.150469062. -- You received this message because you are listed in the owner or CC fields of this issue, or because you starred this issue. You may adjust your issue notification preferences at: http://code.google.com/hosting/settings -- Automated mail from issue updates at http://crbug.com/ Subscription options: http://groups.google.com/group/chromium-bugs
