Xlib deadlock in GUI thread

[mixxxbot]

Reported by: Be-ing
Date: 2018-11-28T04:13:13Z
Status: Fix Released
Importance: Critical
Launchpad Issue: lp1805559
Tags: qt5
Attachments: backtrace.txt, testCase.c

---

[Impact]

Current Mixxx 2.2.0 beta and Mixxx 2.1.3 using 2.2 with RGB (GL) waveforms on XWayland with Qt 5.11.1-9.fc29.x86_64, libX11 1.6.7-1.fc29.x86_64, libxcb 1.13.1-1.fc29.x86_64 causes a GUI deadlock.

The issue can be isolated and fixed with the code posted in comment #⁠11 below. It is not reliable reproducible with the original Mixxx build.

[Test Case]

• Use Mixxx with the effected setup and verify that there is no GUI deadlock.

[Regression Potential]

None.

[Other Info]

The Cosmic 2.1.3 build is also effected, see: https://bugs.launchpad.net/ubuntu/+source/mixxx/+bug/1804513

[mixxxbot]

Commented by: Be-ing
Date: 2018-11-28T04:13:13Z
Attachments: backtrace.txt

[mixxxbot]

Commented by: Be-ing
Date: 2018-11-28T04:13:51Z

---

Note this is a different backtrace than Bug #⁠1789059.

[mixxxbot]

Commented by: Be-ing
Date: 2018-11-28T04:15:51Z

---

Using xorg-x11-drv-intel-2.99.917-39.20180618.fc29.x86_64 with Intel UHD Graphics 620.

[mixxxbot]

Commented by: Be-ing
Date: 2018-11-28T04:43:37Z

---

Actually this is the same backtrace in Xlib as Bug #⁠1789059, but now something else in Mixxx is triggering it. Unfortunately the backtrace doesn't seem very helpful in identifying what that is.

[mixxxbot]

Commented by: uklotzde
Date: 2018-11-28T07:59:03Z

---

I've never seen this issue on Fedora 28/29 on i5-6440HQ with HD Graphics 530.

[mixxxbot]

Commented by: uklotzde
Date: 2018-11-28T08:00:30Z

---

...same configuration, i.e. XWayland and RGB (GL) waveforms. I'm using the Deere skin.

[mixxxbot]

Commented by: Be-ing
Date: 2018-11-28T16:42:26Z

---

#1923

[mixxxbot]

Commented by: Be-ing
Date: 2018-11-28T16:53:11Z

---

I have no idea why no one else has replicated this.

[mixxxbot]

Commented by: ywwg
Date: 2018-11-28T18:44:38Z

---

can you attach gdb while it's locked and inspect memory to see what event is being posted?

Are you using JACK as your audio backend? Do you also get lockups when using a different backend?

[mixxxbot]

Commented by: Be-ing
Date: 2018-11-28T21:23:04Z

---

I tried, but I don't know how to get any useful information from that. Running "frame Xlib-frame-number" then "info args" and "info local" didn't yield any useful information, I think because I didn't have the source code files for the library. If you have any tips how to get more useful info, please let me know. But at this point, I think the best course of action is to hack around the bug. Considering I have encountered at least two distinct situations (this bug and Bug #⁠1789059) that trigger the same Xlib bug, I'm not confident that if we change Mixxx to not trigger the Xlib bug in this one case that we won't discover more code in Mixxx later that also triggers the Xlib bug.

I do use JACK and I haven't tested if this happens with ALSA, but nothing in the backtrace leads me to suspect this has anything to do with audio processing. The audio thread continues fine when the GUI thread deadlocks, which allows me to recover relatively gracefully by letting the track continue to play till the end, then force quitting and restarting Mixxx.

[mixxxbot]

Commented by: Be-ing
Date: 2018-12-16T04:29:19Z
Attachments: testCase.c

---

I have not encountered this bug since #1923 was merged. To confirm that did hack around the issue, I applied the workaround to the testcase from https://bugs.freedesktop.org/show_bug.cgi?id=59361 and it does seem to work. Commenting out this line in the attached test case:

applyXDeadlockFix(dpy);

reproduces the bug.

Build the test case with:
gcc -I/usr/include testCase.c -o testCase -lX11-xcb -lX11 -lxcb

[mixxxbot]

Issue closed with status Fix Released.