Closed icculus closed 2 years ago
So this is a doozy of a stack trace and none of it looks related to SDL:
[New Thread 0x7ffff4226640 (LWP 4000438)]
[Thread 0x7ffff4226640 (LWP 4000438) exited]
[New Thread 0x7ffff4226640 (LWP 4000439)]
[New Thread 0x7ffff39ea640 (LWP 4000440)]
[Thread 0x7ffff4226640 (LWP 4000439) exited]
[Thread 0x7ffff39ea640 (LWP 4000440) exited]
[New Thread 0x7ffff39ea640 (LWP 4000441)]
[New Thread 0x7ffff4226640 (LWP 4000442)]
[Thread 0x7ffff39ea640 (LWP 4000441) exited]
[Thread 0x7ffff4226640 (LWP 4000442) exited]
Thread 1 "zandronum" received signal SIGSEGV, Segmentation fault.
___pthread_mutex_lock (mutex=0x0) at ./nptl/pthread_mutex_lock.c:80
80 ./nptl/pthread_mutex_lock.c: No such file or directory.
(gdb) bt
#0 ___pthread_mutex_lock (mutex=0x0) at ./nptl/pthread_mutex_lock.c:80
#1 0x00007ffff682c50f in XrmQGetResource () at /lib/x86_64-linux-gnu/libX11.so.6
#2 0x00007ffff680dd4a in XGetDefault () at /lib/x86_64-linux-gnu/libX11.so.6
#3 0x00007ffff6737f3b in () at /lib/x86_64-linux-gnu/libcairo.so.2
#4 0x00007ffff673ac54 in () at /lib/x86_64-linux-gnu/libcairo.so.2
#5 0x00007ffff670e8a9 in cairo_surface_get_font_options () at /lib/x86_64-linux-gnu/libcairo.so.2
#6 0x00007ffff66c37f2 in () at /lib/x86_64-linux-gnu/libcairo.so.2
#7 0x00007ffff66c76f2 in () at /lib/x86_64-linux-gnu/libcairo.so.2
#8 0x00007ffff671e3ab in cairo_show_glyphs () at /lib/x86_64-linux-gnu/libcairo.so.2
#9 0x00007ffff75cfe13 in () at /lib/x86_64-linux-gnu/libpangocairo-1.0.so.0
#10 0x00007ffff75cfe60 in () at /lib/x86_64-linux-gnu/libpangocairo-1.0.so.0
#11 0x00007ffff643c51e in pango_renderer_draw_glyphs () at /lib/x86_64-linux-gnu/libpango-1.0.so.0
#12 0x00007ffff75d0770 in pango_cairo_show_glyph_string () at /lib/x86_64-linux-gnu/libpangocairo-1.0.so.0
#13 0x00007ffff643c51e in pango_renderer_draw_glyphs () at /lib/x86_64-linux-gnu/libpango-1.0.so.0
#14 0x00007ffff643c5b3 in pango_renderer_draw_glyph_item () at /lib/x86_64-linux-gnu/libpango-1.0.so.0
#15 0x00007ffff6444e07 in pango_renderer_draw_layout_line () at /lib/x86_64-linux-gnu/libpango-1.0.so.0
#16 0x00007ffff6445415 in pango_renderer_draw_layout () at /lib/x86_64-linux-gnu/libpango-1.0.so.0
#17 0x00007ffff695b23a in gdk_draw_layout_with_colors () at /lib/x86_64-linux-gnu/libgdk-x11-2.0.so.0
#18 0x00007ffff695b4bd in gdk_draw_layout () at /lib/x86_64-linux-gnu/libgdk-x11-2.0.so.0
#19 0x00007ffff7cefff4 in () at /lib/x86_64-linux-gnu/libgtk-x11-2.0.so.0
#20 0x00007ffff7c5a3be in () at /lib/x86_64-linux-gnu/libgtk-x11-2.0.so.0
#21 0x00007ffff7c674d7 in () at /lib/x86_64-linux-gnu/libgtk-x11-2.0.so.0
#22 0x00007ffff7ad8c6c in g_closure_invoke () at /lib/x86_64-linux-gnu/libgobject-2.0.so.0
#23 0x00007ffff7af4564 in () at /lib/x86_64-linux-gnu/libgobject-2.0.so.0
#24 0x00007ffff7af5f66 in g_signal_emit_valist () at /lib/x86_64-linux-gnu/libgobject-2.0.so.0
#25 0x00007ffff7af67a3 in g_signal_emit () at /lib/x86_64-linux-gnu/libgobject-2.0.so.0
#26 0x00007ffff7d93024 in () at /lib/x86_64-linux-gnu/libgtk-x11-2.0.so.0
#27 0x00007ffff7be73cc in gtk_container_propagate_expose () at /lib/x86_64-linux-gnu/libgtk-x11-2.0.so.0
#28 0x00007ffff7be5ca3 in () at /lib/x86_64-linux-gnu/libgtk-x11-2.0.so.0
#29 0x00007ffff7c674d7 in () at /lib/x86_64-linux-gnu/libgtk-x11-2.0.so.0
#30 0x00007ffff7ad8c6c in g_closure_invoke () at /lib/x86_64-linux-gnu/libgobject-2.0.so.0
#31 0x00007ffff7af4564 in () at /lib/x86_64-linux-gnu/libgobject-2.0.so.0
#32 0x00007ffff7af5f66 in g_signal_emit_valist () at /lib/x86_64-linux-gnu/libgobject-2.0.so.0
#33 0x00007ffff7af67a3 in g_signal_emit () at /lib/x86_64-linux-gnu/libgobject-2.0.so.0
#34 0x00007ffff7d93024 in () at /lib/x86_64-linux-gnu/libgtk-x11-2.0.so.0
#35 0x00007ffff7be73cc in gtk_container_propagate_expose () at /lib/x86_64-linux-gnu/libgtk-x11-2.0.so.0
#36 0x00007ffff7bac4a7 in () at /lib/x86_64-linux-gnu/libgtk-x11-2.0.so.0
#37 0x00007ffff7be5ca3 in () at /lib/x86_64-linux-gnu/libgtk-x11-2.0.so.0
#38 0x00007ffff7c674d7 in () at /lib/x86_64-linux-gnu/libgtk-x11-2.0.so.0
#39 0x00007ffff7ad8c6c in g_closure_invoke () at /lib/x86_64-linux-gnu/libgobject-2.0.so.0
#40 0x00007ffff7af4564 in () at /lib/x86_64-linux-gnu/libgobject-2.0.so.0
#41 0x00007ffff7af5f66 in g_signal_emit_valist () at /lib/x86_64-linux-gnu/libgobject-2.0.so.0
#42 0x00007ffff7af67a3 in g_signal_emit () at /lib/x86_64-linux-gnu/libgobject-2.0.so.0
#43 0x00007ffff7d93024 in () at /lib/x86_64-linux-gnu/libgtk-x11-2.0.so.0
#44 0x00007ffff7be73cc in gtk_container_propagate_expose () at /lib/x86_64-linux-gnu/libgtk-x11-2.0.so.0
#45 0x00007ffff7be5ca3 in () at /lib/x86_64-linux-gnu/libgtk-x11-2.0.so.0
#46 0x00007ffff7bbea2b in () at /lib/x86_64-linux-gnu/libgtk-x11-2.0.so.0
#47 0x00007ffff7c674d7 in () at /lib/x86_64-linux-gnu/libgtk-x11-2.0.so.0
#48 0x00007ffff7ad8c6c in g_closure_invoke () at /lib/x86_64-linux-gnu/libgobject-2.0.so.0
#49 0x00007ffff7af4564 in () at /lib/x86_64-linux-gnu/libgobject-2.0.so.0
#50 0x00007ffff7af5f66 in g_signal_emit_valist () at /lib/x86_64-linux-gnu/libgobject-2.0.so.0
#51 0x00007ffff7af67a3 in g_signal_emit () at /lib/x86_64-linux-gnu/libgobject-2.0.so.0
#52 0x00007ffff7d93024 in () at /lib/x86_64-linux-gnu/libgtk-x11-2.0.so.0
#53 0x00007ffff7be73cc in gtk_container_propagate_expose () at /lib/x86_64-linux-gnu/libgtk-x11-2.0.so.0
--Type <RET> for more, q to quit, c to continue without paging--
#54 0x00007ffff7d70831 in () at /lib/x86_64-linux-gnu/libgtk-x11-2.0.so.0
#55 0x00007ffff7c674d7 in () at /lib/x86_64-linux-gnu/libgtk-x11-2.0.so.0
#56 0x00007ffff7ad8d2f in g_closure_invoke () at /lib/x86_64-linux-gnu/libgobject-2.0.so.0
#57 0x00007ffff7af4564 in () at /lib/x86_64-linux-gnu/libgobject-2.0.so.0
#58 0x00007ffff7af5f66 in g_signal_emit_valist () at /lib/x86_64-linux-gnu/libgobject-2.0.so.0
#59 0x00007ffff7af67a3 in g_signal_emit () at /lib/x86_64-linux-gnu/libgobject-2.0.so.0
#60 0x00007ffff7d93024 in () at /lib/x86_64-linux-gnu/libgtk-x11-2.0.so.0
#61 0x00007ffff7c671c3 in gtk_main_do_event () at /lib/x86_64-linux-gnu/libgtk-x11-2.0.so.0
#62 0x00007ffff69784c9 in () at /lib/x86_64-linux-gnu/libgdk-x11-2.0.so.0
#63 0x00007ffff6978449 in () at /lib/x86_64-linux-gnu/libgdk-x11-2.0.so.0
#64 0x00007ffff6978449 in () at /lib/x86_64-linux-gnu/libgdk-x11-2.0.so.0
#65 0x00007ffff696e155 in () at /lib/x86_64-linux-gnu/libgdk-x11-2.0.so.0
#66 0x00007ffff696e8e8 in gdk_window_process_all_updates () at /lib/x86_64-linux-gnu/libgdk-x11-2.0.so.0
#67 0x00007ffff7be5809 in () at /lib/x86_64-linux-gnu/libgtk-x11-2.0.so.0
#68 0x00007ffff694a409 in () at /lib/x86_64-linux-gnu/libgdk-x11-2.0.so.0
#69 0x00007ffff79dfc24 in g_main_context_dispatch () at /lib/x86_64-linux-gnu/libglib-2.0.so.0
#70 0x00007ffff7a346f8 in () at /lib/x86_64-linux-gnu/libglib-2.0.so.0
#71 0x00007ffff79df293 in g_main_loop_run () at /lib/x86_64-linux-gnu/libglib-2.0.so.0
#72 0x00007ffff7c642d2 in gtk_main () at /lib/x86_64-linux-gnu/libgtk-x11-2.0.so.0
#73 0x0000555555783e96 in I_PickIWad_Gtk(WadStuff*, int, bool, int) ()
#74 0x0000555555784067 in I_PickIWad(WadStuff*, int, bool, int) ()
#75 0x00005555557f23cc in FIWadManager::IdentifyVersion(TArray<FString, FString>&, char const*, char const*) ()
#76 0x00005555557f2a8f in FIWadManager::FindIWAD(TArray<FString, FString>&, char const*, char const*) ()
#77 0x00005555557f6d04 in D_DoomMain() ()
#78 0x000055555575db84 in main ()
(gdb)
SDL_Init has been called (the timer thread is running)...I wonder if it's an XInitThreads thing...?
Does it still behave if run against SDL-1.2 from git?
Does it still behave if run against SDL-1.2 from git?
This turned out to be a really good question! SDL-1.2 from git crashes exactly the same way.
(I guess I was using the default Ubuntu 1.2 package before...?)
...and yes, it's this commit that breaks it with SDL-1.2 from git: https://github.com/libsdl-org/SDL-1.2/commit/4c3097466bdf254a262ab7ffb72633992a892801
...and yes, it's this commit that breaks it with SDL-1.2 from git: libsdl-org/SDL-1.2@4c30974
How does that even interfere?
How does that even interfere?
It's crashing in a pthread_mutex_lock call here, with a NULL mutex:
#1 0x00007ffff682c50f in XrmQGetResource () at /lib/x86_64-linux-gnu/libX11.so.6
Which is this line of code:
https://github.com/mirror/libX11/blob/2b7598221d87049d03e9a95fcb541c37c8728184/src/Xrm.c#L2549
_XLockMutex looks like this:
And _XLockMutex_fn
is only non-NULL if you call XInitThreads:
https://github.com/mirror/libX11/blob/2b7598221d87049d03e9a95fcb541c37c8728184/src/locking.c#L603
So likely something in the GTK+ code, or Cairo, or Xlib, or whatever, is forgetting to create the mutex and it doesn't matter because if you don't call XInitThreads() it never tries to touch it.
Alternately: they initialized this stuff before calling SDL_Init, so it skipped creating the mutex, and then we called XInitThreads() after, which made it then try to use the mutex they never set up.
XInitThreads docs say it must be the first Xlib call you make, and this is exactly why, so I'm pretty sure that's what happened here.
Yeah, moving the gtk init call after SDL_Init in Zandronum's sources fixes it, both for SDL-1.2 and sdl12-compat.
diff -r b460d88f3a9e src/sdl/i_main.cpp
--- a/src/sdl/i_main.cpp Sun Aug 28 16:13:35 2022 -0400
+++ b/src/sdl/i_main.cpp Thu Sep 01 23:28:05 2022 -0400
@@ -263,10 +263,6 @@
// Note that the LANG environment variable is overridden by LC_*
setenv ("LC_NUMERIC", "C", 1);
-#ifndef NO_GTK
- GtkAvailable = gtk_init_check (&argc, &argv);
-#endif
-
setlocale (LC_ALL, "C");
Args = new DArgs(argc, argv);
@@ -302,6 +298,13 @@
atterm (SDL_Quit);
+ // Make sure gtk_init_check happens _after_ SDL_Init, so SDL will call
+ // XInitThreads() on X11, then GTK+ will talk to Xlib without leaving
+ // mutexes uncreated that the system is going to expect to be initialized.
+#ifndef NO_GTK
+ GtkAvailable = gtk_init_check (&argc, &argv);
+#endif
+
{
char viddriver[80];
I'll file a bug with them; it's a simple fix, but it's not our bug.
Bug filed with Zandronum: https://zandronum.com/tracker/view.php?id=4023
Zandronum has applied the patch! https://osdn.net/projects/zandronum/scm/hg/zandronum-stable/commits/a079616e5796d1300945766df2776605a1dbd771
Mentioned on https://docs.google.com/spreadsheets/d/1u8Rq3LVQYYgu28sBuxrZ371QolbiZu5z_LjENc4ddZs/edit#gid=0 ...
If using SDL 1.2, it doesn't crash. If you only have a single IWAD file (just the DOOM 1 data and not DOOM 2's), it won't show the iwad selector and thus won't crash (and runs very well!).