openexr

openexr copied to clipboard

Since we got the arm test issues squared away I wonder if we could also see what's going on with s390x.

Because there's so much output I won't paste it all here but you can open the build log and search for "%check" to jump to where the tests are run.

https://kojipkgs.fedoraproject.org//work/tasks/910/76780910/build.log

Here's the first relevant failure in the log:

23/111 Test  #25: OpenEXRCore.testReadDeep ..................Subprocess aborted***Exception:   0.14 sec
tempDir = '/var/tmp/OpenEXR_k0Rol9/': 24
=======
Running testReadDeep
  generating deep scanline file '/var/tmp/OpenEXR_k0Rol9/randomtempdeep.exr' compression 0
  --> done
Core Test failed: packed.size() == (sampcount[N-1]) * bps
           file:/builddir/build/BUILD/openexr-3.1.2/src/test/OpenEXRCoreTest/deep.cpp
           line:456
       function:void testReadDeep(const string&)

Another:

 61/111 Test  #60: OpenEXR.testCompression ...................Subprocess aborted***Exception:   5.57 sec
tempDir = /var/tmp/OpenEXRTest_OKQVVFJH
=======
Running testCompression
...
compression 8, x sampling 1, y sampling 1: writing reading comparingDWA compression detected too big a difference. Got 1 expected 0.000732422
OpenEXRTest: /builddir/build/BUILD/openexr-3.1.2/src/test/OpenEXRTest/testCompression.cpp:454: void {anonymous}::writeRead({anonymous}::pixelArray&, const char*, bool, int, int, int, int, Imf_3_1::Compression, int, int): Assertion `fabs(a1/denominator - a2/denominator) < 0.1' failed.

And several failures similar to this:

91/111 Test  #93: OpenEXR.testRgba ..........................Subprocess aborted***Exception:   0.46 sec
tempDir = /var/tmp/OpenEXRTest_VIPWNBDG
=======
Running testRgba
...
writing reading OpenEXRTest: /builddir/build/BUILD/openexr-3.1.2/src/test/OpenEXRTest/compareDwa.cpp:96: void compareDwa(int, int, const Imf_3_1::Array2D<Imf_3_1::Rgba>&, const Imf_3_1::Array2D<Imf_3_1::Rgba>&, Imf_3_1::RgbaChannels): Assertion `relError < .1' failed.

If access to a s390x system would be useful, please let me know (sharkcz at fedoraproject.org).

I haven't got time to dive into this, but is this a historical preservation effort? Or am I misunderstanding that s390x is the last of the old 360 mainframes? If this is historic iron, I'm just wondering if some 32bit/64 bit detection code fell off a cliff and is trying to build 64 bit OpenEXR on a 32 bit machine (or vice versa, was there ever a 64 bit s390x?) If there is some necessary architecture support to make this viable, I wonder if someone in the mainframe community would want to take that on?

s390x is the nickname for the modern 64-bit mainframes (and "s390" is the 32-bit variant going back to the S/360). The main difference to eg. i686/x86_64 is that s390/s390x is a (always) big endian arch, like ppc/ppc32/ppc64, sparc or mips. And the reason for test failures on big endians could be wrong code (assuming little endian) in the main library/project or the main code is good, but little endian assumptions exist in the tests.

Thanks for that explanation! I had no idea :)

One more question, did OpenEXR work on s390x until recently, and then broke, or has it always failed?

per https://src.fedoraproject.org/rpms/openexr/c/b278b7e1e53dd9b7fd783f8df5491dff37563500?branch=rawhide there were some issues even earlier (issue #876), but the ones reported here are the only remaining ones.

@cary-ilm, if you haven't seen my email reply yet, then check your spam box too, please.

For posterity I tried building 3.1.5 with s390x to see if anything had changed. With the caveat that I used qemu emulation as the builders are down for maintenance, the following tests fail:

The following tests FAILED:
	 25 - OpenEXRCore.testReadDeep (Subprocess aborted)
	 60 - OpenEXR.testCompression (Subprocess aborted)
	 93 - OpenEXR.testRgba (Subprocess aborted)
	 94 - OpenEXR.testRgbaThreading (Subprocess aborted)
	 96 - OpenEXR.testSampleImages (Subprocess aborted)
	 98 - OpenEXR.testSharedFrameBuffer (Subprocess aborted)
	103 - OpenEXR.testTiledRgba (Subprocess aborted)

Build logs can be provided if needed.

Thanks for the update, it appears these are the same issues as in the OP. There will be a point release soon, perhaps it makes sense to re-run the tests on top of tree instead of 3.1.5, or wait for the point release, but bearing in mind that to my knowledge nothing has changed with respect to support for big-endian systems. After testing a new release, addressing the remaining issues might require s390x community involvement ~ PRs would certainly be welcome.

@sharkcz, you did set me up with remote access to a s390 system, but I never succeeded in getting any time to further investigate. I did get connected to the machine (back in 2021), but didn't spend enough time with it to narrow the problem. I'd love to find someone with more bandwidth to investigate further.

@hobbes1069 , can you share the build logs for the failures? Similarly, I'm not sure they'll be all that informative, but I'd at least like to see what they say.

I've kicked off a build just now, you can use the link for the build.log once it's complete. https://koji.fedoraproject.org/koji/taskinfo?taskID=97575052

I also asked for some assistance on the Fedora developer mailing list. Hopefully they'll have some time to poke around.

WIth 3.1.9, the same tests fail on s390x plus those mentioned in #1460.