WebglConformance conformance_extensions_webgl_draw_buffers flaky on Mac 10.10 Retina Debug (AMD) |
|||||||||||
Issue descriptionBuild is broken: webgl_conformance_tests on ATI GPU on Mac Retina on Mac-10.10 Revision range: chromium 389150 : 389153 Failing builders: Mac 10.10 Retina Debug (AMD): https://build.chromium.org/p/chromium.gpu/builders/Mac%2010.10%20Retina%20Debug%20(AMD) Flakes: https://build.chromium.org/p/chromium.gpu/builders/Mac%2010.10%20Retina%20Debug%20%28AMD%29/builds/6224 https://build.chromium.org/p/chromium.gpu/builders/Mac%2010.10%20Retina%20Debug%20%28AMD%29/builds/6233
,
Apr 22 2016
Here's the stack trace of the crash. It's happening in the Oilpan destructor of WebGLFramebuffer: Operating system: Mac OS X 10.10.5 14F1021 CPU: amd64 family 6 model 70 stepping 1 8 CPUs GPU: UNKNOWN Crash reason: EXC_BAD_ACCESS / KERN_INVALID_ADDRESS Crash address: 0x48 Process uptime: 108 seconds Thread 0 (crashed) 0 libblink_platform.dylib!__ZN5blink13DrawingBuffer9contextGLEv + 0x1e 1 libmodules.dylib!__ZNK5blink25WebGLRenderingContextBase9contextGLEv + 0x2b 2 libmodules.dylib!__ZNK5blink18WebGLContextObject15getAGLInterfaceEv + 0x32 3 libmodules.dylib!__ZN5blink11WebGLObject12deleteObjectEPN3gpu5gles214GLES2InterfaceE + 0x80 4 libmodules.dylib!__ZN5blink11WebGLObject21detachAndDeleteObjectEv + 0x37 5 libmodules.dylib!__ZN5blink16WebGLFramebufferD2Ev + 0x3f 6 libmodules.dylib!__ZN5blink16WebGLFramebufferD1Ev + 0x23 7 libmodules.dylib!__ZN5blink25GarbageCollectedFinalizedINS_11WebGLObjectEE30finalizeGarbageCollectedObjectEv + 0x27 8 libmodules.dylib!__ZN5blink18FinalizerTraitImplINS_11WebGLObjectELb1EE8finalizeEPv + 0x26 9 libmodules.dylib!__ZN5blink14FinalizerTraitINS_11WebGLObjectEE8finalizeEPv + 0x23 10 libblink_platform.dylib!__ZN5blink16HeapObjectHeader8finalizeEPhm + 0x6f 11 libblink_platform.dylib!__ZN5blink10NormalPage5sweepEv + 0x26c 12 libblink_platform.dylib!__ZN5blink9BaseArena16sweepUnsweptPageEv + 0x74 13 libblink_platform.dylib!__ZN5blink9BaseArena13completeSweepEv + 0x161 14 libblink_platform.dylib!__ZN5blink11ThreadState13completeSweepEv + 0x19b 15 libblink_platform.dylib!__ZN5blink15NormalPageArena17outOfLineAllocateEmm + 0x24f 16 libwebcore_shared.dylib!__ZN5blink15NormalPageArena14allocateObjectEmm + 0x1db 17 libwebcore_shared.dylib!__ZN5blink10ThreadHeap20allocateOnArenaIndexEPNS_11ThreadStateEmimPKc + 0xfc 18 libwebcore_shared.dylib!__ZN5blink4Node14allocateObjectEmb + 0x6f 19 libwebcore_shared.dylib!__ZN5blink8DocumentnwEm + 0x25 20 libwebcore_shared.dylib!__ZN5blink12HTMLDocument6createERKNS_12DocumentInitE + 0x29 21 libwebcore_shared.dylib!__ZN5blink17DOMImplementation14createDocumentERKN3WTF6StringERKNS_12DocumentInitEb + 0x6b 22 libwebcore_shared.dylib!__ZN5blink14LocalDOMWindow14createDocumentERKN3WTF6StringERKNS_12DocumentInitEb + 0xa9 23 libwebcore_shared.dylib!__ZN5blink14LocalDOMWindow18installNewDocumentERKN3WTF6StringERKNS_12DocumentInitEb + 0xca 24 libwebcore_shared.dylib!__ZN5blink14DocumentLoader15createWriterForERKNS_12DocumentInitERKN3WTF12AtomicStringES7_bNS_27ParserSynchronizationPolicyERKNS_4KURLE + 0x169 25 libwebcore_shared.dylib!__ZN5blink14DocumentLoader12ensureWriterERKN3WTF12AtomicStringERKNS_4KURLE + 0x369 26 libwebcore_shared.dylib!__ZN5blink14DocumentLoader10commitDataEPKcm + 0xbb 27 libwebcore_shared.dylib!__ZN5blink14DocumentLoader11processDataEPKcm + 0xc1 28 libwebcore_shared.dylib!__ZN5blink14DocumentLoader12dataReceivedEPNS_8ResourceEPKcm + 0x263 29 libwebcore_shared.dylib!__ZN5blink11RawResource10appendDataEPKcm + 0xaf 30 libwebcore_shared.dylib!__ZN5blink14ResourceLoader14didReceiveDataEPNS_12WebURLLoaderEPKcii + 0x1ae 31 libcontent.dylib!__ZN7content16WebURLLoaderImpl7Context14OnReceivedDataENSt3__110unique_ptrINS_11RequestPeer12ReceivedDataENS2_14default_deleteIS5_EEEE + 0x1c9 32 libcontent.dylib!__ZN7content16WebURLLoaderImpl15RequestPeerImpl14OnReceivedDataENSt3__110unique_ptrINS_11RequestPeer12ReceivedDataENS2_14default_deleteIS5_EEEE + 0x180 33 libcontent.dylib!__ZN7content18ResourceDispatcher14OnReceivedDataEiiii + 0x81f 34 libcontent.dylib!__ZN4base20DispatchToMethodImplIPN7content18ResourceDispatcherEMS2_FviiiiEJiiiiEJLm0ELm1ELm2ELm3EEEEvRKT_T0_RKNSt3__15tupleIJDpT1_EEENS_13IndexSequenceIJXspT2_EEEE + 0x154 35 libcontent.dylib!__ZN4base16DispatchToMethodIPN7content18ResourceDispatcherEMS2_FviiiiEJiiiiEEEvRKT_T0_RKNSt3__15tupleIJDpT1_EEE + 0x53 36 libcontent.dylib!__ZN3IPC16DispatchToMethodIN7content18ResourceDispatcherEMS2_FviiiiEvNSt3__15tupleIJiiiiEEEEEvPT_T0_PT1_RKT2_ + 0x5d 37 libcontent.dylib!__ZN3IPC8MessageTI29ResourceMsg_DataReceived_MetaNSt3__15tupleIJiiiiEEEvE8DispatchIN7content18ResourceDispatcherES8_vMS8_FviiiiEEEbPKNS_7MessageEPT_PT0_PT1_T2_ + 0x22c 38 libcontent.dylib!__ZN7content18ResourceDispatcher15DispatchMessageERKN3IPC7MessageE + 0x5c6 39 libcontent.dylib!__ZN7content18ResourceDispatcher17OnMessageReceivedERKN3IPC7MessageE + 0x370 40 libcontent.dylib!__ZN7content24ResourceSchedulingFilter15DispatchMessageERKN3IPC7MessageE + 0x48 41 libcontent.dylib!__ZN7content12_GLOBAL__N_119DispatchMessageTask3runEv + 0x65 42 libscheduler.dylib!__ZN9scheduler17WebTaskRunnerImpl7runTaskENSt3__110unique_ptrIN5blink13WebTaskRunner4TaskENS1_14default_deleteIS5_EEEE + 0x42 43 libscheduler.dylib!__ZN4base8internal15RunnableAdapterIPFvNSt3__110unique_ptrIN5blink13WebTaskRunner4TaskENS2_14default_deleteIS6_EEEEEE3RunIJS9_EEEvDpOT_ + 0x16d 44 libscheduler.dylib!__ZN4base8internal12InvokeHelperILb0EvNS0_15RunnableAdapterIPFvNSt3__110unique_ptrIN5blink13WebTaskRunner4TaskENS3_14default_deleteIS7_EEEEEEEE8MakeItSoIJSA_EEEvSD_DpOT_ + 0x36 45 libscheduler.dylib!__ZN4base8internal7InvokerINS_13IndexSequenceIJLm0EEEENS0_9BindStateINS0_15RunnableAdapterIPFvNSt3__110unique_ptrIN5blink13WebTaskRunner4TaskENS6_14default_deleteISA_EEEEEEESE_JNS0_13PassedWrapperISD_EEEEENS0_12InvokeHelperILb0EvSG_EEFvvEE3RunEPNS0_13BindStateBaseE + 0x7d 46 libbase.dylib!__ZNK4base8CallbackIFvvELNS_8internal8CopyModeE1EE3RunEv + 0x3f 47 libbase.dylib!__ZN4base5debug13TaskAnnotator7RunTaskEPKcRKNS_11PendingTaskE + 0x28e 48 libscheduler.dylib!__ZN9scheduler16TaskQueueManager24ProcessTaskFromWorkQueueEPNS_8internal9WorkQueueEPNS1_13TaskQueueImpl4TaskE + 0x635 49 libscheduler.dylib!__ZN9scheduler16TaskQueueManager6DoWorkEN4base9TimeTicksEb + 0x3e0 50 libscheduler.dylib!__ZN4base8internal15RunnableAdapterIMN9scheduler16TaskQueueManagerEFvNS_9TimeTicksEbEE3RunIJRKS4_RKbEEEvPS3_DpOT_ + 0xaa 51 libscheduler.dylib!__ZN4base8internal12InvokeHelperILb1EvNS0_15RunnableAdapterIMN9scheduler16TaskQueueManagerEFvNS_9TimeTicksEbEEEE8MakeItSoINS_7WeakPtrIS4_EEJRKS5_RKbEEEvS8_T_DpOT0_ + 0x6e 52 libscheduler.dylib!__ZN4base8internal7InvokerINS_13IndexSequenceIJLm0ELm1ELm2EEEENS0_9BindStateINS0_15RunnableAdapterIMN9scheduler16TaskQueueManagerEFvNS_9TimeTicksEbEEEFvPS7_S8_bEJNS_7WeakPtrIS7_EES8_bEEENS0_12InvokeHelperILb1EvSB_EEFvvEE3RunEPNS0_13BindStateBaseE + 0xbd 53 libbase.dylib!__ZNK4base8CallbackIFvvELNS_8internal8CopyModeE1EE3RunEv + 0x3f 54 libbase.dylib!__ZN4base5debug13TaskAnnotator7RunTaskEPKcRKNS_11PendingTaskE + 0x28e 55 libbase.dylib!__ZN4base11MessageLoop7RunTaskERKNS_11PendingTaskE + 0x36d 56 libbase.dylib!__ZN4base11MessageLoop21DeferOrRunPendingTaskERKNS_11PendingTaskE + 0x56 57 libbase.dylib!__ZN4base11MessageLoop6DoWorkEv + 0x228 58 libbase.dylib!__ZN4base24MessagePumpCFRunLoopBase7RunWorkEv + 0x68 59 libbase.dylib!____ZN4base24MessagePumpCFRunLoopBase13RunWorkSourceEPv_block_invoke + 0x2a 60 libbase.dylib!__ZN4base3mac15CallWithEHFrameEU13block_pointerFvvE + 0xa 61 libbase.dylib!__ZN4base24MessagePumpCFRunLoopBase13RunWorkSourceEPv + 0x65 62 CoreFoundation + 0x80a01 63 CoreFoundation + 0x72b8d 64 CoreFoundation + 0x721bf 65 CoreFoundation + 0x71bd8 66 Foundation + 0x90b29 67 libbase.dylib!__ZN4base20MessagePumpNSRunLoop5DoRunEPNS_11MessagePump8DelegateE + 0x97 68 libbase.dylib!__ZN4base24MessagePumpCFRunLoopBase3RunEPNS_11MessagePump8DelegateE + 0x7d 69 libbase.dylib!__ZN4base11MessageLoop10RunHandlerEv + 0x12a 70 libbase.dylib!__ZN4base7RunLoop3RunEv + 0x55 71 libbase.dylib!__ZN4base11MessageLoop3RunEv + 0x12f 72 libcontent.dylib!__ZN7content12RendererMainERKNS_18MainFunctionParamsE + 0x149b 73 libcontent.dylib!__ZN7content23RunNamedProcessTypeMainERKNSt3__112basic_stringIcNS0_11char_traitsIcEENS0_9allocatorIcEEEERKNS_18MainFunctionParamsEPNS_19ContentMainDelegateE + 0x257 74 libcontent.dylib!__ZN7content21ContentMainRunnerImpl3RunEv + 0x272 75 libcontent.dylib!__ZN7content11ContentMainERKNS_17ContentMainParamsE + 0x15d 76 libchrome_main_dll.dylib!_ChromeMain + 0x53 77 Chromium Helper!_main + 0x30f 78 Chromium Helper!start + 0x34 Kentaro, Sigbjorn, this is affecting the webgl_conformance_tests which are running on the commit queue. I'm raising this to P1. This is similar to Issue 603168 which affected only optional tests. Can I please ask that we focus on fixing this? I will hold on to this bug until the end of day today and will try to propose a fix.
,
Apr 22 2016
,
Apr 22 2016
,
Apr 22 2016
Note: I don't actually see this on the CQ: https://build.chromium.org/p/tryserver.chromium.mac/builders/mac_chromium_rel_ng?numbuilds=200 Only on the Mac Debug Retina (AMD) bots -- the new MacBook Pro Retinas with AMD GPU.
,
Apr 22 2016
,
Apr 22 2016
Good stuff, thanks for trapping that one. Does that mean the context is invalid or WebGLRenderingContextBase::m_drawingBuffer is null? It looks like |this| of DrawingBuffer::contextGL() is 0.
,
Apr 23 2016
I'm guessing that WebGLRenderingContextBase::m_drawingBuffer is null. It might be the case that recent refactorings to get rid of WebGraphicsContext3D may have made it so that WebGLRenderingContextBase::contextGL has to do a null-check against the DrawingBuffer. Actually, it looks like something unexpected also happened with the canvas rendering context classes recently. WebGLRenderingContext used to implement ActiveDOMObject so that when the document was navigated away from, it would eagerly destroy all of its GPU resources. That's why CanvasRenderingContext declares "virtual void stop() = 0;". However, CanvasRenderingContext doesn't inherit from ActiveDOMObject any more, probably due to the work to decouple it from HTMLCanvasElement. I don't remember whether it was using DocumentLifecycleListener -- vague recollection that it was. Anyway, there are two actions here: 1. Fix the null dereference. 2. Figure out the invariants during destruction and make sure that WebGLContextObject obeys them. 3. Figure out what is supposed to happen with eager termination of WebGLRenderingContext's GPU resources upon page navigation. Brandon, could you please drive this next Monday? It looks to me like WebGLRenderingContextBase::contextGL() really does need a null check, and that calling code is expecting that it might come back null. Separately, let's please work with xlai@ and xidachen@ to understand the recent loss of eager termination of WebGL contexts.
,
Apr 23 2016
Actually, I went ahead and uploaded https://codereview.chromium.org/1916663002/ to add the null check.
,
Apr 23 2016
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/1159e071d7d8b72a210cca6e6a916ef4434b5f00 commit 1159e071d7d8b72a210cca6e6a916ef4434b5f00 Author: kbr <kbr@chromium.org> Date: Sat Apr 23 22:53:03 2016 Add null check to WebGLRenderingContextBase::contextGL(). BUG= 605988 CQ_INCLUDE_TRYBOTS=tryserver.chromium.win:win_optional_gpu_tests_rel;tryserver.chromium.mac:mac_optional_gpu_tests_rel Review URL: https://codereview.chromium.org/1916663002 Cr-Commit-Position: refs/heads/master@{#389391} [modify] https://crrev.com/1159e071d7d8b72a210cca6e6a916ef4434b5f00/third_party/WebKit/Source/modules/webgl/WebGLRenderingContextBase.h
,
Apr 25 2016
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/1159e071d7d8b72a210cca6e6a916ef4434b5f00 commit 1159e071d7d8b72a210cca6e6a916ef4434b5f00 Author: kbr <kbr@chromium.org> Date: Sat Apr 23 22:53:03 2016 Add null check to WebGLRenderingContextBase::contextGL(). BUG= 605988 CQ_INCLUDE_TRYBOTS=tryserver.chromium.win:win_optional_gpu_tests_rel;tryserver.chromium.mac:mac_optional_gpu_tests_rel Review URL: https://codereview.chromium.org/1916663002 Cr-Commit-Position: refs/heads/master@{#389391} [modify] https://crrev.com/1159e071d7d8b72a210cca6e6a916ef4434b5f00/third_party/WebKit/Source/modules/webgl/WebGLRenderingContextBase.h
,
May 5 2016
What's the status on #8?
,
May 6 2016
I will look at #8.
,
May 6 2016
Thanks Xida. Sigbjorn, sorry for not responding yesterday but am swamped with other issues.
,
May 6 2016
Thanks; no worries, whenever there is time - just wondering if that null check is hiding something more fundamental.
,
May 9 2016
Per investigating to #8: we don't really have a regression on eager termination of WebGL contexts. At this moment, HTMLCanvasElement is in charge of eager release of graphics resources. This is implemented in "HTMLCanvasElement::pageVisibilityChanged()", such that when a page is hidden (e.g. switch to another tab), its associated graphics resources will be cleared. A new bug is filed here: https://bugs.chromium.org/p/chromium/issues/detail?id=610350 for the case of OffscreenCanvas.
,
Sep 29 2016
I'm calling this fixed. |
|||||||||||
►
Sign in to add a comment |
|||||||||||
Comment 1 by apaci...@chromium.org
, Apr 22 2016