[Fixed] "gzdoom" received signal SIGFPE, Arithmetic exception

Bugs that have been investigated and resolved somehow.

Moderator: GZDoom Developers

"gzdoom" received signal SIGFPE, Arithmetic exception

Postby mwnn » Wed Oct 09, 2019 4:27 pm

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
Attachments
gzdoomvulkan.log
with vulkan turned on
(14.38 KiB) Downloaded 4 times
gzdoom.log
(11.06 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" received signal SIGFPE, Arithmetic exception

Postby Graf Zahl » Wed Oct 09, 2019 4:55 pm

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

Re: "gzdoom" received signal SIGFPE, Arithmetic exception

Postby mwnn » Wed Oct 09, 2019 5:05 pm

Graf Zahl wrote: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.
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" received signal SIGFPE, Arithmetic exception

Postby Rachael » Wed Oct 09, 2019 5:24 pm

mwnn wrote: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.
User avatar
Rachael
Webmaster
 
Joined: 13 Jan 2004
Discord: Rachael#3767
Twitch ID: madamerachelle
Github ID: madame-rachelle
Graphics Processor: nVidia with Vulkan support

Re: "gzdoom" received signal SIGFPE, Arithmetic exception

Postby mwnn » Fri Oct 11, 2019 7:34 am

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 8-)
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.
Spoiler:

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+
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" received signal SIGFPE, Arithmetic exception

Postby _mental_ » Fri Oct 11, 2019 7:41 am

What’s the version of FluidSynth that crashes with this sound font?
_mental_
 
 
 
Joined: 07 Aug 2011

Re: "gzdoom" received signal SIGFPE, Arithmetic exception

Postby mwnn » Fri Oct 11, 2019 8:33 am

_mental_ wrote: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 :oops:
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

Spoiler:
Attachments
fluidsynth2.log
a second one - might be better than the first.
(9.42 KiB) Downloaded 6 times
fluidsynth.log
(7.2 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" received signal SIGFPE, Arithmetic exception

Postby mwnn » Fri Oct 11, 2019 2:09 pm

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.
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" received signal SIGFPE, Arithmetic exception

Postby _mental_ » Mon Oct 14, 2019 4:54 am

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

Re: "gzdoom" received signal SIGFPE, Arithmetic exception

Postby Graf Zahl » Mon Oct 14, 2019 5:12 am

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

Re: "gzdoom" received signal SIGFPE, Arithmetic exception

Postby mwnn » Mon Oct 14, 2019 5:34 am

_mental_ wrote:Despite a completely misleading title of the topic, it reports a real problem
You lot are always telling me off! :lol:
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.
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" received signal SIGFPE, Arithmetic exception

Postby _mental_ » Mon Oct 14, 2019 8:05 am

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

Re: "gzdoom" received signal SIGFPE, Arithmetic exception

Postby Graf Zahl » Mon Oct 14, 2019 8:36 am

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

Re: "gzdoom" received signal SIGFPE, Arithmetic exception

Postby _mental_ » Mon Oct 14, 2019 9:17 am

Graf Zahl wrote: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.

Spoiler: Callstack of main thread
Spoiler: Callstack of streaming thread

You can comment this 100 ms wait to trigger the crash much faster.
_mental_
 
 
 
Joined: 07 Aug 2011

Re: "gzdoom" received signal SIGFPE, Arithmetic exception

Postby Graf Zahl » Mon Oct 14, 2019 12:21 pm

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

Next

Return to Closed Bugs

Who is online

Users browsing this forum: Proydoha and 0 guests