ZDoom

Linux crash reporter should work better now.

Linux crash handler still requires some attention. I’ll take a look at it soon.

[quote="drfrag"]Is all this compatible with XP? :) At least there's a workaround in LZDoom now.[/quote]

Nothing I did depends on any OS, it was mainly consolidation of the existing error handling in the backends and to explicitly call the cleanup code when quitting instead of depending on exit handlers to call it.

Let's cut this short: All the logs I have seen so far point to a system-side problem, or if _mental_ is correct, user error. If you cannot produce anything useful in the next 24 hours I'm going to close this.

But why do you use c (continue) command? You should do bt (backtrace) right after the first break into debugger.
Those logs are still crap. I would prefer if you post output copied from terminal.

Thread 1 "gzdoom" received signal SIGFPE, Arithmetic exception.
[Switching to Thread 0x7ffff5b954c0 (LWP 19971)]
0x00007ffff780ad09 in pthread_barrier_destroy (barrier=0x7fffffffdc80)
    at pthread_barrier_destroy.c:39
39	pthread_barrier_destroy.c: No such file or directory.
(gdb) c
Continuing.


*** Fatal Error ***

Thread 1 "gzdoom" received signal SIGSEGV, Segmentation fault.
0x0000555555a76670 in TArray<FString, FString>::Size (this=0x0)
    at /home/user/gzdoom/src/utility/tarray.h:500
500	/home/user/gzdoom/src/utility/tarray.h: No such file or directory.
(gdb) c
Continuing.


*** Fatal Error ***

Thread 1 "gzdoom" received signal SIGSEGV, Segmentation fault.
0x0000555555a76670 in TArray<FString, FString>::Size (this=0x0)
    at /home/user/gzdoom/src/utility/tarray.h:500
500	in /home/user/gzdoom/src/utility/tarray.h
(gdb) 

As you wish I'll separate reports into their own topics rather than under the umbrella of this one.
I won't make any further posts in this topic.

I've been compiling debug builds and typing [b]backtrace[/b] at the (gdb) prompt.
Maybe I've been typing that command at the wrong time - perhaps when it says SIGFPE instead of SIGSEGV i.e:
[code]Thread 1 "gzdoom" received signal SIGFPE, Arithmetic exception.
[Switching to Thread 0x7ffff5b954c0 (LWP 19971)]
0x00007ffff780ad09 in pthread_barrier_destroy (barrier=0x7fffffffdc80)
at pthread_barrier_destroy.c:39
39 pthread_barrier_destroy.c: No such file or directory.
(gdb) c
Continuing.


*** Fatal Error ***

Thread 1 "gzdoom" received signal SIGSEGV, Segmentation fault.
0x0000555555a76670 in TArray<FString, FString>::Size (this=0x0)
at /home/user/gzdoom/src/utility/tarray.h:500
500 /home/user/gzdoom/src/utility/tarray.h: No such file or directory.
(gdb) c
Continuing.


*** Fatal Error ***

Thread 1 "gzdoom" received signal SIGSEGV, Segmentation fault.
0x0000555555a76670 in TArray<FString, FString>::Size (this=0x0)
at /home/user/gzdoom/src/utility/tarray.h:500
500 in /home/user/gzdoom/src/utility/tarray.h
(gdb)
[/code]Sometimes SIGSEGV will be printed numerous times and if I keep hitting c (to continue) and don't do a backtrace then it will kick me back to a normal prompt.

I believe I can put [i]set style enabled off[/i] into [b]/etc/gdb/gdbinit[/b] - hopefully that will make the logs more bearable.

set style enabled off

The described method is kinda OK. When it crash, i.e. receives SIGSEGV, use [b]bt[/b] command to print the current callstack.

The problem is you reported several issues in the same topic.
Three logs are different crashes inside FluidSynth library.
Four reports don’t have stack traces at all.

Also, try the following GDB command to avoid those damn escape sequences in the log.[code]set style enabled off[/code]

[quote="_mental_"]@mwnn: Posting a bunch of unrelated logs, without a callstacks and polluted with escape sequences, isn’t the best idea.
You need to find out a list of distinct issues, and to report each of them to a separate topic with a readable stack trace.[/quote]I wasn't aware that what I was posting was useless - those are the instructions which are [url=https://zdoom.org/wiki/Compile_GZDoom_on_Linux#Developing]posted on the wiki page[/url].

What method or command should I use to capture something meaningful?

seg faults/crashing/undefined behaviour isn't easily replicated by posting a save file, screenshot or video as with a eduke32 bug I posted about recently [url=https://forums.duke4.net/topic/10691-dukes-ride-is-missing-linux/]#1[/url] [url=https://drive.google.com/file/d/1oV16xmCb-HC_sF5dK-qJFOegqJOX8WY6/view?usp=sharing]#2[/url]

I can separate each bug into it's own topic easily enough with clear steps on what I'm using and how I've got there.

@mwnn: Posting a bunch of unrelated logs, without a callstacks and polluted with escape sequences, isn’t the best idea.
You need to find out a list of distinct issues, and to report each of them to a separate topic with a readable stack trace.

