[Fixed] GZDoom seems a bit wonky under Debian Testing

Bugs that have been investigated and resolved somehow.

Moderator: GZDoom Developers

GZDoom seems a bit wonky under Debian Testing

Postby mwnn » Fri Oct 04, 2019 9:38 am

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 allExpand view
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 allExpand view
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?
Attachments
gzdoom-crash.log
(40.01 KiB) Downloaded 8 times
CMakeOutput.log
(117.46 KiB) Downloaded 3 times
CMakeError.log
(17.48 KiB) Downloaded 3 times
mwnn
 
Joined: 04 Oct 2019
Location: Manchester; England
Operating System: Debian-like Linux (Debian, Ubuntu, Kali, Mint, etc) 64-bit
Graphics Processor: ATI/AMD with Vulkan Support

Re: GZDoom seems a bit wonky under Debian Testing

Postby drfrag » Fri Oct 04, 2019 12:27 pm

But what have you done? Is it the latest master?
User avatar
drfrag
I.R developer, I.R smart
Vintage GZDoom Developer
 
Joined: 23 Apr 2004
Location: Spain

Re: GZDoom seems a bit wonky under Debian Testing

Postby mwnn » Fri Oct 04, 2019 4:39 pm

drfrag wrote: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 allExpand view
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.
Attachments
mesa_build_options.txt
(760 Bytes) Downloaded 2 times
environment.txt
(850 Bytes) Downloaded 2 times
packages.txt
(254.38 KiB) Downloaded 2 times
mwnn
 
Joined: 04 Oct 2019
Location: Manchester; England
Operating System: Debian-like Linux (Debian, Ubuntu, Kali, Mint, etc) 64-bit
Graphics Processor: ATI/AMD with Vulkan Support

Re: GZDoom seems a bit wonky under Debian Testing

Postby mwnn » Fri Oct 04, 2019 6:24 pm

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/1eCcvvE_ULGh6wNBBhK1zqMOD1lM3T8gY?usp=sharing

Good night everyone :stuppor:
Attachments
gzdoom-crash.log
(33.35 KiB) Downloaded 6 times
mwnn
 
Joined: 04 Oct 2019
Location: Manchester; England
Operating System: Debian-like Linux (Debian, Ubuntu, Kali, Mint, etc) 64-bit
Graphics Processor: ATI/AMD with Vulkan Support

Re: GZDoom seems a bit wonky under Debian Testing

Postby _mental_ » Sat Oct 05, 2019 2:02 pm

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.
_mental_
 
 
 
Joined: 07 Aug 2011

Re: GZDoom seems a bit wonky under Debian Testing

Postby Chris » Sat Oct 05, 2019 5:11 pm

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.
User avatar
Chris
 
Joined: 17 Jul 2003

Re: GZDoom seems a bit wonky under Debian Testing

Postby drfrag » Sat Oct 05, 2019 5:50 pm

There was a PR for LZDoom to fix that crash on exit: https://github.com/drfrag666/gzdoom/com ... e15c143926
User avatar
drfrag
I.R developer, I.R smart
Vintage GZDoom Developer
 
Joined: 23 Apr 2004
Location: Spain

Re: GZDoom seems a bit wonky under Debian Testing

Postby Graf Zahl » Sat Oct 05, 2019 6:32 pm

Chris wrote: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.
User avatar
Graf Zahl
Lead GZDoom Developer
Lead GZDoom Developer
 
Joined: 19 Jul 2003
Location: Germany

Re: GZDoom seems a bit wonky under Debian Testing

Postby mwnn » Sat Oct 05, 2019 6:49 pm

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.
Attachments
lzdoomdebug.log.zip
Change to zip from xz
(24.41 KiB) Downloaded 3 times
Last edited by mwnn on Sun Oct 06, 2019 5:15 am, edited 1 time in total.
mwnn
 
Joined: 04 Oct 2019
Location: Manchester; England
Operating System: Debian-like Linux (Debian, Ubuntu, Kali, Mint, etc) 64-bit
Graphics Processor: ATI/AMD with Vulkan Support

Re: GZDoom seems a bit wonky under Debian Testing

Postby _mental_ » Sun Oct 06, 2019 12:49 am

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?
_mental_
 
 
 
Joined: 07 Aug 2011

Re: GZDoom seems a bit wonky under Debian Testing

Postby mwnn » Sun Oct 06, 2019 3:33 am

_mental_ wrote: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 allExpand view
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 ;)
Attachments
lzdoom-crash.log
(37.21 KiB) Downloaded 4 times
Last edited by mwnn on Sun Oct 06, 2019 4:10 am, edited 1 time in total.
mwnn
 
Joined: 04 Oct 2019
Location: Manchester; England
Operating System: Debian-like Linux (Debian, Ubuntu, Kali, Mint, etc) 64-bit
Graphics Processor: ATI/AMD with Vulkan Support

Re: GZDoom seems a bit wonky under Debian Testing

Postby drfrag » Sun Oct 06, 2019 3:51 am

Can that patch still be applied with the latest changes to the exit code?
User avatar
drfrag
I.R developer, I.R smart
Vintage GZDoom Developer
 
Joined: 23 Apr 2004
Location: Spain

Re: GZDoom seems a bit wonky under Debian Testing

Postby Chris » Sun Oct 06, 2019 4:35 am

drfrag wrote: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.
User avatar
Chris
 
Joined: 17 Jul 2003

Re: GZDoom seems a bit wonky under Debian Testing

Postby drfrag » Sun Oct 06, 2019 4:39 am

Do you mean you get a conflict or it doesn't compile?
User avatar
drfrag
I.R developer, I.R smart
Vintage GZDoom Developer
 
Joined: 23 Apr 2004
Location: Spain

Re: GZDoom seems a bit wonky under Debian Testing

Postby Chris » Sun Oct 06, 2019 5:23 am

drfrag wrote: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.

Graf Zahl wrote: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?
User avatar
Chris
 
Joined: 17 Jul 2003

Next

Return to Closed Bugs

Who is online

Users browsing this forum: Awario [RSS] and 0 guests