GZDoom seems a bit wonky under Debian Testing

[mwnn]

Hello everyone. GZDoom is my go to choice for playing Doom based games so many thanks for working on it.
It seems like there's a bit of strange stuff going on when exiting the game - I see an error displayed, a crash log gets generated and the game won't generate a config file under ~/.config/gzdoom

Let's start at the beginning.
Following the instructions - I can either clone the latest master branch or use the latest release i.e:

Code: Select all

wget https://github.com/coelckers/gzdoom/archive/g4.2.1.tar.gz
git clone https://github.com/coelckers/gzdoom.git

I'll make a build directory, change into it, run cmake and do make -j4 i.e:

Code: Select all

mkdir _build && cd _build
cmake ..
make -j4

No problem so far!
Once that's finished I copy gzdoom, all the .pak files, soundfonts & fm_banks into a directory in my home folder; something like ~/gzdoom.
My WAD files for Doom, Hexen, Heretic are all the latest and match the md5 hashes.

The game starts without any problem and I can make changes to the various options - it's only when I close the game that it crashes and the settings are lost.
I've attached a few logs and other bits - hopefully that might give some insight.
https://imgur.com/Anyo7QC.png

I see lots of references to the video drivers - mesa bug? Anyone have any idea what might be going wrong here?

[drfrag]

But what have you done? Is it the latest master?

[mwnn]

But what have you done? Is it the latest master?

Yes, either the latest master or the v4.2.1 release.
I've literally started up the game by running ./gzdoom and shut it down again from the main menu option.
I can load any of the games (Doom, Heretic, etc) and play them but it always crashes as it exits.

Other than that I've not done much - a fairly standard Debian Testing system except I compile mesa-git (Mesa 19.3.0-devel (git-1b87f4058d)) and load those drivers by setting a few lines in /etc/environment.
I also like to use the Fatboy soundfont in SDL-based games like eduke32, nblood, openxcom, etc - as the samples sound as good as Roland hardware.

Maybe it only affects my R9 285 which is using the amdgpu/mesa driver?
Perhaps you could setup a chroot with debootstrap i.e:

Code: Select all

mkdir mychroot
debootstrap --arch=amd64 --variant=buildd testing mychroot http://deb.debian.org/debian

Compile the game and run the executable on whatever distro your using.

I've compiled and run gzdoom from source in the not too distant past without any problems so it's a bit of a strange one.
eduke32 and ion fury are both working normally (EDuke32 r8133) and I tried out Crispy Doom as well.
I'll can try some older releases and see if I get the same behaviour. I could try using the pre-made deb package as well.

[mwnn]

Wouldn't normally double post but it's approaching midnight here in the UK and I thought I'd just follow up on what I previously wrote.
Let's eliminate anything stupid that I possibly could've done.
And I'll record my screen whilst doing so.

-- 1st run --
I'll disable all my tweaks in the /etc/environment by commenting out those lines and reboot.
I'll revert to using the mesa drivers provided by Debian (Mesa 19.1.6)
I won't compile the code myself - I'll install the debian package that's provided on the github page here
I'll run the game once to get the missing WAD message - then copy the game files to ~/.config/gzdoom.
Then I'll run the game and exit it.

-- 2nd run --
I'll enable the mesa-git drivers again and reboot
Run the game again, exit it and see what happens.

https://drive.google.com/drive/folders/ ... sp=sharing

Good night everyone

[_mental_]

I don’t have Linux machine with AMD graphics, so I can only test with NVIDIA (proprietary drivers) and Intel (open source) running Ubuntu 18.04. Both work fine for me. I would say it’s something specific to the given AMD drivers.
If you are already building from sources, why don’t you build debug version? At least, it’s possible to match a location of crash to exact place in source code. Maybe this will give us some hints.

[Chris]

