"gzdoom" received signal SIGFPE, Arithmetic exception

[mwnn]

Let's start again shall we?
Hopefully the log is formatted correctly (set style sources off) and contains all the right info (gdb 8.3-1)

system: Debian Testing amd64
cpu: AMD Phenom II x4 955
memory: 8GB GSKILL DDR3
audio: VT1708S / [AMD/ATI] SBx00 Azalia (Intel HDA)
gpu: AMD R9 285 2GB / AMD Radeon R9 200 Series (TONGA, DRM 3.32.0, 5.2.0-3-amd64, LLVM 8.0.1)
mesa: Mesa 19.3.0-devel (git-555c0de8c6)
kernel: Linux debian 5.2.0-3-amd64 #1 SMP Debian 5.2.17-1 (2019-09-26) x86_64 GNU/Linux

gzdoom master branch 525d678
ultimate doom 1.9 DOOM.WAD c4fe9fd920207691a9f493668e0a2083

Compiled the latest.
Copied gzdoom, brightmaps.pk3, game_support.pk3, gzdoom.pk3, lights.pk3, fm_banks, soundfonts to ~/gzdoom
Run the game i.e: ./gzdoom
Exited the game via the main menu option
All in-game options are default (newly generated gzdoom.ini file)

Console prints *** Fatal Error *** Segmentation fault

I can reproduce this every time.
Video: https://drive.google.com/open?id=1pHS-E ... 65vri5RPcC

[Graf Zahl]

I'm sorry but you will have to look elsewhere. That stack trace is a bit weird, it looks like the graphics driver is crashing but leaves the system in a state where GZDoom's crashcatcher fails to handle this properly and crashes itself.

[mwnn]

I'm sorry but you will have to look elsewhere. That stack trace is a bit weird, it looks like the graphics driver is crashing but leaves the system in a state where GZDoom's crashcatcher fails to handle this properly and crashes itself.

OK. I'll make a post on gitlab and perhaps they can replicate.

There was a corruption issue with Medieval/Empire Total War which they fixed once I reported it. Generally speaking I find the system to be reliable under Linux.

[Rachael]

Generally speaking I find the system to be reliable under Linux.

You're using Debian Testing.

You should literally expect a rather decent degree of instability, and you must be cognizant of the fact that this can and will often taint your findings. I take every one of your reports with a grain of salt for this reason - while I have no doubt that there may be faults in GZDoom's code, reliably saying that GZDoom is at fault in any particular instance is completely out of the question in your case, since you're using a beta operating system to begin with.

I really think for some the issues you may be having, they should be tested under Debian Stable - just to be sure.

[mwnn]

I did test out Debian stable (buster) by installing it onto 16GB USB stick and booting from that; I believe the kernel was 4.19, mesa is 18.3.6 with llvm 7, other packages were a bit out-of-date.
I only tried the pre-made 4.2.1 deb package but that did appear to work OK.

As I've said I'm currently using Debian Testing (bullseye)
Linux debian 5.3.5-custom #1 SMP Fri Oct 11 08:55:52 BST 2019 x86_64 GNU/Linux
OpenGL renderer string: AMD Radeon R9 200 Series (TONGA, DRM 3.33.0, 5.3.5-custom, LLVM 8.0.1)
OpenGL core profile version string: 4.5 (Core Profile) Mesa 19.3.0-devel (git-aa75be05af)

With the most recent commits that were made a few hours ago; the game now exits cleanly.
So it looks all these recent changes have cracked it
You shouldn't end up with a wave of people wondering what's gone wrong in a few months time when these updates/packages filter down to Ubuntu, etc, which I why I thought I'd post in the first place.

---

Code: Select all

mwnn@debian:~/Git/gzdoom/_build$ gdb gzdoom
GNU gdb (Debian 8.3-1) 8.3
Copyright (C) 2019 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Type "show copying" and "show warranty" for details.
This GDB was configured as "x86_64-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
    <http://www.gnu.org/software/gdb/documentation/>.

