Fix an attachment broker race condition.

Fix an attachment broker race condition.

Race condition: Browser process B starts two new processes: C1 and C2. C1 sends
C2 an attachment brokered message, via B. But B has not yet finished
establishing its connection with C2.

This CL stores wire formats that cannot be immediately sent to the destination
process because the connection has not been established. When the connection is
established, the wire formats are sent. Note that the resource itself has
already been duplicated into the destination.

If, for some reason, the connection is never established, then the assumption
is that the destination process died. The resource itself will be cleaned up by
the OS, but the data structure HandleWireFormat will leak. This is known to be
rare.

If, at a later point in time, a new process is created with the same process
id, the WireFormats will be passed to the new process. There is no security
problem, since the resource itself is not being sent. Furthermore, it is
unlikely to affect the functionality of the new process, since AttachmentBroker
ids are large, unguessable nonces.

BUG=609262, 493414
TBR=asvitkine@chromium.org

Committed: https://crrev.com/3e0f4d3ce943d23e3862d42a273086613be46155
Cr-Commit-Position: refs/heads/master@{#393882}

[erikchen, 2016-05-14 01:09:26]

Description was changed from

==========
clang format and comments.


destination failure.

BUG=
==========

to

==========
Fix an attachment broker race condition.

Race condition: Browser process B starts two new processes: C1 and C2. C1 sends
C2 an attachment brokered message, via B. But B has not yet finished
establishing its connection with C2.

This CL stores wire formats that cannot be immediately sent to the destination
process because the connection has not been established. When the connection is
established, the wire formats are sent. Note that the resource itself has
already been duplicated into the destination.

If, for some reason, the connection is never established, then the assumption
is that the destination process died. The resource itself will be cleaned up by
the OS, but the data structure HandleWireFormat will leak. This is known to be
rare.

If, at a later point in time, a new process is created with the same process
id, the WireFormats will be passed to the new process. There is no security
problem, since the resource itself is not being sent. Furthermore, it is
unlikely to affect the functionality of the new process, since AttachmentBroker
ids are large, unguessable nonces.

BUG=609262, 493414
==========

[erikchen, 2016-05-14 01:09:47]

Description was changed from

==========
Fix an attachment broker race condition.

Race condition: Browser process B starts two new processes: C1 and C2. C1 sends
C2 an attachment brokered message, via B. But B has not yet finished
establishing its connection with C2.

This CL stores wire formats that cannot be immediately sent to the destination
process because the connection has not been established. When the connection is
established, the wire formats are sent. Note that the resource itself has
already been duplicated into the destination.

If, for some reason, the connection is never established, then the assumption
is that the destination process died. The resource itself will be cleaned up by
the OS, but the data structure HandleWireFormat will leak. This is known to be
rare.

If, at a later point in time, a new process is created with the same process
id, the WireFormats will be passed to the new process. There is no security
problem, since the resource itself is not being sent. Furthermore, it is
unlikely to affect the functionality of the new process, since AttachmentBroker
ids are large, unguessable nonces.

BUG=609262, 493414
==========

to

==========
Fix an attachment broker race condition.

Race condition: Browser process B starts two new processes: C1 and C2. C1 sends
C2 an attachment brokered message, via B. But B has not yet finished
establishing its connection with C2.

This CL stores wire formats that cannot be immediately sent to the destination
process because the connection has not been established. When the connection is
established, the wire formats are sent. Note that the resource itself has
already been duplicated into the destination.

If, for some reason, the connection is never established, then the assumption
is that the destination process died. The resource itself will be cleaned up by
the OS, but the data structure HandleWireFormat will leak. This is known to be
rare.

If, at a later point in time, a new process is created with the same process
id, the WireFormats will be passed to the new process. There is no security
problem, since the resource itself is not being sent. Furthermore, it is
unlikely to affect the functionality of the new process, since AttachmentBroker
ids are large, unguessable nonces.

BUG=609262, 493414
==========

[erikchen, 2016-05-14 01:24:10]

erikchen@chromium.org changed reviewers:
+ jam@chromium.org, tsepez@chromium.org

[erikchen, 2016-05-14 01:24:11]

tsepez, jam: To whoever gets here first, please review.

This is probably responsible for a non-trivial percentage of renderer hangs on
M50 and M51. I'd like to land this to Canary ASAP, and assuming everything looks
good, merge to M50 and M51.
https://bugs.chromium.org/p/chromium/issues/detail?id=609262#c48

[erikchen, 2016-05-14 01:24:37]

Description was changed from

==========
Fix an attachment broker race condition.

Race condition: Browser process B starts two new processes: C1 and C2. C1 sends
C2 an attachment brokered message, via B. But B has not yet finished
establishing its connection with C2.

This CL stores wire formats that cannot be immediately sent to the destination
process because the connection has not been established. When the connection is
established, the wire formats are sent. Note that the resource itself has
already been duplicated into the destination.

If, for some reason, the connection is never established, then the assumption
is that the destination process died. The resource itself will be cleaned up by
the OS, but the data structure HandleWireFormat will leak. This is known to be
rare.

If, at a later point in time, a new process is created with the same process
id, the WireFormats will be passed to the new process. There is no security
problem, since the resource itself is not being sent. Furthermore, it is
unlikely to affect the functionality of the new process, since AttachmentBroker
ids are large, unguessable nonces.

BUG=609262, 493414
==========

to

==========
Fix an attachment broker race condition.

Race condition: Browser process B starts two new processes: C1 and C2. C1 sends
C2 an attachment brokered message, via B. But B has not yet finished
establishing its connection with C2.

This CL stores wire formats that cannot be immediately sent to the destination
process because the connection has not been established. When the connection is
established, the wire formats are sent. Note that the resource itself has
already been duplicated into the destination.

If, for some reason, the connection is never established, then the assumption
is that the destination process died. The resource itself will be cleaned up by
the OS, but the data structure HandleWireFormat will leak. This is known to be
rare.

If, at a later point in time, a new process is created with the same process
id, the WireFormats will be passed to the new process. There is no security
problem, since the resource itself is not being sent. Furthermore, it is
unlikely to affect the functionality of the new process, since AttachmentBroker
ids are large, unguessable nonces.

BUG=609262, 493414
TBR=asvitkine@chromium.org
==========

[erikchen, 2016-05-14 01:24:39]

The CQ bit was checked by erikchen@chromium.org to run a CQ dry run

[erikchen, 2016-05-14 01:24:56]

Description was changed from

==========
Fix an attachment broker race condition.

Race condition: Browser process B starts two new processes: C1 and C2. C1 sends
C2 an attachment brokered message, via B. But B has not yet finished
establishing its connection with C2.

This CL stores wire formats that cannot be immediately sent to the destination
process because the connection has not been established. When the connection is
established, the wire formats are sent. Note that the resource itself has
already been duplicated into the destination.

If, for some reason, the connection is never established, then the assumption
is that the destination process died. The resource itself will be cleaned up by
the OS, but the data structure HandleWireFormat will leak. This is known to be
rare.

If, at a later point in time, a new process is created with the same process
id, the WireFormats will be passed to the new process. There is no security
problem, since the resource itself is not being sent. Furthermore, it is
unlikely to affect the functionality of the new process, since AttachmentBroker
ids are large, unguessable nonces.

BUG=609262, 493414
TBR=asvitkine@chromium.org
==========

to

==========
Fix an attachment broker race condition.

Race condition: Browser process B starts two new processes: C1 and C2. C1 sends
C2 an attachment brokered message, via B. But B has not yet finished
establishing its connection with C2.

This CL stores wire formats that cannot be immediately sent to the destination
process because the connection has not been established. When the connection is
established, the wire formats are sent. Note that the resource itself has
already been duplicated into the destination.

If, for some reason, the connection is never established, then the assumption
is that the destination process died. The resource itself will be cleaned up by
the OS, but the data structure HandleWireFormat will leak. This is known to be
rare.

If, at a later point in time, a new process is created with the same process
id, the WireFormats will be passed to the new process. There is no security
problem, since the resource itself is not being sent. Furthermore, it is
unlikely to affect the functionality of the new process, since AttachmentBroker
ids are large, unguessable nonces.

BUG=609262, 493414
TBR=asvitkine@chromium.org
==========

[erikchen, 2016-05-14 01:24:56]

erikchen@chromium.org changed reviewers:
+ asvitkine@chromium.org

[commit-bot: I haz the power, 2016-05-14 01:24:56]

Dry run: CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/1979533003/80001
View timeline at
 https://chromium-cq-status.appspot.com/patch-timeline/1979533003/80001

[commit-bot: I haz the power, 2016-05-14 02:42:30]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2016-05-14 02:42:31]

