Processed: Re: Bug#1062969: doomsday: launching doomsday (2.3.1+ds1-1+b2) causes segfault in libsdl2-2.0-0 (2.30.0+dfsg-1)
Processing control commands: > clone -1 -2 Bug #1062969 [doomsday,src:libsdl2] doomsday: launching doomsday (2.3.1+ds1-1+b2) causes segfault in libsdl2-2.0-0 (2.30.0+dfsg-1) Bug 1062969 cloned as bug 1065714 > reassign -1 libsdl2 2.30.0+dfsg-1 Bug #1062969 [doomsday,src:libsdl2] doomsday: launching doomsday (2.3.1+ds1-1+b2) causes segfault in libsdl2-2.0-0 (2.30.0+dfsg-1) Bug reassigned from package 'doomsday,src:libsdl2' to 'libsdl2'. No longer marked as found in versions doomsday/2.3.1+ds1-1 and libsdl2/2.30.0+dfsg-1. Ignoring request to alter fixed versions of bug #1062969 to the same values previously set Bug #1062969 [libsdl2] doomsday: launching doomsday (2.3.1+ds1-1+b2) causes segfault in libsdl2-2.0-0 (2.30.0+dfsg-1) There is no source info for the package 'libsdl2' at version '2.30.0+dfsg-1' with architecture '' Unable to make a source version for version '2.30.0+dfsg-1' Marked as found in versions 2.30.0+dfsg-1. > reassign -2 doomsday 2.3.1+ds1-1 Bug #1065714 [doomsday,src:libsdl2] doomsday: launching doomsday (2.3.1+ds1-1+b2) causes segfault in libsdl2-2.0-0 (2.30.0+dfsg-1) Bug reassigned from package 'doomsday,src:libsdl2' to 'doomsday'. No longer marked as found in versions libsdl2/2.30.0+dfsg-1 and doomsday/2.3.1+ds1-1. Ignoring request to alter fixed versions of bug #1065714 to the same values previously set Bug #1065714 [doomsday] doomsday: launching doomsday (2.3.1+ds1-1+b2) causes segfault in libsdl2-2.0-0 (2.30.0+dfsg-1) Marked as found in versions doomsday/2.3.1+ds1-1. > retitle -1 libsdl2: SDL_JoystickName() doesn't tolerate NULL joystick object > since 2.30 Bug #1062969 [libsdl2] doomsday: launching doomsday (2.3.1+ds1-1+b2) causes segfault in libsdl2-2.0-0 (2.30.0+dfsg-1) Changed Bug title to 'libsdl2: SDL_JoystickName() doesn't tolerate NULL joystick object since 2.30' from 'doomsday: launching doomsday (2.3.1+ds1-1+b2) causes segfault in libsdl2-2.0-0 (2.30.0+dfsg-1)'. > retitle -2 doomsday: shouldn't rely on being able to call methods on a NULL > SDL object Bug #1065714 [doomsday] doomsday: launching doomsday (2.3.1+ds1-1+b2) causes segfault in libsdl2-2.0-0 (2.30.0+dfsg-1) Changed Bug title to 'doomsday: shouldn't rely on being able to call methods on a NULL SDL object' from 'doomsday: launching doomsday (2.3.1+ds1-1+b2) causes segfault in libsdl2-2.0-0 (2.30.0+dfsg-1)'. -- 1062969: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1062969 1065714: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1065714 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
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
Processed: Re: Bug#1062969: doomsday: launching doomsday (2.3.1+ds1-1+b2) causes segfault in libsdl2-2.0-0 (2.30.0+dfsg-1)
Processing control commands: > reassign -1 doomsday,src:libsdl2 Bug #1062969 [doomsday] doomsday: launching doomsday (2.3.1+ds1-1+b2) causes segfault in libsdl2-2.0-0 (2.30.0+dfsg-1) Bug reassigned from package 'doomsday' to 'doomsday,src:libsdl2'. No longer marked as found in versions doomsday/2.3.1+ds1-1. Ignoring request to alter fixed versions of bug #1062969 to the same values previously set > found -1 doomsday/2.3.1+ds1-1 Bug #1062969 [doomsday,src:libsdl2] doomsday: launching doomsday (2.3.1+ds1-1+b2) causes segfault in libsdl2-2.0-0 (2.30.0+dfsg-1) Marked as found in versions doomsday/2.3.1+ds1-1. > found -1 libsdl2/2.30.0+dfsg-1 Bug #1062969 [doomsday,src:libsdl2] doomsday: launching doomsday (2.3.1+ds1-1+b2) causes segfault in libsdl2-2.0-0 (2.30.0+dfsg-1) Marked as found in versions libsdl2/2.30.0+dfsg-1. -- 1062969: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1062969 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
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