Re: Bug#1077192: gtk4: Test regression in 4.14 on s390x: assertion failure in 3 gsk tests

Control: retitle -1 gtk4: Test regression in 4.14 on s390x: assertion failure in 3 gsk tests
Control: severity -1 serious
Control: tags -1 + experimental
Control: block 1072395 by -1

As with other test regressions, this is RC for experimental and is blocking
re-upload of 4.14.x to unstable. Its severity can be downgraded if we find
a workaround.

I think the three gsk tests that crash with an assertion failure are the
most serious thing here - they're the part of this that is RC.

On Fri, 26 Jul 2024 at 16:03:30 +0200, Matthias Geiger wrote:
>  99/666 gtk:gsk / path-special-cases                                                 ERROR            0.06s   killed by signal 6 SIGABRT

> 102/666 gtk:gsk / curve-special-cases                                                ERROR            0.05s   killed by signal 6 SIGABRT

> 106/666 gtk:gsk / path-private                                                       ERROR            0.06s   killed by signal 6 SIGABRT
> 
> To it looks like those three tests segfault.

No, they're crashing with an assertion failure (looks like the same
assertion failure in all three cases):

not ok /path/rotated-arc - Gsk:ERROR:../../../gsk/gskpathopprivate.h:67:gsk_pathop_encode: assertion failed: ((GPOINTER_TO_SIZE (pts) & GSK_PATHOP_OPERATION_MASK) == 0)

not ok /curve/special/circle - Gsk:ERROR:../../../gsk/gskpathopprivate.h:67:gsk_pathop_encode: assertion failed: ((GPOINTER_TO_SIZE (pts) & GSK_PATHOP_OPERATION_MASK) == 0)

not ok /path/circle/winding - Gsk:ERROR:../../../gsk/gskpathopprivate.h:67:gsk_pathop_encode: assertion failed: ((GPOINTER_TO_SIZE (pts) & GSK_PATHOP_OPERATION_MASK) == 0)

I can reproduce this by rebuilding gtk4 on the s390x porterbox, zelenka.

This is potentially related to
https://gitlab.gnome.org/GNOME/gtk/-/issues/6395 in which a similar
assertion failure was seen on 32-bit little-endian architectures (it
appears that a maintainer worked around this by skipping those tests
without reporting a downstream bug, so maybe gtk4 is already broken on
32-bit in practice; I don't know).

Upstream's CI only has 64-bit little-endian, so any architecture that is
32-bit or big-endian should be considered to be "at risk".

> Furthermore, some reftests
> fail because the colours diff (see attached images).

This is a bug, but the affected reftests are already skipped on s390x.
See also <https://bugs.debian.org/1058740>.

It is very likely that these colour issues are because s390x is the only
remaining big-endian release architecture in Debian: upstream does not
have any big-endian machines in their CI infrastructure, and as a result
does not test on big-endian architectures. If users of big-endian
architectures want this to be fixed, it's up to the relevant porters to
figure out which layer is wrong (maybe GTK, maybe a dependency) and
correct the interpretation of in-memory data.

> - border-image-excess: the corners are pink instead of green

This is maybe the same issue that's already tracked in #1024391.

> - gradient-hard-stop: the bottom is grey when it should be yellow
> - linear-gradient: adds some colors which shoudl not be present
> - background-blend-mode: the red and yellow half is missing from the
>   output

I'm not aware of us having separate bug reports to track these, but maybe
we should. I think they're out of scope for this RC bug, since we already
ignore the results of these reftests on s390x.

    smcv