1279309 - GLX vsync freezes after XRandR changes with Intel DDX driver

Status: RESOLVED DUPLICATE of bug 1710400

(Core :: Graphics, defect, P3)

Description

[Andrew Comminos [:acomminos]]

On mesa drivers, changing the screen resolution with XRandR results in a hang in the GLX VSync thread- particularly when the change makes the root window larger.

>#0  0x00007ffff6e61dcd in poll () at ../sysdeps/unix/syscall-template.S:84
>#1  0x00007ffff0d6d382 in _xcb_conn_wait (__timeout=-1, __nfds=1, __fds=0x7fffd1ef74f0) at /usr/include/x86_64-linux-gnu/bits/poll2.h:46
>#2  0x00007ffff0d6d382 in _xcb_conn_wait (c=c@entry=0x7fffc607b000, cond=cond@entry=0x7fffd1ef7610, vector=vector@entry=0x0, count=count@entry=0x0) at ../../src/xcb_conn.c:459
>#3  0x00007ffff0d6ed37 in wait_for_reply (c=c@entry=0x7fffc607b000, request=1277, e=e@entry=0x0) at ../../src/xcb_in.c:516
>#4  0x00007ffff0d6ee41 in xcb_wait_for_reply (c=0x7fffc607b000, request=1277, e=0x0) at ../../src/xcb_in.c:546
>#5  0x00007fffc8ac9b74 in dri2WaitForMSC (pdraw=0x7fffce83e530, target_msc=0, divisor=2, remainder=<optimized out>, ust=0x7fffd1ef7730, msc=0x7fffd1ef7738, sbc=0x7fffd1ef7740) at ../../../src/glx/dri2_glx.c:478
>#6  0x00007fffc8aa02a7 in __glXWaitVideoSyncSGI (divisor=2, remainder=1, count=0x7fffd1ef77ec) at ../../../src/glx/glxcmds.c:1893
>#7  0x00007fffe59b1db9 in mozilla::gl::GLXLibrary::xWaitVideoSync(int, int, unsigned int*) (this=0x7fffedc131a0 <mozilla::gl::sGLXLibrary>, divisor=2, remainder=1, count=0x7fffd1ef77ec)
>    at /home/andrew/mozilla-central/gfx/gl/GLContextProviderGLX.cpp:776
>#8  0x00007fffe5c25cc0 in GLXVsyncSource::GLXDisplay::RunVsync() (this=0x7fffd0459740) at /home/andrew/mozilla-central/gfx/thebes/gfxPlatformGtk.cpp:771
>#9  0x00007fffe5c26cdf in nsRunnableMethodArguments<>::applyImpl<GLXVsyncSource::GLXDisplay, void (GLXVsyncSource::GLXDisplay::*)()>(GLXVsyncSource::GLXDisplay*, void (GLXVsyncSource::GLXDisplay::*)(), mozilla::Tuple<>&, mozilla::IndexSequence<>) (o=0x7fffd0459740, m=(void (GLXVsyncSource::GLXDisplay::*)(GLXVsyncSource::GLXDisplay * const)) 0x7fffe5c25b78 <GLXVsyncSource::GLXDisplay::RunVsync()>, args=...)
>    at /home/andrew/mozilla-central/obj-x86_64-pc-linux-gnu/dist/include/nsThreadUtils.h:722
>#10 0x00007fffe5c26c74 in nsRunnableMethodArguments<>::apply<GLXVsyncSource::GLXDisplay, void (GLXVsyncSource::GLXDisplay::*)()>(GLXVsyncSource::GLXDisplay*, void (GLXVsyncSource::GLXDisplay::*)()) (this=0x7fffc1b20d30, o=0x7fffd0459740, m=(void (GLXVsyncSource::GLXDisplay::*)(GLXVsyncSource::GLXDisplay * const)) 0x7fffe5c25b78 <GLXVsyncSource::GLXDisplay::RunVsync()>)
>    at /home/andrew/mozilla-central/obj-x86_64-pc-linux-gnu/dist/include/nsThreadUtils.h:729
>#11 0x00007fffe5c26b6b in nsRunnableMethodImpl<void (GLXVsyncSource::GLXDisplay::*)(), true, false>::Run() (this=0x7fffc1b20d00) at /home/andrew/mozilla-central/obj-x86_64-pc-linux-gnu/dist/include/nsThreadUtils.h:756
>#12 0x00007fffe4c35af6 in MessageLoop::RunTask(already_AddRefed<mozilla::Runnable>) (this=0x7fffd1ef7d00, aTask=...) at /home/andrew/mozilla-central/ipc/chromium/src/base/message_loop.cc:349
>#13 0x00007fffe4c35b7f in MessageLoop::DeferOrRunPendingTask(MessageLoop::PendingTask&&) (this=0x7fffd1ef7d00, pending_task=<unknown type in /home/andrew/mozilla-central/obj-x86_64-pc-linux-gnu/dist/bin/libxul.so, CU 0x1e9d553, DIE 0x1ee503d>) at /home/andrew/mozilla-central/ipc/chromium/src/base/message_loop.cc:357
>#14 0x00007fffe4c35f0f in MessageLoop::DoWork() (this=0x7fffd1ef7d00) at /home/andrew/mozilla-central/ipc/chromium/src/base/message_loop.cc:432
>#15 0x00007fffe4c3645a in base::MessagePumpDefault::Run(base::MessagePump::Delegate*) (this=0x7fffcdea23d0, delegate=0x7fffd1ef7d00) at /home/andrew/mozilla-central/ipc/chromium/src/base/message_pump_default.cc:36
>#16 0x00007fffe4c3535d in MessageLoop::RunInternal() (this=0x7fffd1ef7d00) at /home/andrew/mozilla-central/ipc/chromium/src/base/message_loop.cc:235
>#17 0x00007fffe4c352f0 in MessageLoop::RunHandler() (this=0x7fffd1ef7d00) at /home/andrew/mozilla-central/ipc/chromium/src/base/message_loop.cc:228
>#18 0x00007fffe4c352c9 in MessageLoop::Run() (this=0x7fffd1ef7d00) at /home/andrew/mozilla-central/ipc/chromium/src/base/message_loop.cc:208
>#19 0x00007fffe4c52a65 in base::Thread::ThreadMain() (this=0x7fffd04597e0) at /home/andrew/mozilla-central/ipc/chromium/src/base/thread.cc:180
>#20 0x00007fffe4c4dfc7 in ThreadFunc(void*) (closure=0x7fffd04597e0) at /home/andrew/mozilla-central/ipc/chromium/src/base/platform_thread_posix.cc:38
>#21 0x00007ffff7bc5464 in start_thread (arg=0x7fffd1ef8700) at pthread_create.c:334
>#22 0x00007ffff6e6ae5d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:109

