Do you have an idea why this happens? <a href="https://buildd.debian.org/status/packag

It seems to be a side effect of sign extension in <a href="https://github.com/mmitch/g

This is fixed in commit <a class="commit-link" data-hovercard-type="commit" data-hover

Well, better make that commit <a class="commit-link" data-hovercard-type="commit" data

BE test failing,about mmitch/gbsplay

mmitch commented on September 17, 2024 1

We know about problems with the tests on "foreign" architectures, but we don't really have access to such systems to debug it.
gbsplay should handle both BE and LE correctly, so our guess was that it is related to some differences in floating point calculations.

We actually have a detection in our configure script to determine if the tests are safe to run or if they should be skipped because of known problems:

gbsplay/configure

Lines 599 to 633 in 8c77a04

    
           case "$BUILDOS" in 
        
               Linux) 
        
           	if {    [ "$BUILDARCH" = "i386"   ]  \ 
        
           	     || [ "$BUILDARCH" = "i486"   ]  \ 
        
           	     || [ "$BUILDARCH" = "i586"   ]  \ 
        
           	     || [ "$BUILDARCH" = "i686"   ]  \ 
        
           	     || [ "$BUILDARCH" = "x86_64" ]; \ 
        
           	   }; then 
        
           	    setdefault build_test yes 
        
           	else 
        
           	    # expected test failures: 
        
           	    # MD5 sum mismatch due to floating point discrepancies in libimpulse 
        
           	    setdefault build_test no 
        
           	fi 
        
           	;; 
        
               Darwin) 
        
           	setdefault build_test yes 
        
           	;; 
        
               MSYS_*) 
        
           	setdefault build_test yes 
        
           	;; 
        
               MINGW32_*|MINGW64_*) 
        
           	# known test failure: 
        
           	# - util.c does not test-compile properly 
        
           	# - srand(0) in test_shuffle() in util.c gives a different order 
        
           	setdefault build_test no 
        
           	;; 
        
               *) 
        
           	setdefault build_test no 
        
           	;; 
        
           esac

This only handles the "automatic" mode: When you run make without any arguments, gbsplay is built and after that the tests are either run or skipped depending on the output from the configure script.

I think the Debian build script always calls make test separately, so our detection is bypassed and the tests are forced to run, which then fail as expected.

The most relevant comment in the code snippet above would be # MD5 sum mismatch due to floating point discrepancies in libimpulse. This could easily be verifed: Compare the generated file impulse.h from a system failing the tests to a system passing the tests. If both files are the same, we might have a different problem on our hands than we thought.

from gbsplay.

mmitch commented on September 17, 2024 1

On the other hand, the affected architectures fail very consistently: All four failures generate the same wrong MD5 sum as seen in the build logs you have linked:

Bigendian output failed
  Expected: a6f920f9a9ac2bfbd0c7e22bb740db1c
  Got:      1e75ea3d6c66dc7b705082c7fa85290c
make[1]: *** [Makefile:369: test] Error 1

from gbsplay.

mrehkopf commented on September 17, 2024 1

It seems to be a side effect of sign extension in swap_endian; all samples having the sign bit set have their low-byte set to 0xff after swap_endian. Declaring x as unsigned short seems to fix the issue.
(x >> 8) on a signed short will sign-extend the upper 8 bits to 0xFF. The logical OR then sets all upper bits in the result.

from gbsplay.

mmitch commented on September 17, 2024 1

This is fixed in commit 33b6e0a and the additional tests from the upcoming WAV plugout show that it indeed works.

@alexmyczko Do you have a chance to test this fix on a Big Endian machine?
We now might pass the MD5SUM test during build ;-)

from gbsplay.

ranma commented on September 17, 2024

Lets keep this open for now, I'd like to investigate maybe using qemu-system-mips or somesuch to emulate BE on CI.

from gbsplay.

mmitch commented on September 17, 2024

Well, better make that commit 98fb8ac because I was rushing it.

from gbsplay.

ranma commented on September 17, 2024

Most likely fixed, please re-open if it is still an issue.

from gbsplay.

BE test failing about gbsplay HOT 7 CLOSED

Comments (7)

Related Issues (20)

Recommend Projects

React

Vue.js

Typescript

TensorFlow

Django

Laravel

D3

Recommend Topics

javascript

web

server

Machine learning

Visualization

Game

Recommend Org

Facebook

Microsoft

Google

Alibaba

D3

Tencent

	case "$BUILDOS" in
	Linux)
	if { [ "$BUILDARCH" = "i386" ] \
	\|\| [ "$BUILDARCH" = "i486" ] \
	\|\| [ "$BUILDARCH" = "i586" ] \
	\|\| [ "$BUILDARCH" = "i686" ] \
	\|\| [ "$BUILDARCH" = "x86_64" ]; \
	}; then
	setdefault build_test yes
	else
	# expected test failures:
	# MD5 sum mismatch due to floating point discrepancies in libimpulse
	setdefault build_test no
	fi
	;;

	Darwin)
	setdefault build_test yes
	;;

	MSYS_*)
	setdefault build_test yes
	;;

	MINGW32_\|MINGW64_)
	# known test failure:
	# - util.c does not test-compile properly
	# - srand(0) in test_shuffle() in util.c gives a different order
	setdefault build_test no
	;;

	*)
	setdefault build_test no
	;;
	esac