I can't help but notice it's crashing during call_terms at process exit. I wonder if it may be related to viewtopic.php?f=7&t=60020, as well as an issue I've been seeing with OpenAL Soft master. The problem in these cases is that the atexit/call_terms callback is run at an indeterminate time (more specifically, some global static C++ destructors may have run already). If that's the case, the proper fix seems to be to not rely on exit() to invoke call_terms, but have some wrapper that calls call_terms explicitly prior to exit.

[drfrag]

There was a PR for LZDoom to fix that crash on exit: https://github.com/drfrag666/gzdoom/com ... e15c143926

[Graf Zahl]

I can't help but notice it's crashing during call_terms at process exit. I wonder if it may be related to viewtopic.php?f=7&t=60020, as well as an issue I've been seeing with OpenAL Soft master. The problem in these cases is that the atexit/call_terms callback is run at an indeterminate time (more specifically, some global static C++ destructors may have run already). If that's the case, the proper fix seems to be to not rely on exit() to invoke call_terms, but have some wrapper that calls call_terms explicitly prior to exit.

Easier said than done - especially the POSIX code is not properly dealing with I_FatalError - it just exits instead of throwing an exception, calling all the exit handlers from an undefined broken state. Can anybody tell me why that is the case? If it just did an unwind like the Windows code it'd be a lot easier to fix this problem.

[mwnn]

I did test out lzdoom v3.82 today and there wasn't any difference however when I build lzdoom through drfrags fork - the game isn't crashing on exit, the config file is created and the settings are stored when I next run the game.
That's promising!

It's a bit late now but first thing tomorrow I'll continue.
If there's anything you want me to test just post your request and I'll read it in the morning.
I can compile debug mesa drivers or a debug build of the game or do an apitrace - if any of that would be useful.

[_mental_]

I would rather test LZDoom with an without the mentioned fix. If it crashes on exit without it, I will cherry pick it to GZDoom.
Remote investigation of crashes is a long and complicated process, so let’s start with something simple.
Can you build LZDoom from sources with that commit reverted?

[mwnn]

Can you build LZDoom from sources with that commit reverted?

Yes I should be able to do that.
I've set my git name and email, cloned the repo, reverted the commit (457dc8b), then compiled it as normal i.e:

Code: Select all

git config --global user.name "mwnn"
git config --global user.email "mwnn@mwnn.com"
git clone https://github.com/drfrag666/gzdoom/
git revert 457dc8b
mkdir _build && cd _build
cmake ..
make -j4

https://i.imgur.com/F1RqqVA.png (code reverted)
https://imgur.com/hFFwfM3.png (crashing as before)

As soon as you commit the change to gzdoom I'll build the latest master with it applied there

[drfrag]

Can that patch still be applied with the latest changes to the exit code?

[Chris]

Can that patch still be applied with the latest changes to the exit code?

No, it fails on the parts for installing the signal handlers in src/posix/sdl/i_main.cpp, and with adding the if (game_running) check before PClass::StaticShutdown() in src/d_main.cpp.

[drfrag]

Do you mean you get a conflict or it doesn't compile?

[Chris]

Do you mean you get a conflict or it doesn't compile?

Conflict, the patch doesn't apply due to those two hunks. I can say, however, I could apply it on a slightly older commit before the exit code changes, and it did fix the crash on exit with OpenAL Soft master. I'm currently building GZDoom master to see if it still crashes with the exit code changes and without the patch. I'll report back on that in a bit.

Easier said than done - especially the POSIX code is not properly dealing with I_FatalError - it just exits instead of throwing an exception, calling all the exit handlers from an undefined broken state. Can anybody tell me why that is the case? If it just did an unwind like the Windows code it'd be a lot easier to fix this problem.

I think the non-Windows system code was copied or adapted from the Windows system code before it was modified to use an exception, and never got changed itself when the Windows code was. Although, if I_FatalError can be called with the engine in an undefined broken state that shouldn't call the exit handlers, why would it throw an exception that can be caught and execute cleanup routines from stack unwinding (or worse, try to continue execution)? Shouldn't it just try to report the error and terminate on the spot with no exceptions or cleanup?