Is all this compatible with XP? :) At least there's a workaround in LZDoom now.

That alone was worth all the work.

I never liked that particular mess and it's good to know that it is finally gone.

And I can report GZDoom no longer seems to crash on exit with the latest OpenAL Soft master either.

gdb gzdoom

Path=/usr/share/soundfonts

I noticed the changes made in the [b]exit_cleanup branch[/b] were merged into [b]master[/b] with some extra fixes which looks to have solved it.
I'm a bit surprised that it hadn't been reported earlier; I believe anyone with a GCN card (HD 7000 or newer) would've been affected.
Great stuff - I didn't think it would take you clever lot long to fix it :wub:

Now able to launch the game, make changes to the in-game options and exit with the options being preserved.
I played through a few levels of Heretic with [i]Vulkan[/i] turned on and that appears to work just as well as [i]OpenGL[/i]; didn't notice any obvious graphical issues.
[i]Gallium HUD[/i] reports my Phenom II's usage as being around 15% with [i]OpenGL[/i] so that should be a bit less with Vulkan; the [url=https://gitlab.freedesktop.org/mesa/mesa/blob/master/src/vulkan/overlay-layer/README]Vulkan overlay layer[/url] doesn't report that yet. I know when I use [i]DXVK[/i] it outperforms [i]WineD3D[/i] by far.
Lovely for anyone that can use it especially for all these cheap embedded devices which are everywhere now.

I'm attaching a zip of some more logs. I've launched the game with:
[code]gdb gzdoom[/code]
And left it idle in the menu for a brief amount of time. The only change I've made it to edit ~/.gzdoom.ini and add the location of the [url=https://fatboy.site/]Fatboy[/url] soundfont:
[code]Path=/usr/share/soundfonts[/code]You're probably sick of reading my crash logs by now so if you've had enough then that's fine too! :D
I'd say the game is very playable again - I don't have to get eyestrain from [i]Chocolate Doom[/i].

p.s.
Any chance of more sensible/modern default key bindings i.e. WASD instead of arrow keys, vertical mouse movement = 0.
Perhaps the game could check if SDL_SOUNDFONTS is set and read the soundfont path from there?

Like I said, it's not ready yet.

[ 51%] Building CXX object src/CMakeFiles/zdoom.dir/posix/sdl/sdlglvideo.cpp.o
[ 51%] Building CXX object src/CMakeFiles/zdoom.dir/posix/sdl/st_start.cpp.o
/home/user/gzdoom/src/posix/sdl/i_system.cpp: In function 'void Linux_I_FatalError(const char*)':
/home/user/gzdoom/src/posix/sdl/i_system.cpp:129:3: error: 'I_FatalError_Gtk' was not declared in this scope; did you mean 'I_ShowFatalError_Gtk'?
  129 |   I_FatalError_Gtk(errortext);
      |   ^~~~~~~~~~~~~~~~
      |   I_ShowFatalError_Gtk
[ 51%] Building CXX object src/CMakeFiles/zdoom.dir/posix/unix/i_specialpaths.cpp.o
make[2]: *** [src/CMakeFiles/zdoom.dir/build.make:188: src/CMakeFiles/zdoom.dir/posix/sdl/i_system.cpp.o] Error 1
make[2]: *** Waiting for unfinished jobs....
make[1]: *** [CMakeFiles/Makefile2:1571: src/CMakeFiles/zdoom.dir/all] Error 2
make: *** [Makefile:130: all] Error 2

[quote="Graf Zahl"]I just committed the cleanup to a separate branch[/quote]I know it's not really ready yet but I was curious and tried building the [b]exit_cleanup branch[/b]
[code][ 51%] Building CXX object src/CMakeFiles/zdoom.dir/posix/sdl/sdlglvideo.cpp.o
[ 51%] Building CXX object src/CMakeFiles/zdoom.dir/posix/sdl/st_start.cpp.o
/home/user/gzdoom/src/posix/sdl/i_system.cpp: In function 'void Linux_I_FatalError(const char*)':
/home/user/gzdoom/src/posix/sdl/i_system.cpp:129:3: error: 'I_FatalError_Gtk' was not declared in this scope; did you mean 'I_ShowFatalError_Gtk'?
129 | I_FatalError_Gtk(errortext);
| ^~~~~~~~~~~~~~~~
| I_ShowFatalError_Gtk
[ 51%] Building CXX object src/CMakeFiles/zdoom.dir/posix/unix/i_specialpaths.cpp.o
make[2]: *** [src/CMakeFiles/zdoom.dir/build.make:188: src/CMakeFiles/zdoom.dir/posix/sdl/i_system.cpp.o] Error 1
make[2]: *** Waiting for unfinished jobs....
make[1]: *** [CMakeFiles/Makefile2:1571: src/CMakeFiles/zdoom.dir/all] Error 2
make: *** [Makefile:130: all] Error 2
[/code][url=https://imgur.com/N5k9HBi.png]This must be the offending bit[/url]. The code compiles with that change applied - how nice of it to make such a good suggestion!
Being partially finished I expected it would crash when run - and it does!