Don't reuse the initial IPC channel

Don't reuse the initial IPC channel.

I was seeing a non-initial IPC channel getting closed in a renderer, and then
when someone tried to reuse that channel by name,
IPC::Channel::ChannelImpl::CreatePipe would assign the initial pipe.  The
initial pipe was already in use, and things would fall apart pretty rapidly.

I'm making this FATAL because the renderer's probably going to be unusable if
it gets into this state anyway, and a sad tab is probably more useful than a
tab that appears to be loading indefinitely.

BUG=26754
TEST=Test case from bug 26754 comment 9 (affected machines only):
       a. Have lots of bookmarks (import Safari defaults)
       b. Rightclick on bookmark bar, and choose "Open All Bookmarks"
      Expect: no crash.

Committed: http://src.chromium.org/viewvc/chrome?view=rev&revision=33351

[Mark Mentovai, 2009-11-30 21:45:46]

Normally, I'd probably just send this to Adam, but I'm under a bit of a time
crunch here, and Adam's not online.

Jeremy, I know you've done IPC work, but if you don't feel comfortable reviewing
this, just say the word, and I'll hunt down someone else (if I haven't heard
from Adam.)

[jeremy, 2009-11-30 21:50:10]

lgtm

http://codereview.chromium.org/452021/diff/1/2
File ipc/ipc_channel_posix.cc (right):

http://codereview.chromium.org/452021/diff/1/2#newcode343
ipc/ipc_channel_posix.cc:343: // initial channel must not be recycled here.
Could you point at the bug # from the comment?

[agl, 2009-11-30 22:00:17]

LGTM.

I don't understand the control flow that would cause two IPC systems to try and
startup in the renderer, but hopefully with this patch you'll be able to get a
stack trace of the problem.

[Mark Mentovai, 2009-11-30 22:02:04]

agl@chromium.org wrote:
> LGTM.
>
> I don't understand the control flow that would cause two IPC systems to try
and
> startup in the renderer, but hopefully with this patch you'll be able to get a
> stack trace of the problem.

That's the plan.

I might have a lead on the underlying problem now, actually, but it
seems like having the renderer die is preferable regardless of any
other fix.

Certainly, it's better than having the browser die.

Mark