Open wljjn opened 7 years ago
We have the same test failure in Debian, but it does not affect the other big-endian architectures.
I'm more to inclined to believe that the bug is an alignment issue:
libtool: link: g++ -pipe -g -O2 -fdebug-prefix-map=/<<PKGBUILDDIR>>=. -fstack-protector-strong -Wformat -Werror=format-security -Wl,-z -Wl,relro -o .libs/IlmImfTest main.o testAttributes.o testChannels.o testCompression.o testCopyPixels.o testCustomAttributes.o testHuf.o testLineOrder.o testMalformedImages.o testLut.o testRgba.o testRgbaThreading.o testSampleImages.o testSharedFrameBuffer.o testWav.o testXdr.o testConversion.o testNativeFormat.o testPreviewImage.o testMagic.o testStandardAttributes.o testExistingStreams.o testScanLineApi.o testTiledCompression.o testTiledCopyPixels.o testTiledLineOrder.o testTiledRgba.o compareFloat.o testTiledYa.o testYca.o compareB44.o testMultiView.o testIsComplete.o testMultiPartApi.o testMultiPartThreading.o testMultiScanlinePartThreading.o testMultiTiledPartThreading.o testDeepScanLineBasic.o testDeepTiledBasic.o testMultiPartFileMixingBasic.o testMultiPartSharedAttributes.o testBackwardCompatibility.o testCopyDeepScanLine.o testCopyDeepTiled.o testCopyMultiPartFile.o testCompositeDeepScanLine.o testInputPart.o testDeepScanLineMultipleRead.o testPartHelper.o testOptimized.o testBadTypeAttributes.o testFutureProofing.o compareDwa.o testDwaCompressorSimd.o testRle.o -pthread -L../IlmImf -L/usr/lib -lImath -lHalf -lIex -lIlmThread /<<PKGBUILDDIR>>/IlmImf/.libs/libIlmImf.so -lz -lpthread -pthread
make[4]: Leaving directory '/<<PKGBUILDDIR>>/IlmImfTest'
make check-TESTS
make[4]: Entering directory '/<<PKGBUILDDIR>>/IlmImfTest'
make[5]: Entering directory '/<<PKGBUILDDIR>>/IlmImfTest'
../test-driver: line 107: 63055 Bus error "$@" > $log_file 2>&1
FAIL: IlmImfTest
@wljjn Do you have any suggestions on how to run the test in question individually so it can be debugged with gdb? So far, I have been unable to achieve that.
@fkainz @pstanczyk Can you give any hints on how to run selected tests to be able to debug this problem?
You can run IlmImfTest/IlmImfTest directly (rather than via a make build target) using the test name as an argument, to run a single test
e.g.
IlmImfTest testDwaCompressorSimd
You can also run a subset of tests by using an argument such as core, basic, deep, multi. Check the source of "main.cpp" in IlmImfTest to see the test names.
If you build via the ./configure script you may need to use libtool to run the debugger with IlmImfTest. For debuggers with a GUI you may have more luck building so libtool isn't required - the internet will tell you how in either case.
I hit the same issue on my Sparc T5120 running Gentoo Linux with version 2.80, see Gentoo bug 656680.
Still happens with 2.5.2 on sparc:
writing reading channels A, line order 0, compression 7
writing reading channels RB, line order 0, compression 7
writing reading channels RGBA, line order 0, compression 8
writing reading IlmImfTest: /var/tmp/portage/media-libs/openexr-2.5.2/work/openexr-2.5.2/OpenEXR/IlmImfTest/compareDwa.cpp:124: void compareDwa(int, int, const Imf_2_5::Array2D<Imf_2_5::Rgba>&, const Imf_2_5::Array2D<Imf_2_5::Rgba>&, Imf_2_5::RgbaChannels): Assertion `relError < .1' failed.
Same error with 2.5.4
On Gentoo, we are currently hitting the same error on ppc64, another big endian machine, with 2.5.7. See https://bugs.gentoo.org/818424
I got a test failure on sparc in testRgba.
After checking output step by step, I think it is endianess issue in DwaCompressor, although there seems to be some codes in ImfDwaCompressor.cpp dealing with endianess. I tried to pass this test by tweaking the endianess around. I wonder has it been tested in a big endian machine? Or do I miss anything?