New issue
Advanced search Search tips

Issue 709631 link

Starred by 3 users

Issue metadata

Status: Assigned
Owner:
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Android
Pri: 2
Type: Bug

Blocking:
issue 680777
issue 819126



Sign in to add a comment

Delay calling into mediacodec in gpu process

Project Member Reported by boliu@chromium.org, Apr 7 2017

Issue description

There's some evidence that there's MediaCodecList makes a binder call that may hang the gpu process. And most of these are on start up. There's some speculation at crbug.com/690118#c29 that binder can deadlock, and chrome certainly makes lots of synchronous binder calls *with* locks held, especially during child process start up.

Here's the evidence, takes awhile to load though.
https://crash.corp.google.com/browse?q=product.name%3D%27Chrome_Android%27%20AND%20custom_data.ChromeCrashProto.ptype%3D%27gpu-process%27%20OMIT%20RECORD%20IF%20SUM(thread.StackTrace.StackFrame.FunctionName%3D%27register_android_media_MediaCodecList(_JNIEnv*)%27)%20%3D%200&ignore_case=false&enable_rewrite=true&omit_field_name=thread.StackTrace.StackFrame.FunctionName&omit_field_value=register_android_media_MediaCodecList(_JNIEnv*)&omit_field_opt=%3D#-samplereports:5,magicsignature:50,processuptime,-gpuvendor,-gpurenderer,-gpudriverversion,-systemmodified


So I think the first call into MediaCodecList is from AndroidVideoDecodeAccelerator::GetCapabilities. I was wondering if it's possible to make that call later on first use rather than on start up. Or mitigate this some other way?
 
Components: -Internals>Media Internals>Media>Hardware
Owner: sande...@chromium.org
Status: Assigned (was: Untriaged)
start from sandersd@, remove from untriaged plate.

Comment 2 by boliu@chromium.org, Apr 10 2017

hardware?
I think it should be possible to request that asynchronously and defer initialize until it's available in GVD. I'm not sure how hard that would be to implement though. Probably it's just adding a new IPC to fill out the struct on demand (if uncached) at decoder creation time.

Comment 4 by boliu@chromium.org, Apr 10 2017

Labels: -Pri-3 Pri-2
P2 then? Is sandersd the right owner here?
Yup sgtm; we're in the process of switching to a new VDA architecture, so I defer to him if we want to just skip changing GVD and just move Android to VDAv2 to avoid this.
Project Member

Comment 6 by bugdroid1@chromium.org, Apr 13 2017

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

commit 169f23ffda76c9c000b3ff2366a0ff9efa5abb03
Author: boliu <boliu@chromium.org>
Date: Thu Apr 13 03:18:05 2017

android: Swallow MediaCodecList constructor exception

Bad android implementation can sometimes throw exceptions. Just swallow
it and pretend MediaCodecList is not supported.

BUG=695248, 709631

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

[modify] https://crrev.com/169f23ffda76c9c000b3ff2366a0ff9efa5abb03/media/base/android/java/src/org/chromium/media/MediaCodecUtil.java

Project Member

Comment 7 by sheriffbot@chromium.org, May 5 2017

Labels: Fracas FoundIn-M-60
Users experienced this crash on the following builds:

Android Dev 60.0.3087.3 -  0.46 CPM, 4 reports, 3 clients (signature [GPU hang] _JNIEnv::CallStaticObjectMethod)

If this update was incorrect, please add "Fracas-Wrong" label to prevent future updates.

- Go/Fracas

Comment 8 by boliu@chromium.org, May 26 2017

any progress here?
Project Member

Comment 9 by bugdroid1@chromium.org, May 26 2017

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

commit 721f723a4dd263c357515574823e8f3a91ee5561
Author: Bo Liu <boliu@chromium.org>
Date: Fri May 26 20:26:44 2017

android: Swallow MediaCodecList.getCodecCount exception

Bad android implementation can sometimes throw exceptions. Just swallow
it and pretend MediaCodecList is not supported.

Second in this game of whac-a-mole.

BUG=695248, 709631