For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from gzdoom...
(gdb) set logging on gzdoom.log
Copying output to gzdoom.log.
(gdb) run
Starting program: /home/mwnn/Git/gzdoom/_build/gzdoom 
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
[New Thread 0x7ffff5b8f700 (LWP 9008)]
GZDoom g4.3pre-247-gb68a9ebef - 2019-10-11 12:03:23 +0300 - SDL version
Compiled on Oct 11 2019

Thread 2 "gzdoom" received signal SIG33, Real-time event 33.
[Switching to Thread 0x7ffff5b8f700 (LWP 9008)]
futex_wait_cancelable (private=0, expected=0, futex_word=0x555556dfe6e0 <renderPool+256>) at ../sysdeps/unix/sysv/linux/futex-internal.h:88
88	../sysdeps/unix/sysv/linux/futex-internal.h: No such file or directory.
(gdb) c
Continuing.

M_LoadDefaults: Load system defaults.
W_Init: Init WADfiles.
 adding /home/mwnn/Git/gzdoom/_build/gzdoom.pk3, 608 lumps
 adding /home/mwnn/Git/gzdoom/_build/game_support.pk3, 2520 lumps
 adding ./DOOM.WAD, 2306 lumps
I_Init: Setting up machine state.
CPU Vendor ID: AuthenticAMD
  Name: AMD Phenom(tm) II X4 955 Processor
  Family 16 (16), Model 4, Stepping 2
  Features: SSE2 SSE3 3DNow! 3DNow!+ HyperThreading
V_Init: allocate screen.
S_Init: Setting up sound.
I_InitSound: Initializing OpenAL
[New Thread 0x7ffff51c4700 (LWP 9009)]
[Thread 0x7ffff51c4700 (LWP 9009) exited]
[New Thread 0x7ffff5143700 (LWP 9010)]
[Thread 0x7ffff5143700 (LWP 9010) exited]
[New Thread 0x7ffff5143700 (LWP 9011)]
  Opened device Built-in Audio Analog Stereo
[New Thread 0x7ffff4942700 (LWP 9012)]
[New Thread 0x7ffff4741700 (LWP 9013)]
  EFX enabled
ST_Init: Init startup screen.
Checking cmd-line parameters...
S_InitData: Load sound definitions.
G_ParseMapInfo: Load map definitions.
Texman.Init: Init texture manager.
ParseTeamInfo: Load team definitions.
LoadActors: Load actor definitions.
script parsing took 446.55 ms
R_Init: Init Doom refresh subsystem.
DecalLibrary: Load decals.
M_Init: Init menus.
[New Thread 0x7fffdf7d8700 (LWP 9014)]
[Thread 0x7fffdf7d8700 (LWP 9014) exited]
P_Init: Init Playloop state.
ParseSBarInfo: Loading custom status bar definition.
D_CheckNetGame: Checking network game status.
player 1 of 1 (1 nodes)
[New Thread 0x7fffdf7d8700 (LWP 9015)]
[New Thread 0x7fffdd8d0700 (LWP 9016)]
[New Thread 0x7fffdd0cf700 (LWP 9017)]
[New Thread 0x7fffdc8ce700 (LWP 9018)]
[New Thread 0x7fffbffff700 (LWP 9019)]
[New Thread 0x7fffbf7fe700 (LWP 9020)]
[New Thread 0x7fffbeffd700 (LWP 9021)]
[New Thread 0x7fffbe7fc700 (LWP 9022)]
[New Thread 0x7fffbdffb700 (LWP 9023)]
[New Thread 0x7fffbd7fa700 (LWP 9024)]
[New Thread 0x7fffbcdf9700 (LWP 9025)]
[Thread 0x7fffbcdf9700 (LWP 9025) exited]
[New Thread 0x7fffbcdf9700 (LWP 9026)]
[Thread 0x7fffbcdf9700 (LWP 9026) exited]
Using video driver x11
[New Thread 0x7fffbcdf9700 (LWP 9027)]
[Thread 0x7fffbcdf9700 (LWP 9027) exited]
[New Thread 0x7fffbcdf9700 (LWP 9028)]
[Thread 0x7fffbcdf9700 (LWP 9028) exited]
[New Thread 0x7fffbcdf9700 (LWP 9029)]
GL_VENDOR: X.Org
GL_RENDERER: AMD Radeon R9 200 Series (TONGA, DRM 3.33.0, 5.3.5-custom, LLVM 8.0.1)
GL_VERSION: 4.5 (Core Profile) Mesa 19.3.0-devel (git-aa75be05af) (Core profile)
GL_SHADING_LANGUAGE_VERSION: 4.50

