Crash in gpu::CommandBufferProxyImpl::CreateTransferBuffer(unsigned int, int*) |
||||
Issue descriptionChrome Version: 64.0.3243.0 OS: Android What steps will reproduce the problem? (1) visit https://websightjs.com (2) click "Image Demo" (3) click "Choose File" and choose a file What is the expected result? No crash What happens instead? The page crashes a short time after returning from "Choose File". I got to this issue with a different bug: crbug.com/766666 I was able to reproduce the issue with the canary chrome version 64.0.3243.0. The crash report should be crash/3cd71bc6d27393a8 I also able to reproduce the crash with a custom debug build of chrome on my Nexus 6, I attached the tombstone output. Here are my GN args: target_os = "android" use_goma = true enable_nacl = false is_component_build = true is_debug = true symbol_level = 2 use_goma = true v8_enable_backtrace = true v8_enable_disassembler = true v8_enable_verify_heap = true v8_optimized_debug = false I was also able to reproduce the crash with a release build. I was never able to reproduce the issue with any other phone, but I was able to reproduce it with different versions of Android.
,
Oct 20 2017
Danakj@ may have been working in this code.
,
Oct 20 2017
The tombstone looks like a dcheck failure: I 366.776s Main 000a6e79 logging::LogMessage::~LogMessage()+600 /usr/local/google/home/ahaas/src/chromium2/src/base/logging.cc:846 I 366.776s Main 0010aecb gpu::CommandBufferProxyImpl::Send(IPC::Message*)+106 /usr/local/google/home/ahaas/src/chromium2/src/gpu/ipc/client/command_buffer_proxy_impl.cc:686 I 366.776s Main 0010b4f3 gpu::CommandBufferProxyImpl::CreateTransferBuffer(unsigned int, int*)+218 /usr/local/google/home/ahaas/src/chromium2/src/gpu/ipc/client/command_buffer_proxy_impl.cc:425 I 366.776s Main 0007e739 gpu::TransferBuffer::AllocateRingBuffer(unsigned int)+40 /usr/local/google/home/ahaas/src/chromium2/src/gpu/command_buffer/client/transfer_buffer.cc:116 I 366.776s Main 0007e82d gpu::TransferBuffer::AllocUpTo(unsigned int, unsigned int*)+48 /usr/local/google/home/ahaas/src/chromium2/src/gpu/command_buffer/client/transfer_buffer.cc:160 I 366.776s Main 0007e929 gpu::ScopedTransferBufferPtr::Reset(unsigned int)+20 /usr/local/google/home/ahaas/src/chromium2/src/gpu/command_buffer/client/transfer_buffer.cc:234 I 366.776s Main 00026aa1 gpu::ScopedTransferBufferPtr::ScopedTransferBufferPtr(unsigned int, gpu::CommandBufferHelper*, gpu::TransferBufferInterface*)+16 /usr/local/google/home/ahaas/src/chromium2/src/gpu/command_buffer/client/transfer_buffer.h:165 I 366.776s Main 0002bee5 gpu::gles2::GLES2Implementation::TexImage2D(unsigned int, int, int, int, int, int, unsigned int, unsigned int, void const*)+820 /usr/local/google/home/ahaas/src/chromium2/src/gpu/command_buffer/client/gles2_implementation.cc:2685 This might be my change last week to make CreateTransferBuffer still run when context is lost? The Send() that is running only runs when !disconnected_ though, so it should not be after a loss. I *think* the DCHECK that is failing (line numbers dont match TOT exactly) in Send() is: DCHECK_EQ(gpu::error::kNoError, last_state_.error)
,
Oct 20 2017
Makes sense. I think we can remove that DCHECK.
,
Oct 20 2017
ftr I'm not able to view crbug.com/766666 to comment about that bug. > Makes sense. I think we can remove that DCHECK. I think the CreateTransferBuffer() branch should be on error state rather than disconnected_, which requires a post task to run. That's what the early out used to be, and is in other functions that Send().
,
Oct 20 2017
We can do that too. I want to remove the client-side early outs, which are mostly redundant (just let it fail on the IO thread), but that's something that can be done separately.
,
Oct 20 2017
Ah. My worry is there is a crash on canary which shouldnt be a dcheck. but the crash report at crash/3cd71bc6d27393a8 is not useful so i am not sure what to make of that atm.
,
Oct 20 2017
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/cbfdfc87b0e73e3aec7e9f6e9ff1ac69fdc837bd commit cbfdfc87b0e73e3aec7e9f6e9ff1ac69fdc837bd Author: danakj <danakj@chromium.org> Date: Fri Oct 20 22:49:03 2017 CreateTransferBuffer shouldn't Send() when the command buffer has error Previously this function would early out in that case. Now it does work but doesn't Send() to the service side. But it avoids the Send() if the error callback has run, which requires a post task. Instead it should check the error status like it used to. R=piman@chromium.org Bug: 775982 Cq-Include-Trybots: master.tryserver.chromium.android:android_optional_gpu_tests_rel;master.tryserver.chromium.linux:linux_optional_gpu_tests_rel;master.tryserver.chromium.mac:mac_optional_gpu_tests_rel;master.tryserver.chromium.win:win_optional_gpu_tests_rel Change-Id: Ib46cf4cfd8a5ff65136cac2e414f23f48460469e Reviewed-on: https://chromium-review.googlesource.com/730847 Reviewed-by: Antoine Labour <piman@chromium.org> Commit-Queue: danakj <danakj@chromium.org> Cr-Commit-Position: refs/heads/master@{#510593} [modify] https://crrev.com/cbfdfc87b0e73e3aec7e9f6e9ff1ac69fdc837bd/gpu/ipc/client/command_buffer_proxy_impl.cc [modify] https://crrev.com/cbfdfc87b0e73e3aec7e9f6e9ff1ac69fdc837bd/gpu/ipc/client/gpu_channel_host.cc
,
Oct 24 2017
I can still reproduce the crash on my phone with Canary 64.0.3247.0, which already contains the CL referenced in Comment 8, see crash/484b9dbf14fad177. Indeed the tombstone crashes at a DCHECK because I created it with a debug build.
,
Oct 24 2017
That crash stack is also not correct, it looks like 0xaf212e30 (libc.so + 0x00049e30 ) 0xaf1e6637 (libc.so + 0x0001d637 ) 0xaf1e2183 (libc.so + 0x00019183 ) 0x3d675d4b (dalvik-main space 1 (deleted) + 0x0aa75d4b ) 0xaf1e004a (libc.so + 0x0001704a ) 0x90f9779b (base.apk + 0x00f9279b ) 0x90f97781 (base.apk + 0x00f92781 ) 0x908a4341 (base.apk + 0x0089f341 ) 0x00fffffe (ashmem (deleted) + 0x00783ffe ) 0x726f6d63 (boot-framework.oat + 0x00387d63 ) Do you have a stack trace for the DCHECK failure? It can't be the same DCHECK that I thought it was as we literally don't call the function in that case.
,
Oct 24 2017
I 914.013s Main 0010753b base::(anonymous namespace)::OnNoMemory()+50 /usr/local/google/home/ahaas/src/chromium2/src/base/process/memory_linux.cc:39 I 914.013s Main 00104963 (anonymous namespace)::CallNewHandler(unsigned int)+74 /usr/local/google/home/ahaas/src/chromium2/src/base/allocator/allocator_shim.cc:77 I 914.013s Main 001047f5 ShimMalloc+32 /usr/local/google/home/ahaas/src/chromium2/src/base/allocator/allocator_shim.cc:196 I 914.013s Main 00064167 sk_malloc_throw(unsigned int)+4 /usr/local/google/home/ahaas/src/chromium2/src/skia/ext/SkMemory_new_handler.cpp:64 I 914.013s Main 0023210b SkAutoSMalloc<16384u>::reset(unsigned int, SkAutoMalloc::OnShrink, bool*)+90 /usr/local/google/home/ahaas/src/chromium2/src/third_party/skia/src/core/SkAutoMalloc.h:147 I 914.013s Main 002311d9 GrGLGpu::uploadTexData(GrPixelConfig, int, int, GrSurfaceOrigin, unsigned int, GrGLGpu::UploadType, int, int, int, int, GrPixelConfig, GrMipLevel const*, int, GrMipMapsStatus*)+752 /usr/local/google/home/ahaas/src/chromium2/src/third_party/skia/src/gpu/gl/GrGLGpu.cpp:1114 I 914.013s Main 00232ab9 GrGLGpu::createTextureImpl(GrSurfaceDesc const&, GrGLTextureInfo*, bool, GrGLTexture::TexParams*, GrMipLevel const*, int, GrMipMapsStatus*)+624 /usr/local/google/home/ahaas/src/chromium2/src/third_party/skia/src/gpu/gl/GrGLGpu.cpp:1644 I 914.013s Main 00232483 GrGLGpu::onCreateTexture(GrSurfaceDesc const&, SkBudgeted, GrMipLevel const*, int)+186 /usr/local/google/home/ahaas/src/chromium2/src/third_party/skia/src/gpu/gl/GrGLGpu.cpp:1431 I 914.013s Main 001ad98b GrGpu::createTexture(GrSurfaceDesc const&, SkBudgeted You're hitting out of memory, at which point malloc will crash.
,
Oct 24 2017
I think to look at that further, you should file a separate bug as the Send() issue should be addressed now. Here's docs on recording memory traces to see where memory is going which is a good place to start: https://chromium.googlesource.com/chromium/src/+/master/docs/memory-infra/README.md |
||||
►
Sign in to add a comment |
||||
Comment 1 by ahaas@chromium.org
, Oct 18 2017