Bug#1062969: doomsday: launching doomsday (2.3.1+ds1-1+b2) causes segfault in libsdl2-2.0-0 (2.30.0+dfsg-1)
Control: clone -1 -2
Control: reassign -1 libsdl2 2.30.0+dfsg-1
Control: reassign -2 doomsday 2.3.1+ds1-1
Control: retitle -1 libsdl2: SDL_JoystickName() doesn't tolerate NULL joystick
object since 2.30
Control: retitle -2 doomsday: shouldn't rely on being able to call methods on a
NULL SDL object
On Sun, 04 Feb 2024 at 12:31:35 +, Simon McVittie wrote:
> When I try the command above, on GNOME in Wayland mode, I get what
> appears to be a different crash
Now reported separately as #1065709, which I now see was a duplicate
of #1057620 (I'll merge them).
> which makes me wonder whether there is some conflict between the way
> libsdl2 is using X11, and the way the doomsday engine is using X11
> internally?
Yes. A workaround for this crash is to run it like:
SDL_VIDEODRIVER=x11 QT_QPA_PLATFORM=xcb doomsday -game doom2
and with that command I can reproduce a backtrace similar to the one
you provided.
> This might either be a regression in libsdl2, or an unintended interaction
> with the new libsdl2 exposing a bug in doomsday; at this stage it's hard
> to tell which.
I think it's really both, so I'm cloning the bug.
If you don't have a joystick or gamepad attached, Doomsday relies on being
able to call SDL_JoystickName(nullptr).
On one hand, this is fairly clearly a programming error, because
SDL_JoystickName() is documented to take a pointer to a SDL_Joystick as
its parameter, and nullptr isn't a joystick (more like the absence of a
joystick). So doomsday should be doing more like this:
de::String Joystick_Name()
{
#ifndef DENG_NO_SDL
-return SDL_JoystickName(joy);
+return (joy ? SDL_JoystickName(joy) : "");
#else
return "";
#endif
}
or perhaps:
de::String Joystick_Name()
{
#ifndef DENG_NO_SDL
-return SDL_JoystickName(joy);
+return (joyAvailable ? SDL_JoystickName(joy) : "");
#else
return "";
#endif
}
Let's use a cloned bug to represent that.
But on the other hand, SDL has historically tolerated NULL parameters to
most of its public API, returning an error code, so the fact that 2.30
no longer does that for this particular function is technically a
regression I suppose. I'll use #1062969 to represent the SDL regression.
smcv
Bug#1062969: doomsday: launching doomsday (2.3.1+ds1-1+b2) causes segfault in libsdl2-2.0-0 (2.30.0+dfsg-1)
Output from gdb (first try with doomsday-dbgsym, doomsday-common-dbgsym, libsdl2-2.0-0-dbgsym) can be found in attachment. Tell me to install more debug packages. ylb doomsday_gdb_output.txt.7z Description: application/7z-compressed
Bug#1062969: doomsday: launching doomsday (2.3.1+ds1-1+b2) causes segfault in libsdl2-2.0-0 (2.30.0+dfsg-1)
On Tue, 06 Feb 2024 at 10:20:46 +0100, Yves Le Berre wrote: > I am not familiarized with building debian debug packages. > do doomsday and libsdl2 packages need to be rebuilt or do they exist > somewhere ? Their detached debug symbols should already be provided in Debian, so you don't need to rebuild anything. You can either use export DEBUGINFOD_URLS="https://debuginfod.debian.net; (that's the easier option), or add these apt sources: deb http://deb.debian.org/debian-debug/ testing-debug main deb http://deb.debian.org/debian-debug/ unstable-debug main and install the relevant -dbgsym packages: - doomsday-dbgsym - libsdl2-2.0-0-dbgsym - libx11-6-dbgsym - libxcb1-dbgsym - libxext6-dbgsym - libxrandr2-dbgsym - probably others, but I can't tell which ones without seeing a backtrace with partial symbols Thanks, smcv
Bug#1062969: doomsday: launching doomsday (2.3.1+ds1-1+b2) causes segfault in libsdl2-2.0-0 (2.30.0+dfsg-1)
Sorry, your answer on Sun, 4 Feb 2024 12:31:35 + was marked 'spam' by my provider, so i didn't notice it until now. Here are some informations about my environment : System: Host: jupiter Kernel: 6.6.13-amd64 arch: x86_64 bits: 64 Desktop: Xfce v: 4.18.1 Distro: Debian GNU/Linux trixie/sid CPU: Info: 6-core model: AMD Ryzen 5 2600X bits: 64 type: MT MCP cache: L2: 3 MiB Graphics: Device-1: NVIDIA TU116 [GeForce GTX 1660] driver: nvidia v: 525.147.05 Display: x11 server: X.Org v: 21.1.11 driver: X: loaded: nvidia unloaded: fbdev,modesetting,nouveau,vesa gpu: nvidia resolution: 1920x1080~60Hz API: EGL v: 1.5 drivers: nvidia,swrast platforms: gbm,x11,surfaceless,device API: OpenGL v: 4.6.0 vendor: nvidia v: 525.147.05 renderer: NVIDIA GeForce GTX 1660/PCIe/SSE2 I use alternatively compiz and xfwm4 as WM and compositor. Crash was in compiz session. I am not familiarized with building debian debug packages. do doomsday and libsdl2 packages need to be rebuilt or do they exist somewhere ? ylb
Bug#1062969: doomsday: launching doomsday (2.3.1+ds1-1+b2) causes segfault in libsdl2-2.0-0 (2.30.0+dfsg-1)
Control: reassign -1 doomsday,src:libsdl2 Control: found -1 doomsday/2.3.1+ds1-1 Control: found -1 libsdl2/2.30.0+dfsg-1 On Sun, 04 Feb 2024 at 09:18:27 +0100, Yves Le Berre wrote: > * What led up to the situation? > > loading wad file (doom /doom2/heretic/...) Please assume that I'm unfamiliar with the doomsday package. What packages would I install and what command would I run to reproduce this? Also, it might be relevant to ask: what desktop environment or other GUI are you using? And for desktop environments that support being run as a Wayland compositor, is it in Wayland or X11 mode? To reproduce *a* crash on my system (GNOME in Wayland mode), it seems to be sufficient to install doomsday and doom-wad-shareware, and run: doomsday -iwad /usr/share/games/doom/doom1.wad but I don't think this is necessarily the same crash you're seeing. > segmentation fault : > > févr. 04 08:54:11 jupiter kernel: Code: 1d df b0 17 00 48 89 df 48 83 ec 08 > e8 ff b8 fc ff 48 8b 3d d0 b0 17 00 e8 23 61 0e 00 48 89 df be ff ff ff ff > e8 e6 b8 fc ff <8b> 7d 08 83 05 ac b0 17 00 01 e8 f7 fd ff ff 48 89 c3 48 85 > c0 74 > févr. 04 08:54:11 jupiter kernel: doomsday[4521]: segfault at 8 ip > 7fd6534a268a sp 7ffe8e89e7d0 error 4 in > libSDL2-2.0.so.0.3000.0[7fd65346a000+12c000] likely on CPU 0 (core 0, socket > 0) Are you able to get a backtrace from this segfault? Please see: https://wiki.debian.org/HowToGetABacktrace When I try the command above, on GNOME in Wayland mode, I get what appears to be a different crash: Thread 1 (Thread 0x709b1980 (LWP 584950) "doomsday"): #0 0x753ace83 in require_socket (dpy=) at ../../src/xcb_io.c:70 #1 _XFlush (dpy=0x55faf230) at ../../src/xcb_io.c:606 #2 0x753afb3d in _XGetRequest (dpy=dpy@entry=0x55faf230, type=type@entry=98 'b', len=len@entry=8) at ../../src/XlibInt.c:1787 #3 0x753a2a57 in XQueryExtension (dpy=dpy@entry=0x55faf230, name=name@entry=0x75367128 "RANDR", major_opcode=major_opcode@entry=0x7fffd714, first_event=first_event@entry=0x7fffd718, first_error=first_error@entry=0x7fffd71c) at ../../src/QuExt.c:49 #4 0x75395b16 in XInitExtension (dpy=dpy@entry=0x55faf230, name=name@entry=0x75367128 "RANDR") at ../../src/InitExt.c:59 #5 0x760e7c9b in XextAddDisplay (extinfo=extinfo@entry=0x753671b0 , dpy=dpy@entry=0x55faf230, ext_name=ext_name@entry=0x75367128 "RANDR", hooks=hooks@entry=0x75367140 , nevents=nevents@entry=2, data=data@entry=0x0) at ../../src/extutil.c:110 #6 0x7535d860 in XRRFindDisplay (dpy=dpy@entry=0x55faf230) at ../../src/Xrandr.c:295 #7 0x7535dfc0 in XRRFindDisplay (dpy=0x55faf230) at ../../src/Xrandr.c:361 #8 XRRQueryExtension (dpy=0x55faf230, event_base_return=0x7fffd818, error_base_return=0x7fffd818) at ../../src/Xrandr.c:352 #9 0x77995ae4 in de::internal::RRInfo::RRInfo() (this=0x7fffd8a0) at ./doomsday/sdk/libgui/src/displaymode_x11.cpp:63 #10 0x7799502d in DisplayMode_Native_Init() () at ./doomsday/sdk/libgui/src/displaymode_x11.cpp:188 #11 0x77929d11 in DisplayMode_Init() () at ./doomsday/sdk/libgui/src/displaymode.cpp:195 #12 0x5573eb1d in ClientApp::initialize() (this=0x7fffda90) at ./doomsday/apps/client/src/clientapp.cpp:628 #13 0x5572175d in main(int, char**) (argc=, argv=0x7fffdcb8) at ./doomsday/apps/client/src/main_client.cpp:109 which makes me wonder whether there is some conflict between the way libsdl2 is using X11, and the way the doomsday engine is using X11 internally? At the time of this crash, all other threads seem to be blocked in poll() or pthread_cond_wait() or similar: none of them are actively running code. > NB: Downgrading libsdl2-2.0-0 to 2.28.5+dfsg-3 solves issue. This might either be a regression in libsdl2, or an unintended interaction with the new libsdl2 exposing a bug in doomsday; at this stage it's hard to tell which. smcv
Bug#1062969: doomsday: launching doomsday (2.3.1+ds1-1+b2) causes segfault in libsdl2-2.0-0 (2.30.0+dfsg-1)
Package: doomsday Version: 2.3.1+ds1-1+b2 Severity: grave Justification: renders package unusable Dear Maintainer, * What led up to the situation? loading wad file (doom /doom2/heretic/...) * What exactly did you do (or not do) that was effective (or ineffective)? upgraded libsdl2-2.0-0 (2.28.5+dfsg-3 to 2.30.0+dfsg-1) before spawning doomsday. * What was the outcome of this action? segmentation fault : févr. 04 08:54:11 jupiter kernel: Code: 1d df b0 17 00 48 89 df 48 83 ec 08 e8 ff b8 fc ff 48 8b 3d d0 b0 17 00 e8 23 61 0e 00 48 89 df be ff ff ff ff e8 e6 b8 fc ff <8b> 7d 08 83 05 ac b0 17 00 01 e8 f7 fd ff ff 48 89 c3 48 85 c0 74 févr. 04 08:54:11 jupiter kernel: doomsday[4521]: segfault at 8 ip 7fd6534a268a sp 7ffe8e89e7d0 error 4 in libSDL2-2.0.so.0.3000.0[7fd65346a000+12c000] likely on CPU 0 (core 0, socket 0) * What outcome did you expect instead? start of game. NB: Downgrading libsdl2-2.0-0 to 2.28.5+dfsg-3 solves issue. -- System Information: Debian Release: trixie/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 6.6.13-amd64 (SMP w/12 CPU threads; PREEMPT) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages doomsday depends on: ii doomsday-common 2.3.1+ds1-1+b2 ii doomsday-data 2.3.1+ds1-1 ii libc6 2.37-15 ii libgcc-s1 14-20240201-3 ii libqt5core5a 5.15.10+dfsg-6 ii libqt5gui5 5.15.10+dfsg-6 ii libqt5network5 5.15.10+dfsg-6 ii libqt5widgets5 5.15.10+dfsg-6 ii libsdl2-2.0-0 2.30.0+dfsg-1 ii libsdl2-mixer-2.0-0 2.8.0+dfsg-1 ii libstdc++6 14-20240201-3 Versions of packages doomsday recommends: ii fluid-soundfont-gm 3.1-5.3 doomsday suggests no packages. -- no debconf information