Max. texture size: 16384
Max. texture units: 32
Max. varying: 128
Max. combined shader storage blocks: 40
Max. vertex shader storage blocks: 8
Resolution: 640 x 480
[New Thread 0x7fff9d4f7700 (LWP 9030)]
[New Thread 0x7fff9caf6700 (LWP 9031)]
[Thread 0x7fff9d4f7700 (LWP 9030) exited]
[Thread 0x7ffff4741700 (LWP 9013) exited]
[Thread 0x7ffff4942700 (LWP 9012) exited]
[Thread 0x7ffff5143700 (LWP 9011) exited]
[Thread 0x7fffbcdf9700 (LWP 9029) exited]
[Thread 0x7fffbe7fc700 (LWP 9022) exited]
[Thread 0x7fffbeffd700 (LWP 9021) exited]
[Thread 0x7fffbf7fe700 (LWP 9020) exited]
[Thread 0x7fffbd7fa700 (LWP 9024) exited]
[Thread 0x7fffbdffb700 (LWP 9023) exited]
[Thread 0x7fff9caf6700 (LWP 9031) exited]
[Thread 0x7fffdd0cf700 (LWP 9017) exited]
[Thread 0x7fffdd8d0700 (LWP 9016) exited]
[Thread 0x7fffbffff700 (LWP 9019) exited]
[Thread 0x7fffdc8ce700 (LWP 9018) exited]
[Thread 0x7fffdf7d8700 (LWP 9015) exited]
[Thread 0x7ffff5b8f700 (LWP 9008) exited]
[Inferior 1 (process 9004) exited normally]
(gdb) 

As far as the logs with fluidsynth are concerned those crashes were only occurring after I loaded up the third-party soundfont.
If that still occurs then I'll describe the issue in it's own topic; it is a rather large soundfont so perhaps it's the cause of the problem.
I know a lot of people like to use FLAC recordings from a real Roland SC-55 but I like to use that soundfont in ScummVM, other SDL based games, etc - sounds great to me.
Back in the not so good old days it would've been Windows 3.1 & DOS on an Compaq laptop with Adlib or PC speaker and before that the Amiga 500+

[_mental_]

What’s the version of FluidSynth that crashes with this sound font?

[mwnn]

What’s the version of FluidSynth that crashes with this sound font?

fluidsynth 1.1.11-4 amd64
libfluidsynth1:amd64 1.1.11-4 amd64

But I'll test that out in much more detail rather than just posting random crash logs
It might not occur with the latest git master - haven't tried yet.
Don't think it bombs with the included gzdoom soundfont.

Edit: Very quickly tried it - so it's just the console output for now.
My non-programming opinion is that it must be going over whatever limits have been set - just look at the size of it 315MB vs 140MB FluidR3.
You don't officially support it so it's not the end of the world; it tends to crash in the main menu if left idle and not mid-level.

Edit2: Didn't take long for me to break it again - sorry ladies and gents.
Attached a log; let me know if it's inadequate.
Playing fullscreen, I can tell when it goes as the Gallium_HUD stops updating.
I don't recall it ever happening whilst playing a normal level - indeed I could probably play several whilst recording the screen.
https://drive.google.com/file/d/19kcqzX ... sp=sharing
https://imgur.com/m6XMFVM.png

