Skip to content

GLX: lock-order-inversion between CommonMakeCurrent+__glXLookupDisplay and __glXDisplayClosed+OnDisplayCloses

I was testing Mesa git master, with clang-11 and thread sanitizer, and discovered this potential deadlock due inconsistent mutex locking order.

$ ... VARIOUS PATH STUFF ... LD_PRELOAD=/usr/lib/x86_64-linux-gnu/libtsan.so.0.0.0 TSAN_OPTIONS="second_deadlock_stack=1  external_symbolizer_path=/usr/bin/llvm-symbolizer-11 force_seq_cst_atomics=1"   glxinfo -B

...
OpenGL version string: 4.6 (Compatibility Profile) Mesa 21.0.0-devel (git-00b202a812)
OpenGL shading language version string: 4.60
OpenGL context flags: (none)
OpenGL profile mask: compatibility profile

OpenGL ES profile version string: OpenGL ES 3.2 Mesa 21.0.0-devel (git-00b202a812)
OpenGL ES profile shading language version string: OpenGL ES GLSL ES 3.20

==================
WARNING: ThreadSanitizer: lock-order-inversion (potential deadlock) (pid=3591934)
  Cycle in lock order graph: M1 (0x7f70043ca2a0) => M18 (0x7f70043ca368) => M1

  Mutex M18 acquired here while holding mutex M1 in main thread:
    #0 pthread_mutex_lock <null> (libtsan.so.0.0.0+0x4db3a)
    #1 __glXLookupDisplay ../src/GLX/libglxmapping.c:722 (libGLX.so.0+0x9b6f)

  Mutex M1 previously acquired by the same thread here:
    #0 pthread_mutex_lock <null> (libtsan.so.0.0.0+0x4db3a)
    #1 CommonMakeCurrent ../src/GLX/libglx.c:1017 (libGLX.so.0+0x506f)

  Mutex M1 acquired here while holding mutex M18 in main thread:
    #0 pthread_mutex_lock <null> (libtsan.so.0.0.0+0x4db3a)
    #1 __glXDisplayClosed ../src/GLX/libglx.c:631 (libGLX.so.0+0x425f)

  Mutex M18 previously acquired by the same thread here:
    #0 pthread_mutex_lock <null> (libtsan.so.0.0.0+0x4db3a)
    #1 OnDisplayClosed ../src/GLX/libglxmapping.c:698 (libGLX.so.0+0x7f4b)

SUMMARY: ThreadSanitizer: lock-order-inversion (potential deadlock) (/usr/lib/x86_64-linux-gnu/libtsan.so.0.0.0+0x4db3a) in pthread_mutex_lock
==================
ThreadSanitizer: reported 3 warnings

This is with libglvnd 1.3.2-1 from Debian testing.

I am testing on amd64, Linux 5.7.6, and AMD Radeon R9 Fury X.

This happens on both radeonsi and zink (with radv) to me.