New issue
Advanced search Search tips

Issue 778250 link

Starred by 1 user

Issue metadata

Status: Fixed
Owner:
Closed: Oct 2017
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Linux
Pri: 1
Type: Bug



Sign in to add a comment

BrowserGpuChannelHostFactoryTest.CreateTransferBuffer flaky

Project Member Reported by vasi...@chromium.org, Oct 25 2017

Issue description

https://build.chromium.org/p/chromium.linux/builders/Cast%20Linux/builds/45049

[ RUN      ] BrowserGpuChannelHostFactoryTest.CreateTransferBuffer
DevTools listening on ws://127.0.0.1:47601/devtools/browser/1d7294f8-d804-458b-a5ad-3ae804308853
../../content/browser/gpu/gpu_ipc_browsertests.cc:348: Failure
Expected: (impl->GetLastState().error) != (gpu::error::kNoError), actual: 0 vs 0
[24234:24255:1025/061817.910117:1402398752:WARNING:ipc_message_attachment_set.cc(49)] MessageAttachmentSet destroyed with unconsumed attachments: 0/1
[  FAILED  ] BrowserGpuChannelHostFactoryTest.CreateTransferBuffer, where TypeParam =  and GetParam() =  (94 ms)
 

Comment 1 by danakj@chromium.org, Oct 25 2017

Cc: sunn...@chromium.org piman@chromium.org
Components: Tests>Flaky
Labels: -Pri-3 Pri-1
  // Lose the connection to the gpu to lose the context.
  GetGpuChannel()->DestroyChannel();
  // It's not visible until we run the task queue.
  EXPECT_EQ(impl->GetLastState().error, gpu::error::kNoError);
  // Wait to see the error occur.
  base::RunLoop().RunUntilIdle();
  EXPECT_NE(impl->GetLastState().error, gpu::error::kNoError);   <- fails

The error isn't visible after running the message loop, which means that DestroyChannel didn't make a posted task?

- DestroyChannel deletes the |channel_| which is a IPC::SyncChannel.
- channel_ has a message filter that is |channel_filter_|.
- The filter is added on the |channel_|'s ChannelProxy::Context with a posted task to the ipc task runner (IO thread)
- SyncChannel is-a ChannelProxy, whose destructor calls Close(). It posts a task for Context::OnChannelClosed to the IO thread.
- OnChannelClosed will call the message filter's OnChannelClosing on the IO thread, which ends up in GpuChannelHost::OnChannelError.
- GpuChannelHost::OnChannelError PostTasks to inform its listeners_ which were added with AddRoute, which CommandBufferProxyImpl did with a task runner back to main thread.
- Finally CommandBufferProxyImpl::OnChannelError runs on the main thread which sets the error state the test wants to read.

The test waits for the main thread to be idle, but the IO thread is the one processing the channel destruction, and then posting back to the main thread, and this can race.

Comment 2 by danakj@chromium.org, Oct 25 2017

Status: Started (was: Untriaged)

Comment 3 by danakj@chromium.org, Oct 25 2017

Summary: BrowserGpuChannelHostFactoryTest.CreateTransferBuffer flaky (was: BrowserGpuChannelHostFactoryTest.CreateTransferBuffer аlaky)
Project Member

Comment 4 by bugdroid1@chromium.org, Oct 25 2017

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/376cc10d17243cb8ebcc66410e06f9191df3ef1e

commit 376cc10d17243cb8ebcc66410e06f9191df3ef1e
Author: danakj <danakj@chromium.org>
Date: Wed Oct 25 19:02:34 2017

Fix flaky BrowserGpuChannelHostFactoryTest.CreateTransferBuffer

DestroyChannel() needs a round trip through the IO thread before
its effects are visible on the main thread. The test was only waiting
for the main thread MessageLoop to run, making it flaky. More details
in the bug.

R=piman@chromium.org

Bug:  778250 
Change-Id: I99341ecccaa5efdc1d6da31afd5c96f4ceff04dd
Reviewed-on: https://chromium-review.googlesource.com/738510
Reviewed-by: Antoine Labour <piman@chromium.org>
Commit-Queue: danakj <danakj@chromium.org>
Cr-Commit-Position: refs/heads/master@{#511543}
[modify] https://crrev.com/376cc10d17243cb8ebcc66410e06f9191df3ef1e/content/browser/gpu/gpu_ipc_browsertests.cc

Comment 5 by danakj@chromium.org, Oct 25 2017

Status: Fixed (was: Started)

Sign in to add a comment