$ doomsday QSocketNotifier: Can only be used with threads started with QThread Segmentation fault (core dumped) $ Running under gdb (gdb) r Starting program: /usr/games/doomsday [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1". [New Thread 0x7ffff048b6c0 (LWP 1971100)] QSocketNotifier: Can only be used with threads started with QThread [New Thread 0x7fffeeafb6c0 (LWP 1971111)] [New Thread 0x7fffee2fa6c0 (LWP 1971112)] [New Thread 0x7fffedaf96c0 (LWP 1971113)] [New Thread 0x7fffed2766c0 (LWP 1971114)] [New Thread 0x7fffeca756c0 (LWP 1971115)] [New Thread 0x7fffd7f7e6c0 (LWP 1971116)] [New Thread 0x7fffd777d6c0 (LWP 1971117)] [New Thread 0x7fffd6f7c6c0 (LWP 1971118)] [New Thread 0x7fffbb3236c0 (LWP 1971137)] [New Thread 0x7fffba9e16c0 (LWP 1971138)] [New Thread 0x7fffba1e06c0 (LWP 1971139)] [New Thread 0x7fffb99df6c0 (LWP 1971140)] Thread 1 "doomsday" received signal SIGSEGV, Segmentation fault. 0x00007ffff5419e83 in _XFlush () from /lib/x86_64-linux-gnu/libX11.so.6 (gdb) bt #0 0x00007ffff5419e83 in _XFlush () at /lib/x86_64-linux-gnu/libX11.so.6 #1 0x00007ffff541cb3d in _XGetRequest () at /lib/x86_64-linux-gnu/libX11.so.6 #2 0x00007ffff540fa57 in XQueryExtension () at /lib/x86_64-linux-gnu/libX11.so.6 #3 0x00007ffff5402b16 in XInitExtension () at /lib/x86_64-linux-gnu/libX11.so.6 #4 0x00007ffff53cdc9b in XextAddDisplay () at /lib/x86_64-linux-gnu/libXext.so.6 #5 0x00007ffff538a860 in () at /lib/x86_64-linux-gnu/libXrandr.so.2 #6 0x00007ffff538afc0 in XRRQueryExtension () at /lib/x86_64-linux-gnu/libXrandr.so.2 #7 0x00007ffff798bae4 in de::internal::RRInfo::RRInfo() () at /lib/x86_64-linux-gnu/libdeng_gui.so.2.3 #8 0x00007ffff798b02d in DisplayMode_Native_Init () at /lib/x86_64-linux-gnu/libdeng_gui.so.2.3 #9 0x00007ffff791fd11 in DisplayMode_Init () at /lib/x86_64-linux-gnu/libdeng_gui.so.2.3 #10 0x000055555573eb1d in ClientApp::initialize() () #11 0x000055555572175d in main () (gdb) Running under gnome shell. xwayland 2:23.2.2-1
Hello, I am not maintainer of the doomsday package, just tried to collect some more information. Bug 1062969 / Bug 1065714 mentions a workaround to be able to run doomsday with wayland: SDL_VIDEODRIVER=x11 QT_QPA_PLATFORM=xcb doomsday https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1062969 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1065714 It looks like upstream removed the relevant code and relies just on SDL functions, but unfortunately did not release a new version yet. https://github.com/skyjake/Doomsday-Engine/commit/5cc4995861 Kind regards, Bernhard
Control: retitle 1057620 doomsday: segfault in _XFlush() when Qt is using native Wayland
Bug 1062969 is about a problem with SDL_JoystickName(), which is
fixed in unstable. The clone #1065714 is also about doomsday's use
of SDL_JoystickName(). Fixing those is unrelated to that workaround:
the only connection is that I had to use that workaround to avoid the
crash-on-startup before I was able to reproduce the joystick bug on
my system.
Bug 1057620 and its duplicate 1065709 are about the crash on startup that
can be worked around with "SDL_VIDEODRIVER=x11 QT_QPA_PLATFORM=xcb".
I'm copying the title from 1065709 to 1057620 to make its scope a bit
clearer.
I haven't reviewed that change in detail, but letting SDL handle all of the
functionality within its scope is generally a good direction to go in.
The root cause of this bug is that doomsday uses both SDL and Qt, each
of which makes its own independent choice between an X11 backend or a
native Wayland backend, and then uses X11 directly itself and assumes
that both SDL and Qt have also chosen to use X11.
If Doomsday needs to use both SDL and Qt for graphics/windowing, probably
the right way to implement this would be to let one of those libraries
choose its backend (X11 or Wayland) according to its usual heuristic,
and then call configuration functions that force the other library to
make the same choice.
smcv
Is this the same bug as #1113738? If yes, does the workaround from Bernhard I NMUed there look correct to you? cu Adrian
That depends how you define "same bug", but it's certainly closely-related.
If doomsday's Qt code doesn't work when using Qt's Wayland backend, then
the change you applied is necessary, but it might not be sufficient.
My concern about it would be what happens when Qt has been forced to use
X11 (by the patch you applied or by QT_QPA_PLATFORM=xcb in the
environment), but SDL is using native Wayland (via
SDL_VIDEODRIVER=wayland or replacing libsdl2-2.0-0 with
libsdl2-compat-shim). If doomsday code assumes that Qt windows on Unix
are always X11 windows, it is probably also assuming that SDL on Unix
will always be using the X11 backend.
If doomsday has that assumption, one way to make it be true would be to
call
SDL_SetHintWithPriority(SDL_HINT_VIDEODRIVER, "x11", SDL_HINT_OVERRIDE);
near the beginning of main(), before SDL_Init(). Or it could set
SDL_VIDEODRIVER=wayland as an environment variable, equivalent to what
you've done for Qt, which would have a similar effect.
All of this needs to happen before SDL initialization, and before the
program has had a chance to create a second thread, because setting
environment variables is not thread-safe and setting SDL hints is
probably also not thread-safe.
After discussion with SDL upstream, I'm hoping to make src:sdl2-compat
take over libsdl2-2.0-0 early in 2026, after which SDL 2 will default to
native Wayland in many environments, like GTK and Qt already do. Games
that assumed SDL will use X11 forever will need to adjust for that,
similar to what happened for GTK and Qt.
Users and developers can get a preview of the future SDL implementation
by replacing libsdl2-2.0-0 with libsdl2-compat-shim, and replacing
libsdl2-dev (if installed) with libsdl2-compat-dev.
smcv