Closed Bug 1745087 Opened 4 years ago Closed 1 year ago

Crashes in compositor thread with SCCompileShader in proto signature (AMD graphics), on WebGL

Categories

(Core :: Graphics: CanvasWebGL, defect, P2)

Unspecified
macOS
defect

Tracking

()

RESOLVED WORKSFORME

People

(Reporter: smichaud, Unassigned)

Details

Crash Data

These happen in various Firefox versions, on various versions of macOS, on AMD graphics hardware, on WebGL, usually in the Compositor thread:

https://crash-stats.mozilla.org/search/?proto_signature=~SCCompileShader&platform=Mac%20OS%20X&date=%3E%3D2021-06-08T23%3A46%3A00.000Z&date=%3C2021-12-08T23%3A46%3A00.000Z&_facets=signature&_facets=platform_version&_facets=proto_signature&_facets=version&_sort=-date&_columns=date&_columns=signature&_columns=product&_columns=version&_columns=build_id&_columns=platform#facet-signature

Typical recent example:

    Crashing Thread (40), Name: Compositor
    Frame  Module  Signature  Source  Trust
    0  libSC.dylib  SCRegAlloc::Postprocess()   context
    1  libSC.dylib  SCRegAlloc::AllocateRegisters()   cfi
    2  libSC.dylib  CompilerBase::GenerateCodeUsingNewIR(void*, bool)   cfi
    3  libSC.dylib  Compiler::Compile(ILProgram*)   cfi
    4  libSC.dylib  Compiler::CompileShader(unsigned char*, unsigned char*, unsigned int const*)   cfi
    5  libSC.dylib  SCCompileShader   cfi
    6  AMDRadeonX6000GLDriver  glrAMD_GFX10_SCCompileHwPixelShader   cfi
    7  AMDRadeonX6000GLDriver  glrAMD_Hwl_CompileFragmentShader   cfi
    8  AMDRadeonX6000GLDriver  glrUpdateCtxSysFragmentProgram   cfi
    9  AMDRadeonX6000GLDriver  gpusLoadCurrentPipelinePrograms   cfi
    10  AMDRadeonX6000GLDriver  gldUpdateDispatch   cfi
    11  GLEngine  gleDoDrawDispatchCoreGL3   cfi
    12  GLEngine  glDrawArraysInstanced_STD_GL3Exec   cfi
    13  GLEngine  glDrawArrays_UnpackThread   cfi
    14  GLEngine  gleCmdProcessor   cfi
    15  libdispatch.dylib  _dispatch_client_callout   cfi
    16  libdispatch.dylib  _dispatch_lane_barrier_sync_invoke_and_complete   cfi
    17  GLEngine  glGenTextures_ExecThread   cfi
    18  XUL  mozilla::gl::SharedSurface_IOSurface::Create(mozilla::gl::SharedSurfaceDesc const&)  gfx/gl/SharedSurfaceIO.cpp:63  cfi
    19  XUL  mozilla::gl::SurfaceFactory_IOSurface::CreateSharedImpl(mozilla::gl::SharedSurfaceDesc const&)  gfx/gl/SharedSurfaceIO.h:56  cfi
    20  XUL  mozilla::gl::SurfaceFactory::CreateShared(mozilla::gfx::IntSizeTyped<mozilla::gfx::UnknownUnits> const&)  gfx/gl/SharedSurface.h:166  cfi
    21  XUL  mozilla::gl::SwapChain::Acquire(mozilla::gfx::IntSizeTyped<mozilla::gfx::UnknownUnits> const&)  gfx/gl/GLScreenBuffer.cpp:41  cfi
    22  XUL  mozilla::WebGLContext::PresentInto(mozilla::gl::SwapChain&)  dom/canvas/WebGLContext.cpp:839  cfi
    23  XUL  mozilla::WebGLContext::Present(mozilla::WebGLFramebuffer*, mozilla::layers::TextureType, bool)  dom/canvas/WebGLContext.cpp:939  cfi
    24  XUL  mozilla::HostWebGLContext::Present(unsigned long long, mozilla::layers::TextureType, bool) const  dom/canvas/HostWebGLContext.h:173  cfi
    25  XUL  auto bool mozilla::MethodDispatcher<mozilla::WebGLMethodDispatcher, (unsigned long)51, void (mozilla::HostWebGLContext::*)(unsigned long long, mozilla::layers::TextureType const, bool), &mozilla::HostWebGLContext(unsigned long long, mozilla::layers::TextureType, bool)::Present const>::DispatchCommand<mozilla::HostWebGLContext>(mozilla::HostWebGLContext&, unsigned long, mozilla::webgl::RangeConsumerView&)::{lambda(auto:1&...)#1}::operator()<unsigned long long, mozilla::layers::TextureType, bool>(unsigned long long, mozilla::layers::TextureType&, bool) const  dom/canvas/WebGLCommandQueue.h:248  cfi
    26  XUL  mozilla::dom::WebGLParent::RecvDispatchCommands(mozilla::ipc::Shmem&&, unsigned long long)  dom/canvas/WebGLParent.cpp:59  cfi
    27  XUL  mozilla::dom::PWebGLParent::OnMessageReceived(IPC::Message const&)  ipc/ipdl/PWebGLParent.cpp:222  cfi
    28  XUL  mozilla::layers::PCompositorManagerParent::OnMessageReceived(IPC::Message const&)  ipc/ipdl/PCompositorManagerParent.cpp:195  cfi
    29  XUL  mozilla::ipc::MessageChannel::DispatchMessage(IPC::Message&&)  ipc/glue/MessageChannel.cpp:1968  cfi
    30  XUL  mozilla::ipc::MessageChannel::MessageTask::Run()  ipc/glue/MessageChannel.cpp:1855  cfi
    31  XUL  nsThread::ProcessNextEvent(bool, bool*)  xpcom/threads/nsThread.cpp:1142  cfi
    32  XUL  mozilla::ipc::MessagePumpForNonMainThreads::Run(base::MessagePump::Delegate*)  ipc/glue/MessagePump.cpp:330  cfi
    33  XUL  MessageLoop::Run()  ipc/chromium/src/base/message_loop.cc:306  cfi
    34  XUL  nsThread::ThreadFunc(void*)  xpcom/threads/nsThread.cpp:390  cfi
    35  libnss3.dylib  _pt_root  nsprpub/pr/src/pthreads/ptthread.c:201  cfi
    36  libsystem_pthread.dylib  _pthread_start   cfi
    37  libsystem_pthread.dylib  thread_start   cfi
Crash Signature: [@ SCRegAlloc::Postprocess ] [@ RegAllocationStatus::ReleaseRangeColor ] [@ SCRegAlloc::Coalesce ] [@ SC_SCCGCM::ComputeEarlyPosition ]

The severity field is not set for this bug.
:jgilbert, could you have a look please?

For more information, please visit auto_nag documentation.

Flags: needinfo?(jgilbert)

Woow, ok, so basically it's crashing during deferred pipeline/shader (re)compilation.
We need a repro case to make progress.

Severity: -- → S4
Flags: needinfo?(jgilbert)
Priority: -- → P2

There are a variety of urls in the crash reports. Annoyingly, it's not just crashing at a single spot, but instead it seems to be distributed, which sounds like a really spooky race condition in Apple's graphics drivers here.

Closing because no crashes reported for 12 weeks.

Status: NEW → RESOLVED
Closed: 1 year ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.