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
