Webview version 50.0.2661.86 and higher causing app to crash droid turbo 2 running OS 6.0
Reported by
qatest...@gmail.com,
Jun 13 2016
|
|||||||||||||||||||||||||||||||||
Issue descriptionDevice name:Droid Turbo 2 Android version: 6.0 WebView version (from system settings -> Apps -> Android System WebView): 50.0.2661.86 and higher Application: Black Book Digital Application version: 1.9 When our droid turbo 2 marshmallow 6.0 users updated their system webview to 50.0.2661.86 it caused our hybrid app to crash. We got a device and I was able to re-create and find a work around for these users. For the droid turbo 2 users that were having an issue we had to turn off hardware acceleration for our app. Out of thousands of users only the droid turbo 2 customers have this issue. If I uninstall updates the issue goes away. I tried on the latest release of webview and I'm still seeing the issue. Please let me know if more is needed from me. Thanks
,
Jun 13 2016
It is on the play store but requires an account to use it. We purchased a device for testing this issue. I will pull you a log cat and attach shortly.
,
Jun 13 2016
Can you provide us with a test account we can use to try to reproduce the issue? You can send it to me privately in email.
,
Jun 13 2016
Do you have a droid turbo 2 as well?
,
Jun 13 2016
I'm not sure, but we have a lot of devices available to our test teams ;) Even if not we may be able to find another device that has the same GPU and driver version which may also reproduce the issue (if it's a GPU driver bug it normally affects all devices with the same version).
,
Jun 13 2016
Do you still need log cat? I will set you up a test account.
,
Jun 13 2016
If you have the device available, giving us the logcat output would be very helpful, but if you can also give us a test account and details on how to reproduce it, that will be useful too.
,
Jun 13 2016
I sent you the credentials. The crash happens at different times but the steps below is one combination I have found that works consistently. To reproduce the error after logging in: 1. click on search 2. when the screen comes up click on the year drop down and select 2007 3. The screen will load the 2007 vehicle 4. click year again and choose 2017 and the app crashes
,
Jun 13 2016
This would be the qualcomm ref counting bug in driver in 6.0 again. But having a consistent repro would at least allow us to look into working around it.
GPU: OpenGL ES 3.1 V@139.0 (GIT@I8c58819290)
Qualcomm
Adreno (TM) 430
Crash reason:
Crash address: 0x0
Process uptime: not available
Thread 0 (crashed)
0 libGLESv2_adreno.so + 0x1d96e4
r0 = 0xf738c380 r1 = 0xf0b00010 r2 = 0xf0b00050 r3 = 0x00000ddf
r4 = 0xf3f49810 r5 = 0xf0b0003c r6 = 0xf3f49840 r7 = 0xef1404e4
r8 = 0xf3b9ae60 r9 = 0xf0b00080 r10 = 0x0c000000 r12 = 0x00000000
fp = 0x00000000 sp = 0xd82fef40 lr = 0xf5e66f9c pc = 0xe974b6e4
Found by: given as instruction pointer in context
1 libGLESv2_adreno.so + 0x373bbe
sp = 0xd82fef64 pc = 0xe98e5bc0
Found by: stack scanning
2 libGLESv2_adreno.so + 0x1d4527
sp = 0xd82fef70 pc = 0xe9746529
Found by: stack scanning
3 libwebviewchromium.so!gpu::gles2::GLES2DecoderImpl::MakeCurrent [gles2_cmd_decoder.cc : 3717 + 0x5]
sp = 0xd82fef80 pc = 0xe1746fab
Found by: stack scanning
4 libGLESv2_adreno.so + 0x145c63
r4 = 0xe96bebd7 r5 = 0xd82ff040 r6 = 0xe96bb38f r7 = 0x00000001
sp = 0xd82ff038 pc = 0xe96b7c65
Found by: call frame info
5 libEGL_adreno.so + 0x6b3f
sp = 0xd82ff03c pc = 0xe9a9cb41
Found by: stack scanning
6 libwebviewchromium.so!NativeImageBufferEGL::~NativeImageBufferEGL [texture_definition.cc : 204 + 0xd]
sp = 0xd82ff078 pc = 0xe1764f4d
Found by: stack scanning
7 libwebviewchromium.so!NativeImageBufferEGL::~NativeImageBufferEGL [texture_definition.cc : 205 + 0x3]
r4 = 0xdba06b30 r5 = 0xdba06b30 r6 = 0xdb4487d8 sp = 0xd82ff088
pc = 0xe1764fa9
Found by: call frame info
8 libwebviewchromium.so!GLImageSync::~GLImageSync [ref_counted.h : 193 + 0x5]
r4 = 0xf3f0d7b8 r5 = 0xdba06b30 r6 = 0xdb4487d8 sp = 0xd82ff090
pc = 0xe1765175
Found by: call frame info
9 libwebviewchromium.so!GLImageSync::~GLImageSync [texture_definition.cc : 78 + 0x3]
r3 = 0xe176517d r4 = 0xf3f0d7b8 r5 = 0xd4fd9c00 r6 = 0xdb4487d8
sp = 0xd82ff0a0 pc = 0xe1765185
Found by: call frame info
10 libwebviewchromium.so!gpu::gles2::Texture::LevelInfo::~LevelInfo [ref_counted.h : 134 + 0x5]
r4 = 0xd4fd9c00 r5 = 0xd4fd9c00 r6 = 0xdb4487d8 sp = 0xd82ff0a8
pc = 0xe1765d9f
Found by: call frame info
11 libwebviewchromium.so!gpu::gles2::Texture::FaceInfo::~FaceInfo [memory : 1700 + 0x3]
r4 = 0xd50fef40 r5 = 0xd4fd9c00 r6 = 0xdb4487d8 sp = 0xd82ff0b0
pc = 0xe1765e27
Found by: call frame info
12 libwebviewchromium.so!gpu::gles2::Texture::~Texture [memory : 1700 + 0x3]
r3 = 0x00000002 r4 = 0xda31ee40 r5 = 0xd50fef40 r6 = 0xdb4487d8
sp = 0xd82ff0c0 pc = 0xe1767ddd
Found by: call frame info
13 libwebviewchromium.so!gpu::gles2::Texture::RemoveTextureRef [texture_manager.cc : 405 + 0x5]
r4 = 0xdb4487f0 r5 = 0xdb4487f0 r6 = 0xdb4487d8 sp = 0xd82ff0d0
pc = 0xe176a6c3
Found by: call frame info
14 libwebviewchromium.so!gpu::gles2::TextureRef::~TextureRef [texture_manager.cc : 1645 + 0xd]
r4 = 0xdb4487d8 r5 = 0xdb4487d8 r6 = 0xf513ef20 r7 = 0x00000010
r9 = 0xd50fe8c0 sp = 0xd82ff0e8 pc = 0xe176a757
Found by: call frame info
15 libwebviewchromium.so!gpu::gles2::TextureManager::RemoveTexture [ref_counted.h : 134 + 0x5]
r4 = 0xd50fe900 r5 = 0xdb4487d8 r6 = 0xf513ef20 r7 = 0x00000010
r9 = 0xd50fe8c0 sp = 0xd82ff0f0 pc = 0xe176a991
Found by: call frame info
16 libwebviewchromium.so!gpu::gles2::GLES2DecoderImpl::DeleteTexturesHelper [gles2_cmd_decoder.cc : 838 + 0x7]
r4 = 0xdb4487d8 r5 = 0xf3e86700 r6 = 0xdb4f3664 r7 = 0x00000000
r8 = 0x00000001 r9 = 0x00000000 r10 = 0xf3e86774 fp = 0x000000ff
sp = 0xd82ff150 pc = 0xe1729565
Found by: call frame info
17 libwebviewchromium.so!gpu::gles2::GLES2DecoderImpl::HandleDeleteTexturesImmediate [gles2_cmd_decoder_autogen.h : 892 + 0x5]
r4 = 0x00000004 r5 = 0x00000000 r6 = 0x00000000 r7 = 0x00000001
r8 = 0x00000018 r9 = 0xf3e86700 r10 = 0x0000001b fp = 0x000000ff
sp = 0xd82ff170 pc = 0xe17295f9
Found by: call frame info
18 libwebviewchromium.so!gpu::gles2::GLES2DecoderImpl::DoCommandsImpl<false> [gles2_cmd_decoder.cc : 4511 + 0x3]
r4 = 0x00000003 r5 = 0x00000068 r6 = 0x00000134 r7 = 0xdb4f365c
r8 = 0x00000018 r9 = 0xf3e86700 r10 = 0x0000001b fp = 0x000000ff
sp = 0xd82ff198 pc = 0xe1745791
Found by: call frame info
19 libwebviewchromium.so!gpu::CommandParser::ProcessCommands [cmd_parser.cc : 54 + 0x9]
r4 = 0xf3f0d458 r5 = 0xe17465b1 r6 = 0x00000000 r7 = 0xdb4f0000
r8 = 0xf7138ec0 r9 = 0xd82ff2d0 r10 = 0xd82ff45c fp = 0xd82ff3d0
sp = 0xd82ff270 pc = 0xe1711477
Found by: call frame info
20 libwebviewchromium.so!gpu::CommandExecutor::PutChanged [command_executor.cc : 61 + 0x7]
r4 = 0xda337f40 r5 = 0x00000000 r6 = 0xcf43c7c6 r7 = 0x00000002
r8 = 0xf7138ec0 r9 = 0xd82ff2d0 r10 = 0xd82ff45c fp = 0xd82ff3d0
sp = 0xd82ff298 pc = 0xe1711de1
Found by: call frame info
21 libwebviewchromium.so!base::internal::Invoker<base::IndexSequence<0u>, base::internal::BindState<base::internal::RunnableAdapter<void (IPC::MojoBootstrap::*)()>, void(IPC::MojoBootstrap*), base::internal::UnretainedWrapper<IPC::(anonymous namespace)::MojoClientBootstrap> >, base::internal::InvokeHelper<false, void, base::internal::RunnableAdapter<void (IPC::MojoBootstrap::*)()> >, void()>::Run + 0x13
r4 = 0xf3f74400 r5 = 0xe331dc28 r6 = 0xe33afa90 r7 = 0xd82ff3e4
r8 = 0x00000000 r9 = 0x00000e7e r10 = 0xd82ff45c fp = 0xd82ff3d0
sp = 0xd82ff350 pc = 0xe13856af
Found by: call frame info
22 libwebviewchromium.so!gpu::GpuCommandBufferStub::OnAsyncFlush [gpu_command_buffer_stub.cc : 827 + 0x3]
r4 = 0xf3f74400 r5 = 0xe331dc28 r6 = 0xe33afa90 r7 = 0xd82ff3e4
r8 = 0x00000000 r9 = 0x00000e7e r10 = 0xd82ff45c fp = 0xd82ff3d0
sp = 0xd82ff360 pc = 0xe19103d5
Found by: call frame info
23 libwebviewchromium.so!IPC::MessageT<GpuCommandBufferMsg_AsyncFlush_Meta, std::__1::tuple<int, unsigned int, std::__1::vector<ui::LatencyInfo, std::__1::allocator<ui::LatencyInfo> > >, void>::Dispatch<gpu::GpuCommandBufferStub, gpu::GpuCommandBufferStub, void, void (gpu::GpuCommandBufferStub::*)(int, unsigned int, const std::__1::vector<ui::LatencyInfo>&)> [tuple.h : 166 + 0x7]
r4 = 0xe19102dd r5 = 0x00000001 r6 = 0xf3f74400 r7 = 0x00000001
r8 = 0xdb52cc50 r9 = 0xf7138ec0 r10 = 0xcccccce6 fp = 0xe2f540f4
sp = 0xd82ff420 pc = 0xe1910a21
Found by: call frame info
24 libwebviewchromium.so!gpu::GpuCommandBufferStub::OnMessageReceived [gpu_command_buffer_stub.cc : 304 + 0x11]
r4 = 0xdb52cc50 r5 = 0xf3f74400 r6 = 0xd82ff578 r7 = 0x00000001
r8 = 0xd82ff590 r9 = 0xf7138ec0 r10 = 0xcccccce6 fp = 0xe2f540f4
sp = 0xd82ff480 pc = 0xe1911a09
Found by: call frame info
25 libwebviewchromium.so!gpu::GpuChannel::HandleMessageHelper [gpu_channel.cc : 825 + 0x5]
r4 = 0xf3ef6300 r5 = 0xdb52cc50 r6 = 0xf3f74400 r7 = 0xf3ef6300
r8 = 0xf3e8bca8 r9 = 0x00000000 r10 = 0xcccccce6 fp = 0xe2f540f4
sp = 0xd82ff638 pc = 0xe190f065
Found by: call frame info
26 libwebviewchromium.so!gpu::GpuChannel::HandleMessage [gpu_channel.cc : 807 + 0x7]
r4 = 0xd4fbdcf8 r5 = 0xdb52cc50 r6 = 0xf3f74400 r7 = 0xf3ef6300
r8 = 0xf3e8bca8 r9 = 0x00000000 r10 = 0xcccccce6 fp = 0xe2f540f4
sp = 0xd82ff648 pc = 0xe190f0c9
Found by: call frame info
27 libwebviewchromium.so!base::internal::Invoker<base::IndexSequence<0u, 1u>, base::internal::BindState<base::internal::RunnableAdapter<bool (IPC::Listener::*)(const IPC::Message&)>, void(IPC::Listener*, const IPC::Message&), const base::WeakPtr<IPC::Listener>&, const IPC::Message&>, base::internal::InvokeHelper<true, void, base::internal::RunnableAdapter<bool (IPC::Listener::*)(const IPC::Message&)> >, void()>::Run [bind_internal.h : 181 + 0x3]
r4 = 0xd4fbdce8 r5 = 0xd82ff668 r6 = 0xd4fbdcf8 r7 = 0xe33afa6a
r8 = 0xf3e8bca8 r9 = 0x00000000 r10 = 0xcccccce6 fp = 0xe2f540f4
sp = 0xd82ff668 pc = 0xe18446f3
Found by: call frame info
28 libwebviewchromium.so!base::debug::TaskAnnotator::RunTask [callback.h : 397 + 0x5]
r4 = 0xd82ff810 r5 = 0xd82ff6f8 r6 = 0xd82ff6f0 r7 = 0xe33afa6a
r8 = 0xf3e8bca8 r9 = 0x00000000 r10 = 0xcccccce6 fp = 0xe2f540f4
sp = 0xd82ff688 pc = 0xe2afc117
Found by: call frame info
29 libwebviewchromium.so!base::MessageLoop::RunTask [message_loop.cc : 479 + 0xd]
r4 = 0xd82ff810 r5 = 0xf3e8bc00 r6 = 0xe33afa60 r7 = 0xe33af9e0
r8 = 0xe2dc6d14 r9 = 0xd82ff818 r10 = 0xcccccce6 fp = 0x0000004c
sp = 0xd82ff748 pc = 0xe2b08f89
Found by: call frame info
30 libwebviewchromium.so!base::MessageLoop::DeferOrRunPendingTask [message_loop.cc : 488 + 0x7]
r4 = 0xf3e8bc00 r5 = 0x00000001 r6 = 0xd82ff810 r7 = 0xf3e8bc0c
r8 = 0xd82ff820 r9 = 0xd82ff818 r10 = 0xcccccce6 fp = 0x0000004c
sp = 0xd82ff7f0 pc = 0xe2b0941f
Found by: call frame info
31 libwebviewchromium.so!base::MessageLoop::DoWork [message_loop.cc : 600 + 0x3]
r3 = 0x00000000 r4 = 0xf3e8bc00 r5 = 0xd82ff810 r6 = 0xc0c0c0c1
r7 = 0xf3e8bc0c r8 = 0xd82ff820 r9 = 0xd82ff818 r10 = 0xcccccce6
fp = 0x0000004c sp = 0xd82ff810 pc = 0xe2b096b1
Found by: call frame info
32 libwebviewchromium.so!base::MessagePumpDefault::Run [message_pump_default.cc : 33 + 0x7]
r4 = 0x00000000 r5 = 0xf3e8bc00 r6 = 0xcf43ade9 r7 = 0x00000002
r8 = 0xf3f94d78 r9 = 0xf3f94d88 r10 = 0xd8201000 fp = 0xe2b249f9
sp = 0xd82ff868 pc = 0xe2b0a42b
Found by: call frame info
33 libwebviewchromium.so!base::RunLoop::Run [run_loop.cc : 35 + 0x5]
r4 = 0xd82ff8c0 r5 = 0xd82ff89c r6 = 0xf3e8ad08 r7 = 0xf3e8bc00
r8 = 0xd9dc4980 r9 = 0xd9dc3efc r10 = 0xd8201000 fp = 0xe2b249f9
sp = 0xd82ff898 pc = 0xe2b15b2d
Found by: call frame info
34 libwebviewchromium.so!base::MessageLoop::Run [message_loop.cc : 295 + 0x5]
r4 = 0xf3e8ad00 r5 = 0xf7138ec0 r6 = 0xf3e8ad08 r7 = 0xf3e8bc00
r8 = 0xd9dc4980 r9 = 0xd9dc3efc r10 = 0xd8201000 fp = 0xe2b249f9
sp = 0xd82ff8c0 pc = 0xe2b08925
Found by: call frame info
35 libwebviewchromium.so!base::Thread::ThreadMain [thread.cc : 202 + 0x3]
r4 = 0xf3e8ad00 r5 = 0xf7138ec0 r6 = 0xf3e8ad08 r7 = 0xf3e8bc00
r8 = 0xd9dc4980 r9 = 0xd9dc3efc r10 = 0xd8201000 fp = 0xe2b249f9
sp = 0xd82ff8e0 pc = 0xe2b270f1
Found by: call frame info
36 libwebviewchromium.so!ThreadFunc [platform_thread_posix.cc : 70 + 0x7]
r4 = 0xd82ff930 r5 = 0xf3e8ad00 r6 = 0xf3e922d0 r7 = 0x00000078
r8 = 0xd9dc4980 r9 = 0xd9dc3efc r10 = 0xd8201000 fp = 0xe2b249f9
sp = 0xd82ff908 pc = 0xe2b24a2d
Found by: call frame info
37 libc.so + 0x3fc6b
r4 = 0xd82ff930 r5 = 0xd82ff970 r6 = 0xd82ff930 r7 = 0x00000078
r8 = 0xd9dc4980 r9 = 0xd9dc3efc r10 = 0xd8201000 fp = 0xe2b249f9
sp = 0xd82ff918 pc = 0xf70fec6d
Found by: call frame info
38 libc.so + 0x3fc4b
sp = 0xd82ff91c pc = 0xf70fec4d
Found by: stack scanning
39 libc.so + 0x3fc4b
sp = 0xd82ff924 pc = 0xf70fec4d
Found by: stack scanning
40 libc.so + 0x1a095
sp = 0xd82ff928 pc = 0xf70d9097
Found by: stack scanning
41 libwebviewchromium.so!base::PlatformThread::SetCurrentThreadPriority(base::ThreadPriority) + 0x22
sp = 0xd82ff964 pc = 0xe2b249f9
Found by: stack scanning
,
Jun 13 2016
Testing team is trying to repro on similar devices.
,
Jun 13 2016
I would be more than happy to test on this device as well if needed.
,
Jun 13 2016
qatest.rc@gmail.com: Did you send test account credentials to torne@chromium.org?
,
Jun 13 2016
Yes
,
Jun 13 2016
if you are trying our app on different devices there is a 6 minute delay when you close the app until you can login on another device.
,
Jun 13 2016
Trying to replicate the problem as per comment#8 with below configuration - but no luck. Device: Motorola Droid Turbo 2/XT1585 / Android build : 6.0.1/MCK24.183.-13 on Black Book : 1.9.0 web view version : 50.0.2661.86, 51.0.2704.77 and 51.0.2704.81 Tried 6/6 times on each webview version. qatest.rc@gmail.com, is there any setting needs to be set on the developer option to repro this issue? Thanks
,
Jun 13 2016
You would have to have 6.0 instead 6.0.1
,
Jun 13 2016
> You would have to have 6.0 instead 6.0.1 Hmm, seriously doubt motorola updated drivers in a minor update. dneelamegam: Can you open *chrome* on the device, go to chrome://gpu, and attach that page here?
,
Jun 13 2016
attached the chrome://gpu / Device information
,
Jun 13 2016
Huh, it does have a different sha1 from the microdump in comment #9
,
Jun 13 2016
dneelamegam: If you are sure it doesn't repro on the Droid Turbo 2 we have, next device to try would be n5x or n6p on any android M version
,
Jun 14 2016
boliu@, Tested on the below devices, Still no luck as per the Step to repro (with step mentioned in #8) Nexus 6P/Android : 6.0.0/MMB29N/ Webview : 50.0.2661.86 and :51.0.2704.81 Nexus 5X/ Android: 6.0.0/MDB08M/ Webview : 50.0.2661.86 and :51.0.2704.81 Sony XPERIA Z5(E6653)/ Android 6.0.0./Build : 32.1.A.1.163 : Webview : 50.0.2661.86 and :51.0.2704.81 Note:- On Sony Xperia Z5/ Crashed few time while try attempt to login, with different device when the user already added on other device (user id/pwd) where is it throws warning message (user Already sign in different device) for 5 times > And then Quit the apps (from recent apps) > Relaunching the apps , BlackBook continually crashing. Attached the logcat/bugreport/video of these crash not sure any thing to do with bug.
,
Jun 14 2016
Bo, what do you mean by "a different SHA1"? Do you mean the module ID of the GL driver? How did you get them to compare?
,
Jun 14 2016
Microdump from #9 has this gpu info: OpenGL ES 3.1 V@139.0 (GIT@I8c58819290)|Qualcomm|Adreno (TM) 430 If you look at the second screenshot in #19, the sha1 doesn't quite match although everything else does.
,
Jun 14 2016
Oh, so maybe they actually *did* update the driver in 6.0.1 and have fixed the bug, then? Wow. :)
,
Jun 14 2016
Well, not enough evidence to say that, since we didn't reproduce this crash on nexus devices either, and we know for sure on nexus devices that the driver bug exists on all M versions.
,
Jun 14 2016
Well only on driver versions that got shipped in Nexus devices on M versions. Other devices have their own forks of the driver that may have a fix cherrypicked in. But yes, we can't actually say that for sure :/
,
Jun 14 2016
I was able to repro this bug (on Moto droid turbo 2 with android 6.0.0)as per steps in comment#8 Device: Motorola Droid Turbo 2/XT1585 / Android build : 6.0.0/MCK24.78-13.12 on Black Book : 1.9.0 web view version : 50.0.2661.86 Attached is the logcat/bugreport/Video/ChromeGPU1/ChromeGPU2
,
Jun 16 2016
So that's both good and bad.. good: whatever the driver bug is, motorola seemed to have fixed it in 6.0.1 bad: since this doesn't repro on nexus devices, looks like this is a *different* bug from the known refcounting one. motoroloa seemed to have messed with debuggerd, so don't even see functions in libGLESv2_adreno.so and whatnot bad: we only have a user device, so can't do much debugging dneelamegam: can you bisect the release builds? report says this is new in m50, so can start between m49 and m50
,
Jun 16 2016
I'm a bit worried by this line in the bugreport: 06-14 17:55:36.858 13450 13526 E art : Nested signal detected - original signal being reported after the breakpad dump. This suggests that when we retrigger the signal in breakpad, it's going back through ART and ending up somewhere it shouldn't, instead of going to the debuggerd handler. This may be Motorola having changed something they shouldn't as you suggest, but it might potentially also be another issue on our end. We should probably investigate on this device to confirm why the signal handlers aren't chaining properly, independently of this bug (even if it's not our fault, we may be able to work around it). If debuggerd doesn't get notified, then the system crash dialog doesn't show up and therefore the user can't report the crash, so we wouldn't be observing these crashes on the breakpad server :( I can see if we have one of these devices in London sometime next week, but the device lab is currently packed away for our impending office move tomorrow, so I can't look into this now.
,
Jun 23 2016
@boliu, I went way back to M45(system webview) - below is my observation. Device: Motorola Droid Turbo 2/XT1585 / Android build : 6.0.0/MCK24.78-13.12 on Black Book : 1.9.0 Webview version: M45.0.2454.95 (system Image) - Not able to repro 46.0.2490.89 - not able to repro 47.0.2526.100 - not able to repro 48.0.2527.0 - First broken build - Issue is repro M48.0.2564.106 - issue is repro M49.0.2623.75 - Issue is repro M49.0.2623.91 - Issue is repro
,
Jul 4 2016
It seems a more fine-grained bisect would be useful here?
,
Jul 5 2016
Oh, never mind, that bisect shows the first broken build :)
,
Jul 21 2016
,
Jul 21 2016
We have the same issue in our app. At Ent Credit Union we have an app that uses a webview for some of our content. We had hardware acceleration enabled on the activity android:hardwareAccelerated="true". For almost all android devices we have no issues. However, we discovered that for the Droid Turbo 2, the webview intermittently crashes, and crashes our entire app. The device type and OS with an issue are: DeviceOS : 6.0 SDK 23 DeviceType : motorola XT1585 kinzie_verizon If we set android:hardwareAccelerated="false" this device no longer crashes. It appears to be some fault with a driver used for Adreno GSL. I'm attached some logs and crash reports.
,
Jul 21 2016
This might also be an issue on the device LG G4. We have see similar crashes in the google console with this device(although it is much less frequent than the turbo 2). However, we don't have one of these devices to test with, so we can't confirm it.
,
Jul 28 2016
Hm, this device isn't available in the UK it seems (verizon only)? and in any case we don't have one in the device test lab. Mountain view folk, do any of you have access to one of these? I'm still curious to test the signal handling behaviour to see if it's really broken and failing to generate breakpad reports :/
,
Jul 28 2016
satya do we have this device?
,
Jul 28 2016
sgurun@ yes we ordered 1 device similar to #37 with L(we can get M update on this). Thanks!
,
Jul 28 2016
yeah we have the device, and now a debug build, but I don't have time to investigate I mean motorola already fixed it, so could just wait until all users to upgrade and this will go away
,
Jul 29 2016
I'm not particularly concerned about the driver bug, I want to see if the device is really swallowing SIGSEGV and not generating feedback reports. If that's actually happening then it may still happen even when the driver bug is fixed, to other crashes.
,
Aug 19 2016
Just wondering what the status of this issue is. We released a new version of our app where we disabled hardware acceleration on the webview to work around this. A side effect of this is we can't use you tube videos in our webview content any more because they don't work in the webview without hardware acceleration on. We had to do it because we were getting hammered on our reviews by turbo 2 users that our app stunk because it crashed all the time. Telling them it's a driver problem on their phone just infuriates them more. I'm not sure why, but it doesn't seem like driver updates like this are automatically pushed out to phones. Webview updates on the other hand do seem to get pushed out. It would be great if a new version of the webview gracefully handled this fault rather than crashing the entire app.
,
Aug 19 2016
Drivers aren't updated without full OS updates, so unless people update their phones to 6.0.1 (which appears to have a fixed driver) it will be broken forever. Occasionally it's possible for us to work around issues with broken drivers on the webview side, but in general this can't be done easily - it requires the GPU vendor to be able to tell us *exactly* what the bug in their driver is and suggest a way for us to work around it, which requires a large investment of time/effort both on our part and on theirs. In this case, we can't even get basic debugging information about this crash to send to the GPU vendor because it looks like something *else* weird is going on on this device preventing the normal debug code from working correctly (as I mentioned in #43 and other comments) - I'm still intending to try to look into that and see if it's a fixable problem or not, but it appears to be specific to this device so unfortunately is likely to be an error on the device manufacturer's part, and may not be fixable. So, yes, we understand that this is really hard for you to do anything about, but it's also really hard for *us* to do anything about. If we knew how to work around it, we would have done so.
,
Aug 30 2016
Thanks for the explanation. It helps to know that a work around in the webview isn't really possible in this case. We'll find a way to work around it on our end. We appreciate the time you spent looking into this.
,
Aug 31 2016
Test team, if we have this device now, can we check if there's *any* reproducible native crash happening under any circumstances (doesn't have to be this specific GPU issue, but it would be good to try to repro that), and if so, whether we get "normal" crash log output?
,
Oct 4 2016
I did quick sanity on Droid Turbo 2/6.0 on latest M54 web view first party and third party apps (Baidu, twitter, facebook,Overdrive,cnn,theblaze), don't see issues or crash observed.We will continue testing this device, if we come across any issue will update this bug. Note:- I tried to check on Black Book apps, I'm getting subscription expire message (with user id and password the reporter shared with us) so I was not able to test.
,
Oct 4 2016
,
Oct 4 2016
what was the username I gave you? I will fix the account.
,
Oct 4 2016
Never mind I found it. It will be fixed so you can use it in the next 5 min.
,
Oct 4 2016
I updated the account so it should work for you now. The last device that tried to use it had OS 7.1 instead of 6.0
,
Oct 5 2016
There is no Android 7.1 (yet). Are you maybe confusing android OS versions with the version of motorola's customised UI? (vendors don't make this very clear)
,
Oct 5 2016
No. On 10/3 a nexus 6 running 7.1 OS tried to access BBDigital with that username. 560 pixels per inch height 2392 width 1440. It wasn't customized UI. We grab the OS version from the device info on login.
,
Oct 5 2016
Not a problem though. I just wanted to be sure the person hitting it knew the OS version wasn't 6.0
,
Apr 4 2017
Set correct status
,
Sep 17
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@
,
Sep 29
Crash analysis has not encountered any reports for this bug for the past 90 days. Hence as per the comment 11 days ago, we are closing the bug and setting the status to WontFix. If you have any feedback on this feature, please contact pranavk@ |
|||||||||||||||||||||||||||||||||
►
Sign in to add a comment |
|||||||||||||||||||||||||||||||||
Comment 1 by torne@chromium.org
, Jun 13 2016