Fix SIGFPE on OS/2

[komh]

FluidSynth version

FluidSynth runtime version 2.4.6
Copyright (C) 2000-2025 Peter Hanappe and others.
Distributed under the LGPL license.
SoundFont(R) is a registered trademark of Creative Technology Ltd.

FluidSynth executable version 2.4.6
Sample type=double

Describe the bug

When playing a midi file like: fluidsynth mid-file.mid sf2-file.sf2

fluidsynth crashes due to SIGFPE.

Expected behavior

It should be play a mid file without any problems at all.

Steps to reproduce

Execute fluidsynth with DART audio drvier, -a dart like: fluidsynth mid-file.mid sf2-file.sf2 -a dart

Additional context

This is a regression of commit 1ef445e6d787c2c55dd739653c60deda0a36bedd.

Here is the patch.

0001-Fix-SIGFPE-on-OS-2.patch

From 1ffc2de2706ef7066aba75389769334a626433bb Mon Sep 17 00:00:00 2001
From: KO Myung-Hun <[email protected]>
Date: Wed, 21 May 2025 19:52:05 +0900
Subject: [PATCH] Fix SIGFPE on OS/2

This is due to a regression of commit 1ef445e.
---
 src/CMakeLists.txt | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/src/CMakeLists.txt b/src/CMakeLists.txt
index ed051a0e..395f8338 100644
--- a/src/CMakeLists.txt
+++ b/src/CMakeLists.txt
@@ -188,9 +188,9 @@ set ( libfluidsynth_SOURCES
     bindings/fluid_ladspa.h
 )
 if ( CMAKE_CXX_COMPILER_ID STREQUAL "Clang" OR CMAKE_CXX_COMPILER_ID STREQUAL "GNU" )
-  set_source_files_properties(rvoice/fluid_iir_filter.cpp PROPERTIES COMPILE_FLAGS "-fno-math-errno -ffast-math")
+  set_source_files_properties(rvoice/fluid_iir_filter_impl.cpp PROPERTIES COMPILE_FLAGS "-fno-math-errno -ffast-math")
 elseif ( CMAKE_CXX_COMPILER_ID STREQUAL "MSVC" )
-  set_source_files_properties(rvoice/fluid_iir_filter.cpp PROPERTIES COMPILE_FLAGS "/fp:fast")
+  set_source_files_properties(rvoice/fluid_iir_filter_impl.cpp PROPERTIES COMPILE_FLAGS "/fp:fast")
 endif ( )
 
 
-- 
2.42.0

[derselbst]

Thanks for the report. While we obviously missed to adjust the filename in the CMake file, I would like to understand the root cause of the SIGFPE, as these fast math flags might just be hiding a problem. Can you provide a MIDI and SF2 to reproduce this? Or did you perhaps specify enable-trap-on-fpe=1 when compiling with CMake?

[komh]

Sure. Here are the files:

sigfpe.zip

And I didn't use enable-trap-on-fpe=1.

[derselbst]

Thanks, I just gave that a quick try, but wasn't able to reproduce it. I'm on Linux though. I won't be able to investigate this further for the next three weeks. It would be very helpful if you could provide a stacktrace in the meantime, so that I can have a closer look after my return. Also, what's the CPU of your system? (I would like to know if the FPU is SSE or x87 based.)

[komh]

Here is the exception report used on OS/2:

682f3242-0362_01-FLUIDSYNTH-exceptq.txt

I think, FPU is SSE(Core i7) based and my system is running on VirtualBox.

[derselbst]

Thanks for this extensive crash report! I had a first chance to look into it. The crashing instruction is FSTP ST(0), which reads the value from the top fpu register stack and then stores it onto itself. A no-op, but in effect it pops the register stack and also validates if that number was a valid float number. Which it wasn't. Multiple fpu registers contain 7FFF FFFFFF0000000000 which is a long double NaN. Unfortunately I am not exactly sure where this value is coming from or what it represents. The callstack says it's happening in line 192, but this is a comment:

https://github.com/FluidSynth/fluidsynth/blob/v2.4.6/src/rvoice/fluid_iir_filter_impl.cpp#L192

I'll try to reproduce that on a Windows machine with x86/x87 compiled fluidsynth binaries. But it will take me some time to do so.

[komh]

Line 192 on my machine is https://github.com/FluidSynth/fluidsynth/blob/v2.4.6/src/rvoice/fluid_iir_filter_impl.cpp#L193.

[derselbst]

Unfortunately I was unable to reproduce this on x86 Windows. The tune just plays fine. I also have added an additional dsp_hist1 != dsp_hist1 check to trap for a NaN in addition to the compiler flag, but it didn't trap.

The only chance for the code to yield a NaN I see is when q becomes very small, here:

