Source: gtk4
Version: 4.15.6+ds-1
Severity: important
Tags: ftbfs
While working on other FTBFS issues that are fixed in 4.15.6+ds-1, I saw
an intermittent test failure on multiple architectures (amd64, armel, s390x)
in the gsk / scaling test.
This occasionally happens when simply compiling the package from source, but
it's intermittent. An easier reproducer is to let the package build
successfully in an appropriate chroot/container, and then run:
debian/tests/run-with-display x11 meson test --setup=x11 --repeat=100 -v -C
./debian/build/deb scaling
in the same chroot/container. Or replace both occurrences of "x11" with
"wayland" if preferred. If it succeeds, try again until it fails.
An example build failure on s390x:
> 1..198
> # Start of scaling tests
> # Start of linear-filtering tests
> # Start of cairo tests
> ok 1 /scaling/linear-filtering/cairo/b8g8r8a8-premultiplied
> ok 2 /scaling/linear-filtering/cairo/a8r8g8b8-premultiplied
> ok 3 /scaling/linear-filtering/cairo/r8g8b8a8-premultiplied
> ok 4 /scaling/linear-filtering/cairo/b8g8r8a8
> ok 5 /scaling/linear-filtering/cairo/a8r8g8b8
> ok 6 /scaling/linear-filtering/cairo/r8g8b8a8
> ok 7 /scaling/linear-filtering/cairo/a8b8g8r8
> ok 8 /scaling/linear-filtering/cairo/r8g8b8
> ok 9 /scaling/linear-filtering/cairo/b8g8r8
> ok 10 /scaling/linear-filtering/cairo/r16g16b16
> ok 11 /scaling/linear-filtering/cairo/r16g16b16a16-premultiplied
> ok 12 /scaling/linear-filtering/cairo/r16g16b16a16
> ok 13 /scaling/linear-filtering/cairo/r16g16b16-float
> not ok /scaling/linear-filtering/cairo/r16g16b16a16-float-premultiplied -
> ERROR:../../../testsuite/gsk/scaling.c:722:compare_textures:
> 'gdk_memory_format_pixel_equal (format, accurate_compare, data1 + bpp * x,
> data2 + bpp * x)' should be TRUE
> Bail out!
> ----------------------------------- stderr -----------------------------------
> **
> ERROR:../../../testsuite/gsk/scaling.c:722:compare_textures:
> 'gdk_memory_format_pixel_equal (format, accurate_compare, data1 + bpp * x,
> data2 + bpp * x)' should be TRUE
Different tests fail in different runs, but it seems to always be one of
the r16g16b16a16-float family, which uses a half-precision float
implementation.
The obvious next step would be to produce more diagnostic output on
failure. Most of these tests act on small (2x2) textures and scale them
down to half-size, so hexdumping all of the bytes of the texture in
g_test_message() would seem reasonable. For the tests that act on large
(512x512) textures, that's probably not reasonable, but we could at least
hexdump the first pixel that differed?
smcv