Change-Id: I8debc004aad7f3c01160a0b154de15bc49a4af35
Reviewed-on: https://chromium-review.googlesource.com/517288
Reviewed-by: Dale Curtis <dalecurtis@chromium.org>
Commit-Queue: Bo Liu <boliu@chromium.org>
Cr-Commit-Position: refs/heads/master@{#475106}
[modify] https://crrev.com/721f723a4dd263c357515574823e8f3a91ee5561/media/base/android/java/src/org/chromium/media/MediaCodecUtil.java

Project Member

Comment 10 by bugdroid1@chromium.org, May 30 2017

Labels: merge-merged-3112
The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/91075a41caaa12487fc83eb2fd2db5fa241adf9b

commit 91075a41caaa12487fc83eb2fd2db5fa241adf9b
Author: Bo Liu <boliu@chromium.org>
Date: Tue May 30 20:06:52 2017

[Merge M60] android: Swallow MediaCodecList.getCodecCount exception

Bad android implementation can sometimes throw exceptions. Just swallow
it and pretend MediaCodecList is not supported.

Second in this game of whac-a-mole.

BUG=695248, 709631

Change-Id: I8debc004aad7f3c01160a0b154de15bc49a4af35
Reviewed-on: https://chromium-review.googlesource.com/517288
Reviewed-by: Dale Curtis <dalecurtis@chromium.org>
Commit-Queue: Bo Liu <boliu@chromium.org>
Cr-Original-Commit-Position: refs/heads/master@{#475106}(cherry picked from commit 721f723a4dd263c357515574823e8f3a91ee5561)
Reviewed-on: https://chromium-review.googlesource.com/518334
Reviewed-by: Bo Liu <boliu@chromium.org>
Cr-Commit-Position: refs/branch-heads/3112@{#37}
Cr-Branched-From: b6460e24cf59f429d69de255538d0fc7a425ccf9-refs/heads/master@{#474897}
[modify] https://crrev.com/91075a41caaa12487fc83eb2fd2db5fa241adf9b/media/base/android/java/src/org/chromium/media/MediaCodecUtil.java

Project Member

Comment 11 by sheriffbot@chromium.org, Jul 23 2017

Labels: FoundIn-M-61
Users experienced this crash on the following builds:

Android Dev 61.0.3162.3 -  39.47 CPM, 155 reports, 1 clients (signature [GPU hang] _JNIEnv::CallStaticObjectMethod)

If this update was incorrect, please add "Fracas-Wrong" label to prevent future updates.

- Go/Fracas
Project Member

Comment 12 by sheriffbot@chromium.org, Oct 5 2017

Labels: FoundIn-M-63
Users experienced this crash on the following builds:

Android Dev 63.0.3223.7 -  2.56 CPM, 116 reports, 6 clients (signature [GPU hang] _JNIEnv::CallStaticObjectMethod)

If this update was incorrect, please add "Fracas-Wrong" label to prevent future updates.

- Go/Fracas

Comment 13 by boliu@chromium.org, Oct 27 2017

ping, any update here? GpuServiceImpl::UpdateGPUInfoFromPreferences still calls into GpuVideoDecodeAccelerator::GetCapabilities very early in gpu start up, and there's circumstantial evidence this is causing a lot of issues
Short answer is "no". It is still a goal to eliminate GetCapabilities(), but no replacement API has been proposed yet that solves all of the problems. The migration to Mojo has improved latency enough that we may be able to avoid doing it early for VDAs, but again there are use cases that are unsolved.

Comment 15 by boliu@chromium.org, Oct 30 2017

What about dynamically blacklisting avd if gpu crashes before establish channel succeeds?
Project Member

Comment 16 by sheriffbot@chromium.org, Feb 22 2018

Labels: FoundIn-M-66
Users experienced this crash on the following builds:

Android Dev 66.0.3348.3 -  0.45 CPM, 16 reports, 5 clients (signature [GPU hang] _JNIEnv::CallStaticObjectMethod)

If this update was incorrect, please add "Fracas-Wrong" label to prevent future updates.

- Go/Fracas
Project Member

Comment 17 by sheriffbot@chromium.org, Mar 29 2018

Labels: FoundIn-67
Users experienced this crash on the following builds:

Android Dev 67.0.3381.2 -  0.72 CPM, 4 reports, 2 clients (signature [GPU hang] _JNIEnv::CallStaticObjectMethod)

If this update was incorrect, please add "Fracas-Wrong" label to prevent future updates.

- Go/Fracas
bump again.

I believe solving this will have significantly reduce the number of gpu hang crash reports. It's been a year now. Can we get this prioritized?
MediaCodecVideoDecoder eliminates GetCapabilities(), and is launching this quarter. Additional work is required to resolve this issue though, as WebRTC will still be using AndroidVideoDecodeAccelerator for a bit longer.
Can I try MediaCodecVideoDecoder locally to see if early MediaCodec calls are gone?
You can try it, but as long as AndroidVideoDecodeAccelerator exists there will still be early calls. MediaCodecVideoDecoder is the path to eliminating AndroidVideoDecodeAccelerator, but this specific bug won't be resolved until after it launches.

MediaCodecVideoDecoder is enabled by --enable-features=MojoVideoDecoder

Comment 22 by boliu@chromium.org, May 11 2018

Blocking: 819126

Sign in to add a comment