Bug#943563: chromium crash when trying to check error status after invalidateing framebuffer in WebGL
Package: chromium Followup-For: Bug #943563 Looks to be fixed in chromium 79. I can't reproduce it now on the same hardware, but with Mesa 19.3.2 (I was testing with Mesa 19.2.1 previously). In fact the framebuffer invalidation tests all pass now, and no crashes either. There are some other issues with WebGL conformance test, including some serious regressions, but that should be filled as a separate bug. -- System Information: Debian Release: bullseye/sid APT prefers testing-debug APT policy: (500, 'testing-debug'), (500, 'unstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.2.0-3-amd64 (SMP w/32 CPU cores) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages chromium depends on: ii chromium-common 79.0.3945.130-2 ii libasound2 1.2.1.2-2 ii libatk-bridge2.0-0 2.34.1-2 ii libatk1.0-0 2.34.1-1 ii libatomic1 9.2.1-24 ii libatspi2.0-02.34.0-3 ii libavcodec58 7:4.2.1-2+b1 ii libavformat587:4.2.1-2+b1 ii libavutil56 7:4.2.1-2+b1 ii libc62.29-9 ii libcairo-gobject21.16.0-4 ii libcairo21.16.0-4 ii libcups2 2.3.1-1 ii libdbus-1-3 1.12.16-2 ii libdrm2 2.4.100-4 ii libevent-2.1-7 2.1.11-stable-1 ii libexpat12.2.9-1 ii libflac8 1.3.3-1 ii libfontconfig1 2.13.1-2+b1 ii libfreetype6 2.10.1-2 ii libgcc1 1:9.2.1-24 ii libgdk-pixbuf2.0-0 2.40.0+dfsg-2 ii libglib2.0-0 2.62.4-1+b1 ii libgtk-3-0 3.24.13-1 ii libharfbuzz0b2.6.4-1 ii libicu63 63.2-2 ii libjpeg62-turbo 1:1.5.2-2+b1 ii libjsoncpp1 1.7.4-3+b1 ii liblcms2-2 2.9-4 ii libminizip1 1.1-8+b1 ii libnspr4 2:4.24-1 ii libnss3 2:3.49-1 ii libopenjp2-7 2.3.1-1 ii libopus0 1.3-1+b1 ii libpango-1.0-0 1.42.4-8 ii libpangocairo-1.0-0 1.42.4-8 ii libpci3 1:3.6.2-6 ii libpng16-16 1.6.37-1 ii libpulse013.0-3 ii libre2-5 20200101+dfsg-1 ii libsnappy1v5 1.1.7-2 ii libstdc++6 9.2.1-24 ii libva2 2.6.1-1 ii libvpx6 1.8.2-1 ii libwebp6 0.6.1-2+b1 ii libwebpdemux20.6.1-2+b1 ii libwebpmux3 0.6.1-2+b1 ii libx11-6 2:1.6.8-1 ii libx11-xcb1 2:1.6.8-1 ii libxcb1 1.13.1-3 ii libxcomposite1 1:0.4.4-2 ii libxcursor1 1:1.2.0-2 ii libxdamage1 1:1.1.5-1 ii libxext6 2:1.3.3-1+b2 ii libxfixes3 1:5.0.3-1 ii libxi6 2:1.7.9-1 ii libxml2 2.9.4+dfsg1-8 ii libxrandr2 2:1.5.1-1 ii libxrender1 1:0.9.10-1 ii libxslt1.1 1.1.32-2.2 ii libxss1 1:1.2.3-1 ii libxtst6 2:1.2.3-1 ii zlib1g 1:1.2.11.dfsg-1+b1 Versions of packages chromium recommends: ii chromium-sandbox 79.0.3945.130-2 Versions of packages chromium suggests: pn chromium-driver ii chromium-l10n79.0.3945.130-2 pn chromium-shell Versions of packages chromium-common depends on: ii x11-utils 7.7+4 ii xdg-utils 1.1.3-1 Versions of packages chromium-common recommends: ii chromium-sandbox79.0.3945.130-2 ii fonts-liberation1:1.07.4-10 ii libgl1-mesa-dri 19.3.2-1 ii libu2f-udev 1.1.10-1 ii mate-notification-daemon [notification-daemon] 1.22.1-1 ii notification-daemon 3.20.0-4 ii system-config-printer 1.5.12-1 ii upower 0.99.11-1 Versions of packages chromium-sandbox depends on: ii libatomic1 9.2.1-24 ii libc6 2.29-9 ii libgcc1 1:9.2.1-24 ii libstdc++6 9.2.1-24 -- no debconf information
Bug#943563: chromium crash when trying to check error status after invalidateing framebuffer in WebGL
Package: chromium Version: 78.0.3904.97-1+b1 Followup-For: Bug #943563 Tested with newer chromium from unstable. This is with mesa from Debian testing and debug symbols enabled: Thread 20 "Chrome_InProcGp" received signal SIGSEGV, Segmentation fault. [Switching to Thread 0x7fffb27fc700 (LWP 68141)] 0x7fff8a8d9337 in st_discard_framebuffer (ctx=0x7fff9809e4a0, fb=0x7fff992e59d0, att=) at ../src/mesa/state_tracker/st_cb_fbo.h:79 79 ../src/mesa/state_tracker/st_cb_fbo.h: No such file or directory. (gdb) bt #0 0x7fff8a8d9337 in st_discard_framebuffer (ctx=0x7fff9809e4a0, fb=0x7fff992e59d0, att=) at ../src/mesa/state_tracker/st_cb_fbo.h:79 #1 0x7fff8a775b29 in discard_framebuffer (ctx=0x7fff9809e4a0, fb=0x7fff992e59d0, numAttachments=, attachments=0x7fff992a7d60) at ../src/mesa/main/fbobject.c:4917 #2 0x5a38b383 in gpu::gles2::GLES2DecoderImpl::InvalidateFramebufferImpl(unsigned int, int, unsigned int const volatile*, int, int, int, int, char const*, gpu::gles2::GLES2DecoderImpl::FramebufferOperation) () #3 0x5a38b9fd in gpu::gles2::GLES2DecoderImpl::HandleInvalidateFramebufferImmediate(unsigned int, void const volatile*) () #4 0x5a3be2a2 in gpu::error::Error gpu::gles2::GLES2DecoderImpl::DoCommandsImpl(unsigned int, void const volatile*, int, int*) () #5 0x5a271ae1 in gpu::CommandBufferService::Flush(int, gpu::AsyncAPIInterface*) () #6 0x5a51a3d7 in gpu::CommandBufferStub::OnAsyncFlush(int, unsigned int, std::vector > const&) () #7 0x5a51ad77 in gpu::CommandBufferStub::OnMessageReceived(IPC::Message const&) () #8 0x5d8b8ca3 in IPC::MessageRouter::RouteMessage(IPC::Message const&) () #9 0x5a531917 in gpu::GpuChannel::HandleMessageHelper(IPC::Message const&) () #10 0x5a5319cb in gpu::GpuChannel::HandleMessage(IPC::Message const&) () #11 0x5a276919 in gpu::Scheduler::RunNextTask() () #12 0x5931e255 in base::TaskAnnotator::RunTask(char const*, base::PendingTask*) () #13 0x59337124 in base::sequence_manager::internal::ThreadControllerWithMessagePumpImpl::DoWorkImpl(base::sequence_manager::LazyNow*, bool*) () #14 0x593376dd in base::sequence_manager::internal::ThreadControllerWithMessagePumpImpl::DoSomeWork() () #15 0x592e12e6 in base::MessagePumpDefault::Run(base::MessagePump::Delegate*) () #16 0x593211af in base::sequence_manager::internal::ThreadControllerWithMessagePumpImpl::Run(bool, base::TimeDelta) () #17 0x593085ba in base::RunLoop::Run() () #18 0x5934adf3 in base::Thread::ThreadMain() () #19 0x59389f8a in base::(anonymous namespace)::ThreadFunc(void*) () #20 0x77f78fb7 in start_thread (arg=) at pthread_create.c:486 #21 0x713612cf in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95 (gdb) quit I can retest with upstream Mesa from git and compiled myself and correlate lines better.
Bug#943563: chromium crash when trying to check error status after invalidateing framebuffer in WebGL
control: tag -1 moreinfo On Sat, Oct 26, 2019 at 10:48 AM Witold Baryluk wrote: > Thread 20 "Chrome_InProcGp" received signal SIGSEGV, Segmentation fault. > [Switching to Thread 0x7fffaa7fc700 (LWP 32634)] > 0x7fff770d9c37 in ?? () from /usr/lib/x86_64-linux-gnu/dri/radeonsi_dri.so > (gdb) bt > #0 0x7fff770d9c37 in () at /usr/lib/x86_64-linux-gnu/dri/radeonsi_dri.so > #1 0x7fff76f76409 in () at /usr/lib/x86_64-linux-gnu/dri/radeonsi_dri.so > #2 0x59e1d3b1 in > gpu::gles2::GLES2DecoderImpl::InvalidateFramebufferImpl(unsigned int, int, > unsigned int const volatile*, int, int, int, int, char const*, > gpu::gles2::GLES2DecoderImpl::FramebufferOperation) () > #3 0x59e2030a in > gpu::gles2::GLES2DecoderImpl::HandleInvalidateFramebufferImmediate(unsigned > int, void const volatile*) () > #4 0x59dfa261 in gpu::error::Error > gpu::gles2::GLES2DecoderImpl::DoCommandsImpl(unsigned int, void const > volatile*, int, int*) () This looks like an error in the RadeonSI driver. Could you try installing libgl1-mesa-dri-dbgsym to fill in the ?? in the backtrace? Best wishes, Mike
Bug#943563: chromium crash when trying to check error status after invalidateing framebuffer in WebGL
Package: chromium Version: 76.0.3809.100-1 Severity: normal Dear Maintainer, When visiting https://www.khronos.org/registry/webgl/sdk/tests/conformance2/renderbuffers/invalidate-framebuffer.html?webglVersion=2=0=1 the test fails: This tests invalidateFramebuffer and invalidateSubFramebuffer On success, you will see a series of "PASS" messages, followed by "TEST COMPLETE". Canvas.getContext PASS context exists invalidate framebuffer. PASS gl.checkFramebufferStatus(gl.FRAMEBUFFER) is gl.FRAMEBUFFER_INCOMPLETE_ATTACHMENT PASS getError was expected value: NO_ERROR : calling invalidateSubFramebuffer to invalidate an incomplete attachment will be ignored. There should be no errors PASS getError was expected value: NO_ERROR : calling invalidateFramebuffer to invalidate an incomplete attachment will be ignored. There should be no errors. FAIL getError expected: NO_ERROR. Was INVALID_OPERATION : should be no errors after attaching a multi-sampled renderbuffer to fbo. FAIL gl.checkFramebufferStatus(gl.FRAMEBUFFER) should be 36054. Was 0. PASS getError was expected value: NO_ERROR : calling invalidateSubFramebuffer to invalidate an incomplete attachment will be ignored. There should be no errors PASS getError was expected value: NO_ERROR : calling invalidateFramebuffer to invalidate an incomplete attachment will be ignored. There should be no errors. FAIL getError expected: NO_ERROR. Was INVALID_OPERATION : should be no errors after attaching a renderbuffer to fbo. PASS getError was expected value: NO_ERROR : calling invalidateSubFramebuffer to invalidate a specified attachment that does not exist will be ignored. There should be no errors. PASS getError was expected value: NO_ERROR : calling invalidateSubFramebuffer should succeed. PASS getError was expected value: INVALID_VALUE : calling invalidateSubFramebuffer should generate INVALID_VALUE if width < 0 or height < 0. PASS getError was expected value: NO_ERROR : calling invalidateSubFramebuffer should succeed, even the invalidated pixels may be outside of the framebuffer allocated to current context. These pixels are ignored. PASS getError was expected value: NO_ERROR : calling invalidateSubFramebuffer should succeed, even the invalidated pixels may be outside of the framebuffer allocated to current context. These pixels are ignored. PASS getError was expected value: NO_ERROR : calling invalidateFramebuffer to invalidate a specified attachment that does not exist will be ignored. There should be no errors. PASS getError was expected value: NO_ERROR : calling invalidateFramebuffer should succeed. PASS getError was expected value: NO_ERROR : should be no errors after attaching a renderbuffer to fbo. PASS getError was expected value: NO_ERROR : should be no errors after bliting framebuffer. PASS getError was expected value: NO_ERROR : calling invalidateSubFramebuffer to invalidate a specified attachment that does not exist will be ignored. There should be no errors. PASS getError was expected value: NO_ERROR : calling invalidateSubFramebuffer should succeed. PASS getError was expected value: INVALID_VALUE : calling invalidateSubFramebuffer should generate INVALID_VALUE if width < 0 or height < 0. PASS getError was expected value: NO_ERROR : calling invalidateSubFramebuffer should succeed, even the invalidated pixels may be outside of the framebuffer allocated to current context. These pixels are ignored. PASS getError was expected value: NO_ERROR : calling invalidateSubFramebuffer should succeed, even the invalidated pixels may be outside of the framebuffer allocated to current context. These pixels are ignored. PASS getError was expected value: NO_ERROR : calling invalidateFramebuffer to invalidate a specified attachment that does not exist will be ignored. There should be no errors. PASS getError was expected value: NO_ERROR : calling invalidateFramebuffer should succeed. FAIL getError expected one of: INVALID_OPERATION or INVALID_ENUM. Was NO_ERROR : calling invalidateSubFramebuffer to invalidate a COLOR_ATTACHMENT that exceeds MAX_COLOR_ATTACHMENT should generate INVALID_ENUM or INVALID_OPERATION. FAIL getError expected one of: INVALID_OPERATION or INVALID_ENUM. Was NO_ERROR : calling invalidateFramebuffer to invalidate a COLOR_ATTACHMENT that exceeds MAX_COLOR_ATTACHMENT should generate INVALID_ENUM or INVALID_OPERATION. PASS getError was expected value: NO_ERROR : calling invalidateSubFramebuffer to invalidate a specified attachment that does not exist will be ignored. There should be no errors. PASS getError was expected value: NO_ERROR : calling invalidateSubFramebuffer should succeed. PASS getError was expected value: INVALID_VALUE : calling invalidateSubFramebuffer should generate INVALID_VALUE if width < 0 or height < 0. PASS getError was expected value: NO_ERROR : calling invalidateSubFramebuffer should succeed, even the invalidated pixels may be outside of the framebuffer allocated to current
