New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.

Issue 627295 link

Starred by 2 users

Issue metadata

Status: Fixed
Owner:
Closed: Feb 2018
Cc:
Components:
EstimatedDays: ----
NextAction: 2018-02-14
OS: ----
Pri: 2
Type: Bug



Sign in to add a comment

[FATAL:gpu_video_decode_accelerator_host.cc(175)] Check failed: CalledOnValidThread().

Project Member Reported by w...@chromium.org, Jul 12 2016

Issue description

I've seen this DCHECK fire when the gpu process dies. It looks like GpuVideoDecodeAcceleratorHost::OnWillDeleteImpl() is being called on the render thread, but it's DCHECKing that it's on the media thread.

This was seen on Android, but I don't think it matters?

dcastagna@, I think you're the expert on this. Any ideas what the right thing to do is?
 
Owner: sande...@chromium.org
I'm not familiar with that code, but it seems like GpuVideoDecodeAcceleratorHost::OnWillDeleteImpl calls OnChannelError that has the same DCHECK, and that one probably matters.

Reassigning to sandersd that might know more than I do.
This is triggered when:
  1. The GPU process dies or the context is lost.
  2. There is a VDA alive at the time.
  3. The VDA (running on the media thread) does not receive OnConnectionError() before
  4. The renderer main thread uses the command buffer, triggering OnWillDelete().

(This can be done reliably by disabling OnConnectionError().)

This looks to be a case where the code was not updated properly during the switch to a shared renderer context; the fix will be to add a lock around |impl_| and post a task from OnWillDelete().
Status: Started (was: Available)
Status: Assigned (was: Started)
Perhaps surprisingly, I've not actually been working on this for 5 months.

In the meantime, VDAs are no longer using the renderer shared context; they are back on a separate media context. I'll need to validate again whether this DCHECK actually fires.
Project Member

Comment 5 by bugdroid1@chromium.org, Jan 13 2017

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

commit ddd5cb6aad0421c0fa7f82207531ada865bfe7f0
Author: emircan <emircan@chromium.org>
Date: Fri Jan 13 22:17:16 2017

Adds locks for CommandBufferProxyImpl invalidation

This CL tries to fix the race condition between the destruction of
CommandBufferProxyImpl and GpuVideo{En,De}codeAcceleratorHost.
CommandBufferProxyImpl is destroyed on main_thread whereas the other
is destroyed on media thread.
- OnWillDeleteImpl() is called on main thread and the thread check
is wrong.
- Added lock around |impl_| use.
- Post a task on media thread for OnChannelError().

BUG= 627295 ,674674
CQ_INCLUDE_TRYBOTS=master.tryserver.chromium.linux:linux_optional_gpu_tests_rel;master.tryserver.chromium.mac:mac_optional_gpu_tests_rel;master.tryserver.chromium.win:win_optional_gpu_tests_rel

Review-Url: https://codereview.chromium.org/2627173002
Cr-Commit-Position: refs/heads/master@{#443695}

[modify] https://crrev.com/ddd5cb6aad0421c0fa7f82207531ada865bfe7f0/media/gpu/ipc/client/gpu_video_decode_accelerator_host.cc
[modify] https://crrev.com/ddd5cb6aad0421c0fa7f82207531ada865bfe7f0/media/gpu/ipc/client/gpu_video_decode_accelerator_host.h
[modify] https://crrev.com/ddd5cb6aad0421c0fa7f82207531ada865bfe7f0/media/gpu/ipc/client/gpu_video_encode_accelerator_host.cc
[modify] https://crrev.com/ddd5cb6aad0421c0fa7f82207531ada865bfe7f0/media/gpu/ipc/client/gpu_video_encode_accelerator_host.h

Owner: emir...@chromium.org
emircan@ did #5 solve this issue?
NextAction: 2018-02-14
Status: Fixed (was: Assigned)
That should have fixed the issue. Sorry for not marking it earlier.
The NextAction date has arrived: 2018-02-14

Sign in to add a comment