I'm thinking recreating the GLX context backing the vsync source after the root window gets resized should fix this issue. This is what compton does.

Comment 1

[Andrew Comminos [:acomminos]]

Ack, this may be quite annoying to work around; RANDR-RRScreenChangeNotify is received well after mesa starts waiting for a MSC increment in most cases.

We may need to disable GLX VSync on Mesa until https://bugs.freedesktop.org/show_bug.cgi?id=35607 is fixed. I don't think it's a good idea to cancel the pthread while it's hung waiting for a response from X11.

Comment 2

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

I see this too, now that I'm back in the office and connect my laptop to an external monitor.

(I ended up in a situation where Firefox would mostly not repaint, although a few window switching maneuvers caused repaints.  I was able to quit using the shortcut key, and shutting down hung with the main thread trying to join the GLX thread, and the GLX thread with a stack like comment 0's stack, although I didn't check every detail matches.)

Comment 3

[Chris AtLee [:catlee]]

I was seeing something similar as well. My shutdown crash looked like this:
https://crash-stats.mozilla.com/report/index/e7434fa0-f740-482b-bb54-c4cc42160629

:jrmuizel suggested that https://bugzilla.mozilla.org/show_bug.cgi?id=1281105 may be related; I haven't been able to reproduce this issue on today's nightly.

Comment 4

[Andrew Comminos [:acomminos]]

It's worth noting that this won't happen by default on Nightly any more since the GLX Vsync provider is only used when hardware composition is force-enabled.

More interestingly, I can no longer reproduce this after switching to the xserver-xorg-video-modesetting DDX on my Haswell chip; looks like this likely isn't an issue in mesa, but in the DDX instead (xserver-xorg-video-intel). This makes sense considering our userspace driver (mesa) is left waiting on the server, whose DDX driver is providing our DRI implementation.

Comment 5

[zézinho]

I think I have the same problem : no repaint after changing the desktop size. And even closing Firefox does not kill the process. I am using ESR 52.6.0 version in Mageia Linux, with intel DDX.

Comment 6

[mirh]

https://gitlab.freedesktop.org/mesa/mesa/-/issues/75
Take note this supposedly might have been a X server bug. And with 1.21 on the horizon, chances are something changed.