---

Code: Select all

GZDoom g4.3pre-247-gb68a9ebef - 2019-10-11 12:03:23 +0300 - SDL version
Compiled on Oct 11 2019
M_LoadDefaults: Load system defaults.
Please select a game wad (or 0 to exit):
1. The Ultimate DOOM (DOOM)
2. Heretic: Shadow of the Serpent Riders (HERETIC)
3. Hexen: Beyond Heretic (HEXEN)
4. Hexen: Deathkings of the Dark Citadel (HEXDD)
Which one? 1
W_Init: Init WADfiles.
 adding /home/mwnn/GOG/gzdoom/gzdoom.pk3, 608 lumps
 adding /home/mwnn/GOG/gzdoom/game_support.pk3, 2520 lumps
 adding ./DOOM.WAD, 2306 lumps
I_Init: Setting up machine state.
CPU Vendor ID: AuthenticAMD
  Name: AMD Phenom(tm) II X4 955 Processor
  Family 16 (16), Model 4, Stepping 2
  Features: SSE2 SSE3 3DNow! 3DNow!+ HyperThreading
V_Init: allocate screen.
S_Init: Setting up sound.
I_InitSound: Initializing OpenAL
  Opened device Built-in Audio Analog Stereo
  EFX enabled
ST_Init: Init startup screen.
Checking cmd-line parameters...
S_InitData: Load sound definitions.
G_ParseMapInfo: Load map definitions.
Texman.Init: Init texture manager.
ParseTeamInfo: Load team definitions.
LoadActors: Load actor definitions.
script parsing took 443.55 ms
R_Init: Init Doom refresh subsystem.
DecalLibrary: Load decals.
M_Init: Init menus.
P_Init: Init Playloop state.
ParseSBarInfo: Loading custom status bar definition.
D_CheckNetGame: Checking network game status.
player 1 of 1 (1 nodes)
Using video driver x11
GL_VENDOR: X.Org
GL_RENDERER: AMD Radeon R9 200 Series (TONGA, DRM 3.33.0, 5.3.5-custom, LLVM 8.0.1)
GL_VERSION: 4.5 (Core Profile) Mesa 19.3.0-devel (git-aa75be05af) (Core profile)
GL_SHADING_LANGUAGE_VERSION: 4.50

Max. texture size: 16384
Max. texture units: 32
Max. varying: 128
Max. combined shader storage blocks: 40
Max. vertex shader storage blocks: 8
Resolution: 640 x 480
fluidsynth: warning: Failed to pin the sample data to RAM; swapping is possible.
fluidsynth: warning: Failed to pin the sample data to RAM; swapping is possible.
malloc_consolidate(): invalid chunk size
Aborted

[mwnn]

I thought it might be worth noting that the author of that soundfont posts on the scummvm forums.
He's also a released cut down version of the Fatboy soundfont - the UHD3 soundfont which is a mere 64MB.
There's some sound samples and links on the first page and he talks about both through the whole thread.

[_mental_]

Despite a completely misleading title of the topic, it reports a real problem.

There is a race condition between main and streaming threads.
MIDI device can be in process of destruction on the main thread while streaming one asks this MIDI device to fill a buffer with new data.
It's hard to understand the issue without seeing all related code in the debugger.

Previously, it worked because stream was closed by MIDI device. Now, it is closed by the backend without any synchronization with the device.
So, calling MIDIStreamer::Stop() from MIDIStreamer::IsPlaying() is no longer correct.
Moreover, any call to MusInfo::Stop() with its stream still registered in the backend is potentially dangerous.

Removal of these calls from MIDIStreamer::IsPlaying() will fix this particular crash, but this doesn't fix the problem in general.

[Graf Zahl]

I think the best option would be a mutex on the outward facing interface of the music code - of course this means that the interface should not involve any direct virtual calls but go through wrapper functions instead. Otherwise the synchronization needs to be in too many places.

