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
00007fd6534a268a sp 00007ffe8e89e7d0 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.

Control: reassign -1 doomsday,src:libsdl2
Control: found -1 doomsday/2.3.1+ds1-1
Control: found -1 libsdl2/2.30.0+dfsg-1
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.
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 0x7ffff09b1980 (LWP 584950) "doomsday"):
#0  0x00007ffff53ace83 in require_socket (dpy=<optimized out>) at ../../src/xcb_io.c:70
#1  _XFlush (dpy=0x555555faf230) at ../../src/xcb_io.c:606
#2  0x00007ffff53afb3d in _XGetRequest (dpy=dpy@entry=0x555555faf230, type=type@entry=98 'b', len=len@entry=8) at ../../src/XlibInt.c:1787
#3  0x00007ffff53a2a57 in XQueryExtension (dpy=dpy@entry=0x555555faf230, name=name@entry=0x7ffff5367128 <XRRExtensionName> "RANDR", major_opcode=major_opcode@entry=0x7fffffffd714, first_event=first_event@entry=0x7fffffffd718, first_error=first_error@entry=0x7fffffffd71c) at ../../src/QuExt.c:49
#4  0x00007ffff5395b16 in XInitExtension (dpy=dpy@entry=0x555555faf230, name=name@entry=0x7ffff5367128 <XRRExtensionName> "RANDR") at ../../src/InitExt.c:59
#5  0x00007ffff60e7c9b in XextAddDisplay (extinfo=extinfo@entry=0x7ffff53671b0 <XRRExtensionInfo>, dpy=dpy@entry=0x555555faf230, ext_name=ext_name@entry=0x7ffff5367128 <XRRExtensionName> "RANDR", hooks=hooks@entry=0x7ffff5367140 <rr_extension_hooks>, nevents=nevents@entry=2, data=data@entry=0x0) at ../../src/extutil.c:110
#6  0x00007ffff535d860 in XRRFindDisplay (dpy=dpy@entry=0x555555faf230) at ../../src/Xrandr.c:295
#7  0x00007ffff535dfc0 in XRRFindDisplay (dpy=0x555555faf230) at ../../src/Xrandr.c:361
#8  XRRQueryExtension (dpy=0x555555faf230, event_base_return=0x7fffffffd818, error_base_return=0x7fffffffd818) at ../../src/Xrandr.c:352
#9  0x00007ffff7995ae4 in de::internal::RRInfo::RRInfo() (this=0x7fffffffd8a0) at ./doomsday/sdk/libgui/src/displaymode_x11.cpp:63
#10 0x00007ffff799502d in DisplayMode_Native_Init() () at ./doomsday/sdk/libgui/src/displaymode_x11.cpp:188
#11 0x00007ffff7929d11 in DisplayMode_Init() () at ./doomsday/sdk/libgui/src/displaymode.cpp:195
#12 0x000055555573eb1d in ClientApp::initialize() (this=0x7fffffffda90) at ./doomsday/apps/client/src/clientapp.cpp:628
#13 0x000055555572175d in main(int, char**) (argc=<optimized out>, argv=0x7fffffffdcb8) 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.

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

Sorry, your answer on Sun, 4 Feb 2024 12:31:35 +0000 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

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

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

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

Now reported separately as #1065709, which I now see was a duplicate
of #1057620 (I'll merge them).

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.

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