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