Same crash happens in v49 and v50

Operating system: Android
                  google/bullhead/bullhead:6.0.1/MMB29Q/2480792:user/release-keys
CPU: armv8l
     6 CPUs

Crash reason:  
Crash address: 0x0
Process uptime: not available

Thread 0 (crashed)
 0  libwebviewchromium.so!blink::CredentialManagerClient::dispatchStore [CredentialManagerClient.cpp : 65 + 0x2]
 
    Found by: given as instruction pointer in context
 1  libwebviewchromium.so!v8::internal::GlobalHandles::PendingPhantomCallback::Invoke [global-handles.cc : 967 + 0x3]
 
    Found by: call frame info
 2  libwebviewchromium.so!v8::internal::GlobalHandles::InvokeSecondPassPhantomCallbacks [global-handles.cc : 822 + 0x7]
 
    Found by: call frame info
 3  libwebviewchromium.so!v8::internal::GlobalHandles::PendingPhantomCallbacksSecondPassTask::RunInternal [global-handles.cc : 538 + 0x9]
 
    Found by: call frame info
 4  libwebviewchromium.so!base::debug::TaskAnnotator::RunTask [callback.h : 396 + 0x5]
 
    Found by: call frame info
 5  libwebviewchromium.so!scheduler::TaskQueueManager::ProcessTaskFromWorkQueue [task_queue_manager.cc : 357 + 0xd]
 
    Found by: call frame info
 6  libwebviewchromium.so!scheduler::TaskQueueManager::DoWork [task_queue_manager.cc : 282 + 0x9]
 
    Found by: call frame info
 7  libwebviewchromium.so!base::debug::TaskAnnotator::RunTask [callback.h : 396 + 0x5]
 
    Found by: call frame info
 8  libwebviewchromium.so!base::MessageLoop::RunTask [message_loop.cc : 481 + 0xd]
 
    Found by: call frame info
 9  libwebviewchromium.so!base::MessageLoop::DeferOrRunPendingTask [message_loop.cc : 490 + 0x7]
 
    Found by: call frame info
10  libwebviewchromium.so!base::MessageLoop::DoWork [message_loop.cc : 602 + 0x3]
 
    Found by: call frame info
11  libwebviewchromium.so!base::MessagePumpDefault::Run [message_pump_default.cc : 32 + 0x7]
 
    Found by: call frame info
12  libwebviewchromium.so!base::RunLoop::Run [run_loop.cc : 55 + 0x5]
 
    Found by: call frame info
13  libwebviewchromium.so!base::MessageLoop::Run [message_loop.cc : 288 + 0x5]
 
    Found by: call frame info
14  libwebviewchromium.so!base::Thread::ThreadMain [thread.cc : 199 + 0x3]
 
    Found by: call frame info
15  libwebviewchromium.so!base::::ThreadFunc [platform_thread_posix.cc : 64 + 0x7]
 
    Found by: call frame info

We have 35 reports since m48, 34 for the app com.fd.accessplusecs.aqua - maybe this is something application specific?

CredentialManagerClient seems to be something to do with password saving, which isn't supposed to be implemented in webview. mkwst@, do you know what this might be?

Is there any way you can make a test app that does enough of the same things as your real app to also crash in this way, so we can reproduce it?

CredentialManagerClient is used when processing `navigator.credentials.*`. It shouldn't be accessible at all in M48 (the feature was behind a flag), and shouldn't have any effect if the password manager backend isn't available (which it isn't in WebView).

Is your code using this API? If so, I'd love to see a code sample if you could provide one.

No, that API is not called from anywhere in the code. Because the code is is private, I am going to try to extract pieces of code and create a project I can share. I know that without code it is hard.  

We are using the Android Webview API (nothing weird here, I could share how do I initialize the webview and the settings of it) and javascript widgets. Is there a way that from a JS API a call to CredentialsManagerClient is called? 

Weird, I checked that navigator.credentials is undefined on webview 48.0.2564.71. So how is crash even possible? Is there an old prefixed version?

> Is there a way that from a JS API a call to CredentialsManagerClient is called?

Yes. navigator.credentials is a js API. Extracting the part of the html/js that causes this crash would be really helpful.

> Is there an old prefixed version?

There is not. I am equally confused. :)

After checking the Javascript code from the customer and talking with the frontend team that delivers a set of libraries used in the project, there is no trace of "navigator.credentials" in any JS code. 

I have attached the crash in version 49, not sure if that is going to be helpful. Weird thing: In version 47 everything is working fine. 

Deleted: CrashLogV49 35.4 KB

CrashLogV49 35.4 KB View Download

Crash log isn't helpful here since at this point, no one even knows how you can get to that code that's crashing. So really need the extracted html/js that triggers this crash

I understand. I am working on it. Meanwhile a question: What tool do you use to extract a meaningful logtrace from the memory dump?  

