[JNI crashes] Properly throw Java Exceptions from android_webview::AwAutofillClient::ShowAutofillPopupImpl |
|||||||
Issue descriptionAnother JNI crash on a thread backed by Java: -debugger_posix.cc:221 ) base::debug::BreakDebugger() -logging.cc:759 ) logging::LogMessage::~LogMessage() -jni_android.cc:243 ) base::android::CheckException(_JNIEnv*) -jni_generator_helper.h:42 ) android_webview::AwAutofillClient::ShowAutofillPopupImpl(...) -aw_autofill_client.cc:117 ) android_webview::AwAutofillClient::ShowAutofillPopup(...) -autofill_external_delegate.cc:173 ) autofill::AutofillExternalDelegate::OnSuggestionsReturned(...) -autocomplete_history_manager.cc:137 ) autofill::AutocompleteHistoryManager::SendSuggestions(...) -autocomplete_history_manager.cc:166 ) autofill::AutocompleteHistoryManager::OnWebDataServiceRequestDone(...) -web_data_request_manager.cc:178 ) WebDataRequestManager::RequestCompletedOnThread(...) -bind_internal.h:214 ) [1] -bind_internal.h:342 ) [2] -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: 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%20android_webview%3A%3AAwAutofillClient%3A%3AShowAutofillPopupImpl%27&ignore_case=false&enable_rewrite=true&omit_field_name=&omit_field_value=&omit_field_opt=%3D Accounts for less than about 2.7% of crashes on 58. I believe this is a crash caused by us (WebView) rather than an app though. [1] void base::internal::Invoker<base::internal::BindState<void (WebDataRequestManager::*)(std::__ndk1::unique_ptr<WebDataRequest, std::__ndk1::default_delete<WebDataRequest> >, std::__ndk1::unique_ptr<WDTypedResult, std::__ndk1::default_delete<WDTypedResult> >), scoped_refptr<WebDataRequestManager>, base::internal::PassedWrapper<std::__ndk1::unique_ptr<WebDataRequest, std::__ndk1::default_delete<WebDataRequest> > >, base::internal::PassedWrapper<std::__ndk1::unique_ptr<WDTypedResult, std::__ndk1::default_delete<WDTypedResult> > > >, void ()>::RunImpl<void (WebDataRequestManager::* const&)(std::__ndk1::unique_ptr<WebDataRequest, std::__ndk1::default_delete<WebDataRequest> >, std::__ndk1::unique_ptr<WDTypedResult, std::__ndk1::default_delete<WDTypedResult> >), std::__ndk1::tuple<scoped_refptr<WebDataRequestManager>, base::internal::PassedWrapper<std::__ndk1::unique_ptr<WebDataRequest, std::__ndk1::default_delete<WebDataRequest> > >, base::internal::PassedWrapper<std::__ndk1::unique_ptr<WDTypedResult, std::__ndk1::default_delete<WDTypedResult> > > > const&, 0u, 1u, 2u>(void (WebDataRequestManager::* const&)(std::__ndk1::unique_ptr<WebDataRequest, std::__ndk1::default_delete<WebDataRequest> >, std::__ndk1::unique_ptr<WDTypedResult, std::__ndk1::default_delete<WDTypedResult> >), std::__ndk1::tuple<scoped_refptr<WebDataRequestManager>, base::internal::PassedWrapper<std::__ndk1::unique_ptr<WebDataRequest, std::__ndk1::default_delete<WebDataRequest> > >, base::internal::PassedWrapper<std::__ndk1::unique_ptr<WDTypedResult, std::__ndk1::default_delete<WDTypedResult> > > > const&, base::IndexSequence<0u, 1u, 2u>) [2] base::internal::Invoker<base::internal::BindState<void (WebDataRequestManager::*)(std::__ndk1::unique_ptr<WebDataRequest, std::__ndk1::default_delete<WebDataRequest> >, std::__ndk1::unique_ptr<WDTypedResult, std::__ndk1::default_delete<WDTypedResult> >), scoped_refptr<WebDataRequestManager>, base::internal::PassedWrapper<std::__ndk1::unique_ptr<WebDataRequest, std::__ndk1::default_delete<WebDataRequest> > >, base::internal::PassedWrapper<std::__ndk1::unique_ptr<WDTypedResult, std::__ndk1::default_delete<WDTypedResult> > > >, void ()>::Run(base::internal::BindStateBase*) -callback.h:68 ) base::debug::TaskAnnotator::RunTask(char const*, base::PendingTask*)
,
May 23 2017
ShowAutofillPopupImpl makes the following JNI calls: Java_AwAutofillClient_createAutofillSuggestionArray Java_AwAutofillClient_addToAutofillSuggestionArray Java_AwAutofillClient_showAutofillPopup
,
May 23 2017
Chrome doesn't seem to make similar calls into Java - so looking at Chrome's logcats doesn't help debugging these crashes.
,
Jul 6 2017
We should search for minidumps for these crash reports to get the corresponding Java stacks.
,
Jul 11 2017
Unlike issue 739447 this one isn't only happening on Sony devices, so there may be multiple causes here.
,
Jul 12
This issue has been Available for over a year. If it's no longer important or seems unlikely to be fixed, please consider closing it out. If it is important, please re-triage the issue. Sorry for the inconvenience if the bug really should have been left as Available. For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
,
Jul 16
,
Oct 7
Crash analysis has not encountered any reports for this bug for the past 90 days. We have added the label 'crash-BugNoRepro' Crash analysis will be automatically closing the bug in 6 days. If you do not want Crash analysis to automatically close the bug, please remove the label 'crash-BugNoRepro'. If you have any feedback on this feature, please contact pranavk@
,
Oct 8
Michael, is this still an issue? We may want to close this.
,
Oct 8
There are definitely still exceptions being thrown here, see e.g. https://crash.corp.google.com/browse?q=product_name%3D%27AndroidWebView%27+AND+STRPOS%28expanded_custom_data.ChromeCrashProto.magic_signature_1.name%2C+%27AwAutofillClient%27%29+%3E+0+AND+product.Version%3D%2769.0.3497.100%27 I'm not sure if these callbacks call application code (possibly *unintentionally* through apps overriding View methods?), or are just directly calling framework code - if we're sure it's always the latter then propagating the Java exception state isn't especially useful because we can already see the Java exception in most cases and so can just fix our code or catch the exception thrown by the framework in Java if there's no way to avoid it. So yes, we should still do something about this either way, but possibly not the thing Gustav originally intended :)
,
Oct 11
Michael, tentatively assigning to you to have a look because it seems to be autofill related.. Feel free to triage as appropriate. |
|||||||
►
Sign in to add a comment |
|||||||
Comment 1 by ntfschr@chromium.org
, May 8 2017