Source: pipewire
Version: 0.3.79-1
Severity: important
Reason: fails to build from source but built in the past
User: debian-al...@lists.debian.org
Usertags: ftbfs
pipewire FTBFS on Alpha due to test suite failure. From the build
log [1]:
8/22 test-resample FAIL0.19s killed by signal 8 SIGFPE
Re-running the test under gdb reveals the failure is in:
(gdb) bt
#0 0x020001002b14 in inner_product_c (n_taps=,
taps=0x2000102e300, s=0x11fcfbb54, d=0x11fcf9cf0)
at ../spa/plugins/audioconvert/resample-native-c.c:13
#1 do_resample_full_c (r=0x11fcfd000, src=, ioffs=0,
in_len=0x11fcf8eb4, dst=, ooffs=34,
out_len=0x11fcfcf80) at ../spa/plugins/audioconvert/resample-native-c.c:44
#2 0x020001001cb4 in impl_native_process (r=0x11fcfd000, src=0x11fcfcf78,
in_len=0x11fcfcf84, dst=0x11fcfcf70,
out_len=0x11fcfcf80) at ../spa/plugins/audioconvert/resample-native.c:238
#3 0x02000100157c in pull_blocks (r=0x11fcfd000, first=,
size=1024)
at ../spa/plugins/audioconvert/test-resample.c:89
#4 0x020001000ec8 in test_in_len () at
../spa/plugins/audioconvert/test-resample.c:123
#5 main (argc=, argv=) at
../spa/plugins/audioconvert/test-resample.c:154
And disassembling at the failure point reveals:
0x020001002b10 <+336>: muls$f14,$f11,$f13
=> 0x020001002b14 <+340>: sextl t0,t0
i.e. it is multiplying two single precision floating-point values
together (the location of the failure can be an instruction or
two out due to superscalar execution in the pipeline; it will be
the muls instruction that caused the fault):
f115.2433191122247536e-09 (raw 0x3e3685172000)
f141.6132473000813483e-310 (raw 0x1db28000)
and we see that f14 is a denormalised floating point number. (The
interpretation by gdb that it is 1.613...e-310 is wrong in that gdb
has assumed incorrectly that it is a double precision number for
printing the value.)
The relevant module was compiled with -ffast-math. The relevant line
in the build log [1] is:
[89/965] cc -Ispa/plugins/audioconvert/libaudioconvert_c.a.p
-Ispa/plugins/audioconvert -I../spa/plugins/audioconvert -Ispa/include
-I../spa/include -fdiagnostics-color=always -D_FILE_OFFSET_BITS=64 -Wall
-Winvalid-pch -Wextra -Wpedantic -std=gnu11 -fvisibility=hidden
-fno-strict-aliasing -Werror=suggest-attribute=format -Wsign-compare
-Wpointer-arith -Wpointer-sign -Wformat -Wformat-security
-Wimplicit-fallthrough -Wmissing-braces -Wtype-limits -Wvariadic-macros
-Wmaybe-uninitialized -Wno-missing-field-initializers -Wno-unused-parameter
-Wno-pedantic -Wdeprecated-declarations -Wunused-result -Werror=return-type
-D_GNU_SOURCE -DFASTPATH -Werror=implicit-function-declaration
-Werror=int-conversion -Werror=old-style-declaration
-Werror=old-style-definition -Werror=missing-parameter-type
-Werror=strict-prototypes -g -O2 -ffile-prefix-map=/<>=.
-specs=/usr/share/dpkg/pie-compile.specs -Wformat -Werror=format-security
-Wdate-time -D_FORTIFY_SOURCE=2 -fPIC -Ofast -ffast-math -MD -MQ
spa/plugins/audioconvert/libaudioconvert_c.a.p/resample-native-c.c.o -MF
spa/plugins/audioconvert/libaudioconvert_c.a.p/resample-native-c.c.o.d -o
spa/plugins/audioconvert/libaudioconvert_c.a.p/resample-native-c.c.o -c
../spa/plugins/audioconvert/resample-native-c.c
But according to the gcc manual:
This option is not turned on by any -O option besides
-Ofast since it can result in incorrect output for programs
that depend on an exact implementation of IEEE or ISO
rules/specifications for math functions. It may, however,
yield faster code for programs that do not require the
guarantees of these specifications.
That's the problem. The use of -ffast-math "can result in incorrect
output" if "depend on an exact implementation of IEEE" and on Alpha
-ffast-math turns off IEEE support for infinities, NaNs and
denormalised numbers, and the use of any of these results in a
SIGFPE signal being raised.
One wonders why pipewire would even need support for denormalised
numbers given that audio has a much more limited range of values!
Maybe the test suite is testing something that will never occur
in practice, in which case this test should be modified not to
include denormalised numbers. Or, if there is a good reason to
expect denormalised numbers to be possible then this module should
not be compiled with -ffast-math on Alpha. (Or the input should be
tested and any denormalised numbers set to zero before any further
processing occurs.)
Cheers,
Michael.
[1]
https://buildd.debian.org/status/fetch.php?pkg=pipewire=alpha=0.3.79-1=1693346040=0
