[Fixed] GZDoom seems a bit wonky under Debian Testing

Bugs that have been investigated and resolved somehow.

Moderator: GZDoom Developers

Re: GZDoom seems a bit wonky under Debian Testing

Postby Graf Zahl » Sun Oct 06, 2019 6:13 am

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.
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 Chris » Sun Oct 06, 2019 6:55 am

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

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 allExpand view
OutputDebugStringA(errortext);

to
Code: Select allExpand view
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.
User avatar
Chris
 
Joined: 17 Jul 2003

Re: GZDoom seems a bit wonky under Debian Testing

Postby Graf Zahl » Sun Oct 06, 2019 7:13 am

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.
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 Graf Zahl » Mon Oct 07, 2019 3:41 am

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.
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 » Mon Oct 07, 2019 4:16 am

Graf Zahl wrote: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 allExpand view
[ 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!
Last edited by mwnn on Mon Oct 07, 2019 6: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 Graf Zahl » Mon Oct 07, 2019 5:11 am

Like I said, it's not ready yet.
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 » Wed Oct 09, 2019 9:49 am

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 :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 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 allExpand view
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 allExpand view
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! :D
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 5 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 Chris » Wed Oct 09, 2019 12:11 pm

And I can report GZDoom no longer seems to crash on exit with the latest OpenAL Soft master either.
User avatar
Chris
 
Joined: 17 Jul 2003

Re: GZDoom seems a bit wonky under Debian Testing

Postby Graf Zahl » Wed Oct 09, 2019 1:15 pm

That alone was worth all the work.

I never liked that particular mess and it's good to know that it is finally gone.
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 drfrag » Wed Oct 09, 2019 1:33 pm

Is all this compatible with XP? :) At least there's a workaround in LZDoom now.
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 _mental_ » Wed Oct 09, 2019 2:05 pm

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

Re: GZDoom seems a bit wonky under Debian Testing

Postby mwnn » Wed Oct 09, 2019 2:08 pm

_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.
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.
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_ » Wed Oct 09, 2019 2:41 pm

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 allExpand view
set style enabled off
_mental_
 
 
 
Joined: 07 Aug 2011

Re: GZDoom seems a bit wonky under Debian Testing

Postby mwnn » Wed Oct 09, 2019 3:12 pm

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 allExpand view
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.
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_ » Thu Oct 10, 2019 12:08 am

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

PreviousNext

Return to Closed Bugs

Who is online

Users browsing this forum: Ahrefs [Bot] and 0 guests