Dry run: This issue passed the CQ dry run.

[erikchen, 2016-05-14 22:58:28]

On 2016/05/14 02:42:31, commit-bot: I haz the power wrote:
> Dry run: This issue passed the CQ dry run.

I decided to revert all the relevant changes to M50. I still intend to merge to
M51.

[Alexei Svitkine (slow), 2016-05-16 14:57:44]

histograms xml lgtm, will let others review the logic

[Tom Sepez, 2016-05-16 16:09:39]

lgtm

[erikchen, 2016-05-16 17:26:11]

The CQ bit was checked by erikchen@chromium.org

[commit-bot: I haz the power, 2016-05-16 17:26:40]

CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/1979533003/80001
View timeline at
 https://chromium-cq-status.appspot.com/patch-timeline/1979533003/80001

[jam, 2016-05-16 18:03:45]

jam@chromium.org changed reviewers:
- jam@chromium.org

[commit-bot: I haz the power, 2016-05-16 18:48:06]

Description was changed from

==========
Fix an attachment broker race condition.

Race condition: Browser process B starts two new processes: C1 and C2. C1 sends
C2 an attachment brokered message, via B. But B has not yet finished
establishing its connection with C2.

This CL stores wire formats that cannot be immediately sent to the destination
process because the connection has not been established. When the connection is
established, the wire formats are sent. Note that the resource itself has
already been duplicated into the destination.

