Revert of Eliminate a potential race in IPC::ChannelProxy (https://codereview.chromiu...
commit4a052c0b1e82d663ba4d0b5d5ae97148f5833200
authorjohnme@chromium.org <johnme@chromium.org@0039d316-1c4b-4281-b951-d872f2087c98>
Tue, 11 Mar 2014 13:54:51 +0000 (11 13:54 +0000)
committerjohnme@chromium.org <johnme@chromium.org@0039d316-1c4b-4281-b951-d872f2087c98>
Tue, 11 Mar 2014 13:54:51 +0000 (11 13:54 +0000)
tree4f255979bc8d44462a5f99dbe20fdde136b3bbfe
parent688d82173be7b00aa3397191c25e1c32f5ce32ea
Revert of Eliminate a potential race in IPC::ChannelProxy (https://codereview.chromium.org/183553004/)

Reason for revert:
Since this has landed, testsuite content_browsertests is failing on bot Android Tests (dbg) on the chromium.linux waterfall.

Specifically, the WebContentsImplBrowserTest.OpenURLSubframe test is consistently crashing, with the following DCHECK:

[FATAL:device_orientation_message_filter.cc(18)] Check failed: BrowserThread::CurrentlyOn(BrowserThread::IO).

This corresponds the the following DCHECK about being on the IO thread:

DeviceOrientationMessageFilter::~DeviceOrientationMessageFilter() {
  DCHECK(BrowserThread::CurrentlyOn(BrowserThread::IO));
  if (is_started_)
    DeviceInertialSensorService::GetInstance()->RemoveConsumer(
        CONSUMER_TYPE_ORIENTATION);
}

This same DCHECK failed in one of the try jobs on this CL: http://build.chromium.org/p/tryserver.chromium/builders/android_dbg_triggered_tests/builds/133648

Since this DCHECK has never been observed to fail before (certainly not in the last 200 builds), and has failed both in this CL's try job and twice in a row on the waterfall since landing this CL, it seems very likely that this CL is the cause.

At a guess, the changes to ChannelProxy::Context::OnRemoveFilter seem quite relevant here.

Original issue's description:
> Eliminate a potential race in IPC::ChannelProxy
>
> Doing the following steps with ChannelProxy leads to a data race:
> 1) Create the ChannelProxy, but don't initialize it.
> 2) Add a filter.
> 3) Init the ChannelProxy.
>
> The problem is, AddFilter() posts a task from the Listener thread to the IPC task runner to do OnAddFilter. Prior to this patch, OnAddFilter will try to read channel_ even though channel_ may not have been initialized, and it's accessed without any synchronization.
>
> This patch only really adds the filter if peer_pid_ has been set on the IPC::Channel thread; otherwise, it waits until the connection has been established to really add filters.
>
> See the bug for more detail.
>
> BUG=244383
>
> Committed: https://src.chromium.org/viewvc/chrome?view=rev&revision=256188

TBR=jam@chromium.org,dmichael@chromium.org
NOTREECHECKS=true
NOTRY=true
BUG=244383

Review URL: https://codereview.chromium.org/194923004

git-svn-id: svn://svn.chromium.org/chrome/trunk/src@256221 0039d316-1c4b-4281-b951-d872f2087c98
ipc/ipc_channel_nacl.cc
ipc/ipc_channel_nacl.h
ipc/ipc_channel_proxy.cc
ipc/ipc_channel_proxy.h