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

Issue 719396 link

Starred by 1 user

Issue metadata

Status: Fixed
Owner:
Last visit > 30 days ago
Closed: May 2017
Components:
EstimatedDays: ----
NextAction: ----
OS: Android
Pri: 3
Type: Bug

Blocking:
issue 592556



Sign in to add a comment

[JNI crashes] Properly throw Java Exceptions from JavaScriptResultCallback

Project Member Reported by gsennton@chromium.org, May 8 2017

Issue description

This exception happens on a Java-backed thread, and with a fairly short stack trace, so might be an easy pick-off:

debugger_posix.cc:221 )	base::debug::BreakDebugger()
jni_android.cc:243 )	base::android::CheckException(_JNIEnv*)
jni_generator_helper.h:42 )	JavaScriptResultCallback
bind_internal.h:164 )	base::internal::Invoker<base::internal::BindState<bool (*)(GURL const&, content::ServiceWorkerProviderHost*), GURL>, bool (content::ServiceWorkerProviderHost*)>::Run(base::internal::BindStateBase*, content::ServiceWorkerProviderHost*&&)
callback.h:85 )	content::RenderFrameHostImpl::OnJavaScriptExecuteResponse(int, base::ListValue const&)
tuple.h:91 )	content::RenderFrameHostImpl::OnMessageReceived(IPC::Message const&)
render_process_host_impl.cc:2081 )	content::RenderProcessHostImpl::OnMessageReceived(IPC::Message const&)
ipc_channel_proxy.cc:329 )	IPC::ChannelProxy::Context::OnDispatchMessage(IPC::Message const&)
bind_internal.h:214 )	Run
callback.h:68 )	base::debug::TaskAnnotator::RunTask(char const*, base::PendingTask*)
message_loop.cc:423 )	base::MessageLoop::RunTask(base::PendingTask*)
message_loop.cc:434 )	base::MessageLoop::DeferOrRunPendingTask(base::PendingTask)
message_loop.cc:527 )	base::MessageLoop::DoWork()
message_pump_android.cc:44 )	Java_org_chromium_base_SystemMessageHandler_nativeDoRunLoopOnce


Crash corp URL for 58:
https://crash.corp.google.com/browse?q=custom_data.ChromeCrashProto.magic_signature_1.name%20CONTAINS%20%27%5BAndroid%20Java%20Exception%5D%27%20AND%20product.name%3D%27AndroidWebView%27%20AND%20product.Version%20CONTAINS%20%2758.0.3%27%20AND%20special_protos.user_feedback.mobile_data.crash_data.exception_class_name%3D%27Native%20crash%27%20AND%20custom_data.ChromeCrashProto.magic_signature_1.name%3D%27%5BAndroid%20Java%20Exception%5D%20JavaScriptResultCallback%27&ignore_case=false&enable_rewrite=true&omit_field_name=&omit_field_value=&omit_field_opt=%3D#samplereports:5,magicsignature


This crash represents about 3% of the JNI crashes on 58.
 
Status: Available (was: Untriaged)
Moving to "available" as per new bug triaging guidelines
If this callback is not performance critical we could post the callback-call as a separate Java task so that it doesn't contain any native stack. I would suspect that we don't want to regress the performance of this callback though?

Comment 3 by torne@chromium.org, May 18 2017

I'm not sure this is actually that critical :)

This is the result of an asynchronous call into the renderer to evaluate the JS code; this could already be delayed by quite a lot of factors, and is an IPC; delaying it by one more turn of the Looper doesn't seem like it will actually make much difference. It doesn't seem likely that anyone is relying on this being super timely for animation/etc purposes, because it already has unpredictable (and probably somewhat high) latency.
Owner: gsennton@chromium.org
Status: Started (was: Available)
Project Member

Comment 5 by bugdroid1@chromium.org, May 23 2017

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

commit b8b1cbadd7941505caf3cdaebfa30f019854f815
Author: gsennton <gsennton@chromium.org>
Date: Tue May 23 16:22:39 2017

[Android WebView] Propagate Java exceptions for evaluateJavascript

WebView applications can throw run-time exceptions within
WebView-callbacks. When such an exception is thrown from the callback
passed to evaluateJavascript it is not correctly propagated to Android's
feedback mechanism. This is because that callbacks is called through
JNI, and the default way (in Chromium) of handling Java exceptions
thrown on the Java-side of JNI calls is to print the stack trace for the
current exception to the logcat when the JNI call returns to native, and
then intentionally crash in native.

With this CL we avoid the problem of propagating a Java exception back
through JNI and the native stack by posting the WebView-callback (which
can cause the Java exception) as a new task to the current Java Handler.
In that way any Java exception thrown inside the WebView-callback can be
propagated directly up to the Android framework's
UncaughtExceptionHandler which then properly reports the Exception
through the framework's crash reporting mechanism.

BUG= 719396 

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

[modify] https://crrev.com/b8b1cbadd7941505caf3cdaebfa30f019854f815/android_webview/java/src/org/chromium/android_webview/AwContents.java

Status: Fixed (was: Started)

Sign in to add a comment