If, for some reason, the connection is never established, then the assumption
is that the destination process died. The resource itself will be cleaned up by
the OS, but the data structure HandleWireFormat will leak. This is known to be
rare.

If, at a later point in time, a new process is created with the same process
id, the WireFormats will be passed to the new process. There is no security
problem, since the resource itself is not being sent. Furthermore, it is
unlikely to affect the functionality of the new process, since AttachmentBroker
ids are large, unguessable nonces.

BUG=609262, 493414
TBR=asvitkine@chromium.org
==========

to

==========
Fix an attachment broker race condition.

Race condition: Browser process B starts two new processes: C1 and C2. C1 sends
C2 an attachment brokered message, via B. But B has not yet finished
establishing its connection with C2.

This CL stores wire formats that cannot be immediately sent to the destination
process because the connection has not been established. When the connection is
established, the wire formats are sent. Note that the resource itself has
already been duplicated into the destination.

If, for some reason, the connection is never established, then the assumption
is that the destination process died. The resource itself will be cleaned up by
the OS, but the data structure HandleWireFormat will leak. This is known to be
rare.

If, at a later point in time, a new process is created with the same process
id, the WireFormats will be passed to the new process. There is no security
problem, since the resource itself is not being sent. Furthermore, it is
unlikely to affect the functionality of the new process, since AttachmentBroker
ids are large, unguessable nonces.

BUG=609262, 493414
TBR=asvitkine@chromium.org
==========

[commit-bot: I haz the power, 2016-05-16 18:48:07]

Committed patchset #5 (id:80001)

[commit-bot: I haz the power, 2016-05-16 18:50:22]

Description was changed from

==========
Fix an attachment broker race condition.

Race condition: Browser process B starts two new processes: C1 and C2. C1 sends
C2 an attachment brokered message, via B. But B has not yet finished
establishing its connection with C2.

This CL stores wire formats that cannot be immediately sent to the destination
process because the connection has not been established. When the connection is
established, the wire formats are sent. Note that the resource itself has
already been duplicated into the destination.

If, for some reason, the connection is never established, then the assumption
is that the destination process died. The resource itself will be cleaned up by
the OS, but the data structure HandleWireFormat will leak. This is known to be
rare.

If, at a later point in time, a new process is created with the same process
id, the WireFormats will be passed to the new process. There is no security
problem, since the resource itself is not being sent. Furthermore, it is
unlikely to affect the functionality of the new process, since AttachmentBroker
ids are large, unguessable nonces.

BUG=609262, 493414
TBR=asvitkine@chromium.org
==========

to

==========
Fix an attachment broker race condition.

Race condition: Browser process B starts two new processes: C1 and C2. C1 sends
C2 an attachment brokered message, via B. But B has not yet finished
establishing its connection with C2.

This CL stores wire formats that cannot be immediately sent to the destination
process because the connection has not been established. When the connection is
established, the wire formats are sent. Note that the resource itself has
already been duplicated into the destination.

If, for some reason, the connection is never established, then the assumption
is that the destination process died. The resource itself will be cleaned up by
the OS, but the data structure HandleWireFormat will leak. This is known to be
rare.

If, at a later point in time, a new process is created with the same process
id, the WireFormats will be passed to the new process. There is no security
problem, since the resource itself is not being sent. Furthermore, it is
unlikely to affect the functionality of the new process, since AttachmentBroker
ids are large, unguessable nonces.

BUG=609262, 493414
TBR=asvitkine@chromium.org

Committed: https://crrev.com/3e0f4d3ce943d23e3862d42a273086613be46155
Cr-Commit-Position: refs/heads/master@{#393882}
==========

[commit-bot: I haz the power, 2016-05-16 18:50:23]

Patchset 5 (id:??) landed as
https://crrev.com/3e0f4d3ce943d23e3862d42a273086613be46155
Cr-Commit-Position: refs/heads/master@{#393882}