GZDoom seems a bit wonky under Debian Testing

[Graf Zahl]

The problem is more that some stuff needs to be properly shut down to avoid losing data. You can either do that by unwinding and shut things down in the right place or by installing exit handlers.
Just terminating won't shut down all these things - but calling exit handlers without unwinding first will leave a lot of unknown and potentially important local context behind - and this can also cause problems.

So, without changing I_FatalError I cannot do a proper unwind. If I could do that I could remove the exit handlers by putting a single catch around D_DoomMain and perform a controlled exit.

[Chris]

So, without changing I_FatalError I cannot do a proper unwind. If I could do that I could remove the exit handlers by putting a single catch around D_DoomMain and perform a controlled exit.

Looking at what it does on Windows, I don't see why it couldn't be changed. Just copy it over and change

Code: Select all

OutputDebugStringA(errortext);

to

Code: Select all

fputs(errortext, stderr);

It will lose the gtk/kde/sdl dialog it currently would throw up in that call (throwing it to stderr instead), but if the goal is to unify fatal error handling, that message box can be handled in a way more similar to Windows.

[Graf Zahl]

That's the general idea I already had but wasn't able to implement yet.
Actually, the fact that all the exception catching is in system code is really dumb, it needlessly complicates things. Those in-game errors should be dealt with in the outermost function which knows about the game and that is D_DoomMain.

If something decides to throw an exception in the code called from system startup or system shutdown it should just terminate, or catch it itself.

[Graf Zahl]

I just committed the cleanup to a separate branch. There is no more exception handling in the startup code, the main handler is in D_DoomMain.
Now that there is a single defined exit point, the next step will be do get rid of atterm and do a controlled shutdown when D_DoomMain exits - and all real exits that cannot communicate directly with D_DoomMain should use a special ExitException I will add next.

Let's hope that these shutdown problems get resolved by that. It's about time that this Boom inherited madness goes away.

[mwnn]

I just committed the cleanup to a separate branch

I know it's not really ready yet but I was curious and tried building the exit_cleanup branch

Code: Select all

[ 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

This must be the offending bit. 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!

[Graf Zahl]

Like I said, it's not ready yet.

[mwnn]

I noticed the changes made in the exit_cleanup branch were merged into master 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

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 Vulkan turned on and that appears to work just as well as OpenGL; didn't notice any obvious graphical issues.
Gallium HUD reports my Phenom II's usage as being around 15% with OpenGL so that should be a bit less with Vulkan; the Vulkan overlay layer doesn't report that yet. I know when I use DXVK it outperforms WineD3D 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: Select all

gdb gzdoom

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 Fatboy soundfont:

Code: Select all

Path=/usr/share/soundfonts

You're probably sick of reading my crash logs by now so if you've had enough then that's fine too!
I'd say the game is very playable again - I don't have to get eyestrain from Chocolate Doom.

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?

[Chris]

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

[Graf Zahl]

That alone was worth all the work.

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

[drfrag]

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

[_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.

[mwnn]

@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.

I wasn't aware that what I was posting was useless - those are the instructions which are posted on the wiki page.

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 #1 #2

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.

[_mental_]

The described method is kinda OK. When it crash, i.e. receives SIGSEGV, use bt 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: Select all

set style enabled off

[mwnn]

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 backtrace 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: Select all

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) 

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 set style enabled off into /etc/gdb/gdbinit - hopefully that will make the logs more bearable.

[_mental_]

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.