The tool is microdump_stackwalk from the chromium source tree, but its output isn't very useful without the corresponding symbols for the build of webview you're using, which aren't currently published publicly and so you can't do it yourself. (they're not particularly secret, we just haven't yet done the work to make them widely available as there's not much demand).

Thanks Torne, That is a tool that is quite interesting for me. Me and my team have build a framework around webviews and we have to deal with this kind of memory crashes from time to time. Is there any near future plans to have it released and open to the public? 

After already more than a week dealing with this issues, and still no clear solution, is it possible for you guys to tell me if the source of the crash I am attaching into this message is the same as the one I reported at the beginning of the thread? This is driving me nuts... 

Thanks for your help.

Deleted: Crash49.txt 26.3 KB

Crash49.txt 26.3 KB View Download

Crash in #14 is

 0  0x48
    Found by: given as instruction pointer in context
 1  libwebviewchromium.so!v8::internal::GlobalHandles::InvokeSecondPassPhantomCallbacks [global-handles.cc : 823 + 0x7]
    Found by: stack scanning
 2  libwebviewchromium.so!v8::internal::GlobalHandles::PendingPhantomCallbacksSecondPassTask::RunInternal [global-handles.cc : 539 + 0x9]
 3  libwebviewchromium.so!base::debug::TaskAnnotator::RunTask [callback.h : 394 + 0x5]
 4  libwebviewchromium.so!scheduler::TaskQueueManager::ProcessTaskFromWorkQueue [task_queue_manager.cc : 264 + 0xd]
 5  libwebviewchromium.so!scheduler::TaskQueueManager::DoWork [task_queue_manager.cc : 180 + 0x9]

So probably related, yes.

You can compile microdump_stackwalk from the chromium tree right now and it will do its best to generate a stack trace, but it will just output only the byte offset into each library, without function names/source locations. It also won't be as accurate (it might include incorrect entries, but will generally also include the correct ones). That might be enough to quickly check if two crashes are the same/similar, as long as the crashes are from the same version of webview (since offsets will change between versions).

Publishing the symbols is something we'll probably get around to eventually but it's not a priority at the moment and so I can't promise it will happen on any particular timeline :/

-----

As for this actual crash, it seems likely that this is nothing to do with navigator.credentials at all, and that the actual bug is that the callback V8 is trying to invoke is invalid/corrupt, and just happened to contain a code address inside the chromium library in the original crash. The one Toby decoded in #15 instead just jumped to an entirely invalid address. So, we probably need V8 experts here, and it would still be much easier if we had a way to reproduce this.

For any googlers looking at this, here's all our crashes that pass through PendingPhantomCallbacksSecondPassTask:

https://crash.corp.google.com/browse?q=product.name%3D%27AndroidWebView%27%20AND%20special_protos.user_feedback.mobile_data.build_data.sdk_int%3E%3D21%20AND%20processingfailed%3Dfalse%20OMIT%20RECORD%20IF%20SUM(CrashedStackTrace.StackFrame.FunctionName%3D%27v8%3A%3Ainternal%3A%3AGlobalHandles%3A%3APendingPhantomCallbacksSecondPassTask%3A%3ARunInternal%27)%20%3D%200&ignore_case=false&enable_rewrite=false&omit_field_name=CrashedStackTrace.StackFrame.FunctionName&omit_field_value=base%3A%3Aandroid%3A%3ACheckException&omit_field_opt=%3D&stbtiq=&reportid=03b56bc400000000&index=9#0

Not all of these are the same issue: some of them successfully call a callback and then it just happens that the callback crashes for some other reason, but there are quite a few of these where the stack goes from "invoke a callback" to an invalid or implausible address. Looks like there might be a lifetime issue of some kind here.

Does this issue could have something in common with mine?https://bugs.chromium.org/p/chromium/issues/detail?id=568602

No.

 Issue 605586  has been merged into this issue.

Might have a repro in  issue 605586 ?

Hi guys,

I find out what was causing the crash: In the affected application injected a javascript object into the webview from native with the "addJavascriptInterface". This object had methods reachable from javascript with the following signature: 

@android.webkit.JavascriptInterface
public Map<String, WhateverObject> subscribe(String eventName).

The issue didn't happen anymore if the return is a "void" instead of a Map. Obviously the Map was not used in javascript, we had it for testing purposes, but for some reason from  webviews v48 and up, this is an issue.  

OK, that's definitely a webview bug - it shouldn't crash even if you're using types it can't deal with (I think the expected behaviour is that it calls toString on the object, but I actually can't find any documentation for this at all, which is kinda sad).

Can someone try to repro this with a little test app and fix it? :)

Something to take into consideration, that this is hard to reproduce. Just having something returning from the interface function is not enough. There has to be a lot of javascript logic. I managed to reproduce in some projects 100% of the times, but in others was not possible, or reproducible just 1 in 20 times. 

Ok. Are you able to share anything that has a reasonably good chance of reproducing the bug?

WontFix for inactivity. Please file a new bug if there's still something we should investigate.