GZDoom seems a bit wonky under Debian Testing
Moderator: GZDoom Developers
Forum rules
Please don't bump threads here if you have a problem - it will often be forgotten about if you do. Instead, make a new thread here.
Please don't bump threads here if you have a problem - it will often be forgotten about if you do. Instead, make a new thread here.
- Graf Zahl
- Lead GZDoom+Raze Developer
- Posts: 49073
- Joined: Sat Jul 19, 2003 10:19 am
- Location: Germany
Re: GZDoom seems a bit wonky under Debian Testing
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.
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
- Posts: 2942
- Joined: Thu Jul 17, 2003 12:07 am
- Graphics Processor: ATI/AMD with Vulkan/Metal Support
Re: GZDoom seems a bit wonky under Debian Testing
Looking at what it does on Windows, I don't see why it couldn't be changed. Just copy it over and changeGraf Zahl wrote: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.
Code: Select all
OutputDebugStringA(errortext);
Code: Select all
fputs(errortext, stderr);
- Graf Zahl
- Lead GZDoom+Raze Developer
- Posts: 49073
- Joined: Sat Jul 19, 2003 10:19 am
- Location: Germany
Re: GZDoom seems a bit wonky under Debian Testing
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.
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
- Lead GZDoom+Raze Developer
- Posts: 49073
- Joined: Sat Jul 19, 2003 10:19 am
- Location: Germany
Re: GZDoom seems a bit wonky under Debian Testing
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.
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.
-
- Posts: 16
- Joined: Fri Oct 04, 2019 7:47 am
- Graphics Processor: ATI/AMD with Vulkan/Metal Support
- Location: Manchester; England
Re: GZDoom seems a bit wonky under Debian Testing
I know it's not really ready yet but I was curious and tried building the exit_cleanup branchGraf Zahl wrote:I just committed the cleanup to a separate 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
Being partially finished I expected it would crash when run - and it does!
Last edited by mwnn on Mon Oct 07, 2019 5:15 am, edited 1 time in total.
- Graf Zahl
- Lead GZDoom+Raze Developer
- Posts: 49073
- Joined: Sat Jul 19, 2003 10:19 am
- Location: Germany
Re: GZDoom seems a bit wonky under Debian Testing
Like I said, it's not ready yet.
-
- Posts: 16
- Joined: Fri Oct 04, 2019 7:47 am
- Graphics Processor: ATI/AMD with Vulkan/Metal Support
- Location: Manchester; England
Re: GZDoom seems a bit wonky under Debian Testing
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:
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:
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?
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
Code: Select all
Path=/usr/share/soundfonts
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?
- Attachments
-
- gzdoomlogs.zip
- Mostly sound related (?)
- (10.14 KiB) Downloaded 30 times
- Chris
- Posts: 2942
- Joined: Thu Jul 17, 2003 12:07 am
- Graphics Processor: ATI/AMD with Vulkan/Metal Support
Re: GZDoom seems a bit wonky under Debian Testing
And I can report GZDoom no longer seems to crash on exit with the latest OpenAL Soft master either.
- Graf Zahl
- Lead GZDoom+Raze Developer
- Posts: 49073
- Joined: Sat Jul 19, 2003 10:19 am
- Location: Germany
Re: GZDoom seems a bit wonky under Debian Testing
That alone was worth all the work.
I never liked that particular mess and it's good to know that it is finally gone.
I never liked that particular mess and it's good to know that it is finally gone.
- drfrag
- Vintage GZDoom Developer
- Posts: 3141
- Joined: Fri Apr 23, 2004 3:51 am
- Location: Spain
- Contact:
Re: GZDoom seems a bit wonky under Debian Testing
Is all this compatible with XP? At least there's a workaround in LZDoom now.
Re: GZDoom seems a bit wonky under Debian Testing
@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.
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.
-
- Posts: 16
- Joined: Fri Oct 04, 2019 7:47 am
- Graphics Processor: ATI/AMD with Vulkan/Metal Support
- Location: Manchester; England
Re: GZDoom seems a bit wonky under Debian Testing
I wasn't aware that what I was posting was useless - those are the instructions which are posted on the wiki page._mental_ wrote:@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.
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.
Re: GZDoom seems a bit wonky under Debian Testing
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.
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
-
- Posts: 16
- Joined: Fri Oct 04, 2019 7:47 am
- Graphics Processor: ATI/AMD with Vulkan/Metal Support
- Location: Manchester; England
Re: GZDoom seems a bit wonky under Debian Testing
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: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.
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)
I believe I can put set style enabled off into /etc/gdb/gdbinit - hopefully that will make the logs more bearable.
Re: GZDoom seems a bit wonky under Debian Testing
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.
Those logs are still crap. I would prefer if you post output copied from terminal.