https://github.com/FluidSynth/fluidsynth/blob/a7792513b032f1ff422cc928eecc6c660f236720/src/rvoice/fluid_iir_filter_impl.cpp#L71

We're guarding against too small q here:

https://github.com/FluidSynth/fluidsynth/blob/a7792513b032f1ff422cc928eecc6c660f236720/src/rvoice/fluid_iir_filter_impl.cpp#L163

However, within the filter loop q is interpolated and I guess it could probably become close to zero:

https://github.com/FluidSynth/fluidsynth/blob/a7792513b032f1ff422cc928eecc6c660f236720/src/rvoice/fluid_iir_filter_impl.cpp#L235-L239

I'll think about how to guard against this and keep you posted so you can test this.

---

For the record, I compiled with

export CFLAGS="/arch:IA32 /fp:strict /fp:except"
export CXXFLAGS="/arch:IA32 /fp:strict /fp:except"
cmake -Werror=dev -G "Visual Studio 17 2022" -A "Win32" -T v141_xp -Dwindows-version=0x0501 -Denable-readline=0 -Denable-libinstpatch=0 -DCMAKE_TOOLCHAIN_FILE=$VCPKG_INSTALLATION_ROOT/scripts/buildsystems/vcpkg.cmake -DCMAKE_INSTALL_PREFIX=$VCPKG_INSTALLATION_ROOT/installed/x86-windows -DCMAKE_VERBOSE_MAKEFILE=1 ..

[derselbst]

I have proposed an implementation of my previous thought. May I ask you to try out the issue-1574 branch? And in case it still causes a SIGFPE, could you pls. uncomment this line:

https://github.com/FluidSynth/fluidsynth/blob/89bc9ee4020afc9ef4cbf660adfdb0eb473540ac/src/rvoice/fluid_iir_filter.h#L27

Run it again and provide the console output? (It will get very spammy, redirecting stdout to file recommended).

[komh]

I've tested, but it has no difference at all. And I've encountered the following compilation error:

[ 18%] Building C object src/CMakeFiles/libfluidsynth-OBJ.dir/utils/fluid_sys.c.o
In file included from g:/usr/include/os2.h:39,
                 from F:/lang/work/fluidsynth/fluidsynth.git/src/utils/fluid_sys.h:209,
                 from F:/lang/work/fluidsynth/fluidsynth.git/src/utils/fluid_sys.c:20:
F:/lang/work/fluidsynth/fluidsynth.git/src/utils/fluid_sys.c: In function 'fluid_shell_parse_argv_internal':
F:/lang/work/fluidsynth/fluidsynth.git/src/utils/fluid_sys.c:1669:9: error: expected identifier before numeric constant
 1669 |         COMMENT
      |         ^~~~~~~
F:/lang/work/fluidsynth/fluidsynth.git/src/utils/fluid_sys.c:1830:9: error: duplicate case value
 1830 |         case COMMENT:
      |         ^~~~
F:/lang/work/fluidsynth/fluidsynth.git/src/utils/fluid_sys.c:1813:9: note: previously used here
 1813 |         case DOUBLE_QUOTE:
      |         ^~~~
make[2]: *** [src/CMakeFiles/libfluidsynth-OBJ.dir/build.make:212: src/CMakeFiles/libfluidsynth-OBJ.dir/utils/fluid_sys.c.o] Error 1

This is because COMMENT is defined as a macro by OS/2 header.

[derselbst]

Looks like you have compiled master branch instead of issue-1574.

Edit: Or did you compile both branches? I need the DBG_FILTER to comprehend what's going on.

[komh]

Ooops... You're right, I had compiled master branch.

Now I've compiled issue-1574 branch, however, the result does not change.

I attach the crash report with DBG_FILTER enabled.

6863cd8d-09be_01-FLUIDSYNTH-exceptq.txt

If you need any other info, ask me please...

[derselbst]

Sorry, I meant when DBG_FILTER is enabled, you should get lot's of console output on stdout and stderr. That's the output I need. In case you notice no such output, please try recompiling in debug mode by passing -DCMAKE_BUILD_TYPE=Debug to CMake. Thanks :)

[komh]

Here it is:

filter.log

[derselbst]

Thanks for the log. I had a look into it. Unfortunately, it looks completely normal, actually almost identical to my log on x86/x87 Windows. Just that mine doesn't end so early. I would have at least expected to see a failing NaN-assertion in your log, but this is not the case either. Since I cannot reproduce this anywhere, the only option seems to be reapplying the fast-fpu-math flag you have mentioned initially. This has been applied to the release/2.4 branch already, pls. confirm if that works for you as expected, i.e. no audible clicks, pops, etc.

(I have applied #1593 to release/2.4 as well - it might be necessary if the filter's Q becomes very small for some reason.)

[komh]

release/2.4 branch works fine here, thanks!