MemoryInfra: gpu::MappedMemoryManager does not unregister on the right thread |
|||
Issue descriptionBackground context:go/memory-infra: memory profiling in chrome://tracing The dump provider must unregister on the task runner which was provider during RegisterDumpProvider call. The MappedMemoryManager is unregistered on a different thread. Failed build: https://build.chromium.org/p/tryserver.chromium.mac/builders/mac_chromium_rel_ng/builds/357552 https://luci-logdog.appspot.com/v/?s=chromium%2Fbb%2Ftryserver.chromium.mac%2Fmac_chromium_rel_ng%2F357552%2F%2B%2Frecipes%2Fsteps%2Fcc_unittests__with_patch_%2F0%2Flogs%2FPixelResourceTest_LayerTreeHostMasksPixelTest.MaskOfLayer_3%2F0 Stack trace: [ RUN ] LayerTreeHostBlendingPixelTest.BlendingWithRenderPassWithMask_GL [13226:13059:1219/175706.028795:4885670643376:FATAL:memory_dump_manager.cc(353)] Check failed: (*mdp_iter)->task_runner && (*mdp_iter)->task_runner->RunsTasksOnCurrentThread(). MemoryDumpProvider "gpu::MappedMemoryManager" attempted to unregister itself in a racy way. Please file a crbug. 0 cc_unittests 0x000000010fee1c53 _ZN4base5debug10StackTraceC1Ev + 19 1 cc_unittests 0x000000010feffdd7 _ZN7logging10LogMessageD2Ev + 71 2 cc_unittests 0x000000010ff9292a _ZN4base11trace_event17MemoryDumpManager30UnregisterDumpProviderInternalEPNS0_18MemoryDumpProviderEb + 490 3 cc_unittests 0x000000010fa39bfb _ZN3gpu19MappedMemoryManagerD0Ev + 43 4 cc_unittests 0x000000011097794d _ZN3gpu5gles219GLES2ImplementationD2Ev + 797 5 cc_unittests 0x0000000110977ebe _ZN3gpu5gles219GLES2ImplementationD0Ev + 14 6 cc_unittests 0x00000001109aa23c _ZN3gpu12_GLOBAL__N_122GLInProcessContextImplD1Ev + 60 7 cc_unittests 0x00000001109aa2fe _ZN3gpu12_GLOBAL__N_122GLInProcessContextImplD0Ev + 14 8 cc_unittests 0x000000010fd42490 _ZN2cc28TestInProcessContextProviderD2Ev + 112 9 cc_unittests 0x000000010fd424de _ZN2cc28TestInProcessContextProviderD0Ev + 14 10 cc_unittests 0x000000010fbd85a6 _ZN2cc19CompositorFrameSink16DetachFromClientEv + 358 11 cc_unittests 0x000000010fcb9fd0 _ZN2cc17LayerTreeHostImpl26ReleaseCompositorFrameSinkEv + 144 12 cc_unittests 0x000000010fcf18a6 _ZN2cc9ProxyImplD2Ev + 262 13 cc_unittests 0x000000010fcf1a3e _ZN2cc9ProxyImplD0Ev + 14 14 cc_unittests 0x000000010fcf72ad _ZN2cc9ProxyMain28DestroyProxyImplOnImplThreadEPNS_15CompletionEventE + 125 15 cc_unittests 0x000000010fee2371 _ZN4base5debug13TaskAnnotator7RunTaskEPKcPNS_11PendingTaskE + 225 16 cc_unittests 0x000000010ff115e9 _ZN4base11MessageLoop7RunTaskEPNS_11PendingTaskE + 425 17 cc_unittests 0x000000010ff119ac _ZN4base11MessageLoop21DeferOrRunPendingTaskENS_11PendingTaskE + 44 18 cc_unittests 0x000000010ff11ea3 _ZN4base11MessageLoop6DoWorkEv + 467 19 cc_unittests 0x000000010ff16ce0 _ZN4base24MessagePumpCFRunLoopBase7RunWorkEv + 48 20 cc_unittests 0x000000010ff00b8a _ZN4base3mac15CallWithEHFrameEU13block_pointerFvvE + 10 21 cc_unittests 0x000000010ff166b4 _ZN4base24MessagePumpCFRunLoopBase13RunWorkSourceEPv + 68 22 CoreFoundation 0x00007fff8f3a95b1 __CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE0_PERFORM_FUNCTION__ + 17 23 CoreFoundation 0x00007fff8f39ac62 __CFRunLoopDoSources0 + 242 24 CoreFoundation 0x00007fff8f39a3ef __CFRunLoopRun + 831 25 CoreFoundation 0x00007fff8f399e75 CFRunLoopRunSpecific + 309 26 cc_unittests 0x000000010ff171ef _ZN4base20MessagePumpCFRunLoop5DoRunEPNS_11MessagePump8DelegateE + 79 27 cc_unittests 0x000000010ff16b37 _ZN4base24MessagePumpCFRunLoopBase3RunEPNS_11MessagePump8DelegateE + 119 28 cc_unittests 0x000000010ff1132b _ZN4base11MessageLoop10RunHandlerEv + 363 29 cc_unittests 0x000000010ff418f9 _ZN4base7RunLoop3RunEv + 137 30 cc_unittests 0x000000010ff82fdd _ZN4base6Thread3RunEPNS_7RunLoopE + 205 31 cc_unittests 0x000000010ff83592 _ZN4base6Thread10ThreadMainEv + 930 32 cc_unittests 0x000000010ff794cf _ZN4base12_GLOBAL__N_110ThreadFuncEPv + 95 33 libsystem_pthread.dylib 0x00007fff95a47899 _pthread_body + 138 34 libsystem_pthread.dylib 0x00007fff95a4772a _pthread_struct_init + 0 35 libsystem_pthread.dylib 0x00007fff95a4bfc9 thread_start + 13
,
Dec 28 2016
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/4f2afdb2933744b91906b3b881aaeaf9b9523deb commit 4f2afdb2933744b91906b3b881aaeaf9b9523deb Author: ericrk <ericrk@chromium.org> Date: Wed Dec 28 20:10:19 2016 Dump MappedMemoryManager memory via GLES2Implementation Due to threading issues, we'd already changed several components of the GL command buffer to dump their memory heirarchically through a single registration point in ContextProviderCommandBuffer. MappedMemoryManager was missed. Modifying it so it doesn't register to dump directly, but is dumped through ContextProviderCommandBuffer > GLES2Implementation > MappedMemoryManager. R=ssid BUG= 675821 CQ_INCLUDE_TRYBOTS=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 Review-Url: https://codereview.chromium.org/2592803002 Cr-Commit-Position: refs/heads/master@{#440884} [modify] https://crrev.com/4f2afdb2933744b91906b3b881aaeaf9b9523deb/gpu/command_buffer/client/gles2_implementation.cc [modify] https://crrev.com/4f2afdb2933744b91906b3b881aaeaf9b9523deb/gpu/command_buffer/client/mapped_memory.cc [modify] https://crrev.com/4f2afdb2933744b91906b3b881aaeaf9b9523deb/gpu/command_buffer/client/mapped_memory.h
,
Dec 29 2016
,
Jan 4 2017
|
|||
►
Sign in to add a comment |
|||
Comment 1 by ericrk@chromium.org
, Dec 20 2016