Work around GPU process crashing in TracingControllerAndroid

Work around GPU process crashing in TracingControllerAndroid

In WebVR presentation mode, the GPU process crashes when receiving tracing
broadcasts due to not having native methods such as nativeGetDefaultCategories
available. Add a try/catch to work around this.

BUG=710591

[klausw, 2017-04-11 20:37:14]

klausw@chromium.org changed reviewers:
+ aelias@chromium.org, skyostil@chromium.org

[klausw, 2017-04-11 20:37:15]

I'm not convinced this is the right way to fix it, but it worked for me to get
traces again. I've seen this kind of crashes sporadically earlier, but recently
it started crashing on every trace attempt. Please let me know if there's a
better approach.

[Sami, 2017-04-12 13:19:22]

That's very strange, I'm sure I've been able to trace the GPU process on Android
before. Did something change recently perhaps? I'm not sure why the natives
wouldn't exist in the GPU process in the first place.

[klausw, 2017-04-12 17:17:21]

On 2017/04/12 13:19:22, Sami wrote:
> That's very strange, I'm sure I've been able to trace the GPU process on
Android
> before. Did something change recently perhaps? I'm not sure why the natives
> wouldn't exist in the GPU process in the first place.

Tracing actually works fine, I see data from CrGpuMain in the output. The
problem seems to be the broadcast for getting categories. With my patch in
place, I get an identical list of categories including "gpu" when running
"build/android/adb_profile_chrome --browser chromium -c list". I'll update the
bug.

I don't understand what's going on here, but do you think this workaround would
be acceptable while trying to figure out a better fix? The traces are pretty
essential for diagnosing WebVR performance issues.

[Sami, 2017-04-13 09:25:17]

Description was changed from

==========
Work around GPU process crashing in TracingControllerAndroid

In WebVR presentation mode, the GPU process crashes when receiving tracing
broadcasts due to not having native methods such as nativeGetDefaultCategories
available. Add a try/catch to work around this.

BUG=710591
==========

to

==========
Work around GPU process crashing in TracingControllerAndroid

In WebVR presentation mode, the GPU process crashes when receiving tracing
broadcasts due to not having native methods such as nativeGetDefaultCategories
available. Add a try/catch to work around this.

BUG=710591
==========

[Sami, 2017-04-13 09:26:01]

+cc some tracing folks for ideas, I'm still not sure how this could be broken
just the GPU process.

Have you checked whether chrome://inspect?tracing has the same issue?

[Primiano Tucci (use gerrit), 2017-04-13 09:29:40]

"In WebVR presentation mode, the GPU process crashes when receiving tracing
broadcasts due to not having native methods such as nativeGetDefaultCategories
available."

Ehm, why does that happen in the first place? That function is defined in
content/browser/android/tracing_controller_android.cc.
This smells to me like there is some more substantial problem underneath and we
are just trying to hide the place where it shows up

[Primiano Tucci (use gerrit), 2017-04-13 09:31:09]

On 2017/04/13 09:29:40, Primiano Tucci wrote:
> "In WebVR presentation mode, the GPU process crashes when receiving tracing
> broadcasts due to not having native methods such as nativeGetDefaultCategories
> available."
> 
> Ehm, why does that happen in the first place? That function is defined in
> content/browser/android/tracing_controller_android.cc.
> This smells to me like there is some more substantial problem underneath and
we
> are just trying to hide the place where it shows up

Also, hold on, how do we end up hitting
content/**browser**/TracingControllerAndroid.java in the GPU process in the
first place?

[klausw, 2017-04-13 15:56:50]

On 2017/04/13 09:31:09, Primiano Tucci wrote:
> On 2017/04/13 09:29:40, Primiano Tucci wrote:
> > "In WebVR presentation mode, the GPU process crashes when receiving tracing
> > broadcasts due to not having native methods such as
nativeGetDefaultCategories
> > available."
> > 
> > Ehm, why does that happen in the first place? That function is defined in
> > content/browser/android/tracing_controller_android.cc.
> > This smells to me like there is some more substantial problem underneath and
> we
> > are just trying to hide the place where it shows up

I am fully aware that this is just a crude workaround, and agree that the
underlying issue should be fixed. My primary goal for this patch was to get
traces working again and to provide a bit more information in the error message
as opposed to just crashing, I don't know enough about the underlying code to do
a more fundamental fix.

> Also, hold on, how do we end up hitting
> content/**browser**/TracingControllerAndroid.java in the GPU process in the
> first place?

Can we move the discussion about the underlying issue to the bug? I added more
information in http://crbug.com/710591#c4 but I'm mystified about what's going
on.