I cannot really say this surprises me because the entire self-driving design in the old code was like a house of cards.

[mwnn]

Despite a completely misleading title of the topic, it reports a real problem

You lot are always telling me off!
The topic title made perfect sense when I wrote the topic.
You've solved the serious crashing in the previous (closed) topic with the exit_cleanup changes.
The SIGFPE Arithmetic exception which occurs after exiting the game (topic title) was solved with the SDL error + Linux crash handler changes.

The fluidsynth issue only seems to manifest itself with the soundfont.
You did ask for the fluidsynth version I had installed and it's the final release of fluidsynth 1.xx.
We've just carried on and have not changed the topic title or made a new topic.

If the fluidsynth related bugs are solved then gzdoom 4.2.2 / 4.3 (?) will be as robust as a german panzer.
I was able to play through the entire first episode of Heretic yesterday using Vulkan without too much trouble so I must be finding fringe issues - the sort of bug that affects 1 in 100 or triggers under certain rare conditions.
I've noticed you've already added changes for fluidsynth 2.xx.
I'm confident that you'll come up with a solution in any case.

[_mental_]

I think the best option would be a mutex on the outward facing interface of the music code - of course this means that the interface should not involve any direct virtual calls but go through wrapper functions instead. Otherwise the synchronization needs to be in too many places.

Probably, I didn't explain the problem well. Like I said, it's quite hard to grasp it without debugger.
Everything is fine with synchronization in the backend and client code.

The main issue is with responsibility. MIDIStreamer can shutdown MIDI device by itself, client code can do this too via S_StopMusic() function.
In the former case, client can has no indication that device is gone and stream should be closed. Actually, stream needs to be closed before device's destruction.
That's what I meant when blaming MIDIStreamer::IsPlaying() as a source of race condition.

[Graf Zahl]

Yes, right. Obviously, IsPlaying may not do this thing - it's nasty. Obviously the function may stop the playback but it must not, under any circumstances delete it.
It should merely return the current status and let the caller perform the shutdown instead.
I must have overlooked this particular piece of nastiness, it was things like this that made me do the refactor in the first place. Thanks to such internal antics the code was basically not reusable.

But looking at the code, where does it crash? It looks to me that at some point the MIDI streamer fails to validate its internal state. If its internal player state got deleted it should play silence instead.

[_mental_]

But looking at the code, where does it crash? It looks to me that at some point the MIDI streamer fails to validate its internal state. If its internal player state got deleted it should play silence instead.

When the title music stops, the main thread deletes MIDI device when Stop() is called from IsPlaying().
The corresponding stream inside the backend is still registered. The background streaming thread is still processing it regularly.

---

Code: Select all

MIDIStreamer::Stop() at music_midi.cpp:558
MIDIStreamer::IsPlaying() at music_midi.cpp:573
S_UpdateMusic() at s_music.cpp:240
D_DoomLoop() at d_main.cpp:1047
D_DoomMain_Internal() at d_main.cpp:2801
D_DoomMain() at d_main.cpp:2818

---

Code: Select all

fluid_synth_write_float()
FluidSynthMIDIDevice::ComputeOutput() at music_fluidsynth_mididevice.cpp:342
SoftSynthMIDIDevice::ServiceStream() at music_softsynth_mididevice.cpp:386
MIDIStreamer::ServiceStream() at music_midi.cpp:991
FillStream() at s_music.cpp:129
OpenALSoundStream::Process() at oalsound.cpp:441
OpenALSoundRenderer::BackgroundProc() at oalsound.cpp:959

You can comment this 100 ms wait to trigger the crash much faster.

[Graf Zahl]

Well, in that case the only solution is to use a mutex to synchronize Stop() with ServiceStream() because obviously, Stop() may not be called when the device is busy doing stuff.
But I think this needs to be done outside the worker functions, it may also cause problems with non-MIDI music.