Your message dated Mon, 27 Oct 2025 16:49:24 +0000
with message-id <[email protected]>
and subject line Bug#1118780: fixed in gtk4 4.20.2+ds-2
has caused the Debian Bug report #1118780,
regarding gtk4: Mipmap tests fail 16/32-bit pixel format conversions due to
memory alignment issues
to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.
(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact [email protected]
immediately.)
--
1118780: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1118780
Debian Bug Tracking System
Contact [email protected] with problems
--- Begin Message ---
Source: gtk4
Version: 4.20.2+ds-1
Severity: serious
Tags: ftbfs upstream
Justification: fails unit tests at the end of the build process
X-Debbugs-Cc: [email protected]
The gtk4 package build currently fails on architectures with strict memory
alignment rules, namely sparc64.
The errors manifest as bus errors due to unaligned memory access in unit tests
for mipmap conversion routines. [1]
These unit test use the helper function texture_builder_init[2], which
unconditionally calls gdk_memory_layout_init[3] and gdk_memory_layout_fudge[4]
with a required memory alignment of 1 byte.
gdk_memory_layout_fudge[4] will then generate a randomized memory layout for
storing pixel data.
This function would actually honor a requested memory alignment, but not if the
alignment is always 1.
With a requested alignment of 1, it may generate data offsets that cause errors
when accessing 16- or 32-bit pixel formats, which must be aligned at 2 or 4
byte boundaries on sparc64.
I can see several possible fixes for this issue:
1. Always enforce the minimum required alignment based on the underlying data
types. This is the most drastic change and will require modifying
gdk_memory_layout_init.[2]
2. Enforce the minimum required alignment only on CPU architectures that
require it. This would fix the issue, but may also cause problems when a
specific memory layout is expected by an application.
3. Fix the unit test by always requesting a memory layout with adequate
alignment in texture_builder_init.[2]
Option 3. seems to be the most prudent, since it wouldn't cause problems on
other architectures where the memory alignment doesn't matter.
On the other hand, it would hide the fact that inadequate memory alignments in
user programs may lead to crashes when the target CPU doesn't support it.
I've included an untested patch for option 3.
[1] testsuite/gdk/mipmap.c
https://salsa.debian.org/gnome-team/gtk4/-/blob/debian/latest/testsuite/gdk/mipmap.c?ref_type=heads#L234
[2] testsuite/gdk/gdktestutils.c:texture_builder_init
https://salsa.debian.org/gnome-team/gtk4/-/blob/debian/latest/testsuite/gdk/gdktestutils.c?ref_type=heads#L656
[3] gdk/gdkmemorylayout.c:gdk_memory_layout_init
https://salsa.debian.org/gnome-team/gtk4/-/blob/debian/latest/gdk/gdkmemorylayout.c#L39
[4] testsuite/gdk/gdktestutils.c:gdk_memory_layout_fudge
https://salsa.debian.org/gnome-team/gtk4/-/blob/debian/latest/testsuite/gdk/gdktestutils.c?ref_type=heads#L635
-- System Information:
Debian Release: forky/sid
APT prefers unreleased
APT policy: (500, 'unreleased'), (500, 'unstable')
Architecture: sparc64
Kernel: Linux 6.16.12+deb14+1-sparc64 (UP)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8),
LANGUAGE=en_US:en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
--- gtk4/testsuite/gdk/gdktestutils.c 2025-10-16 22:15:43.620309363 +0200
+++ gdktestutils.c 2025-10-25 02:04:24.709349454 +0200
@@ -177,6 +177,89 @@
}
}
+gsize
+gdk_memory_format_get_alignment (GdkMemoryFormat format)
+{
+ switch (format)
+ {
+ case GDK_MEMORY_R8G8B8:
+ case GDK_MEMORY_B8G8R8:
+ case GDK_MEMORY_B8G8R8A8_PREMULTIPLIED:
+ case GDK_MEMORY_A8R8G8B8_PREMULTIPLIED:
+ case GDK_MEMORY_R8G8B8A8_PREMULTIPLIED:
+ case GDK_MEMORY_A8B8G8R8_PREMULTIPLIED:
+ case GDK_MEMORY_B8G8R8A8:
+ case GDK_MEMORY_A8R8G8B8:
+ case GDK_MEMORY_R8G8B8A8:
+ case GDK_MEMORY_A8B8G8R8:
+ case GDK_MEMORY_B8G8R8X8:
+ case GDK_MEMORY_X8R8G8B8:
+ case GDK_MEMORY_R8G8B8X8:
+ case GDK_MEMORY_X8B8G8R8:
+ case GDK_MEMORY_G8:
+ case GDK_MEMORY_G8A8:
+ case GDK_MEMORY_G8A8_PREMULTIPLIED:
+ case GDK_MEMORY_A8:
+ case GDK_MEMORY_G8_B8R8_420:
+ case GDK_MEMORY_G8_R8B8_420:
+ case GDK_MEMORY_G8_B8R8_422:
+ case GDK_MEMORY_G8_R8B8_422:
+ case GDK_MEMORY_G8_B8R8_444:
+ case GDK_MEMORY_G8_R8B8_444:
+ case GDK_MEMORY_G8_B8_R8_410:
+ case GDK_MEMORY_G8_R8_B8_410:
+ case GDK_MEMORY_G8_B8_R8_411:
+ case GDK_MEMORY_G8_R8_B8_411:
+ case GDK_MEMORY_G8_B8_R8_420:
+ case GDK_MEMORY_G8_R8_B8_420:
+ case GDK_MEMORY_G8_B8_R8_422:
+ case GDK_MEMORY_G8_R8_B8_422:
+ case GDK_MEMORY_G8_B8_R8_444:
+ case GDK_MEMORY_G8_R8_B8_444:
+ case GDK_MEMORY_G8B8G8R8_422:
+ case GDK_MEMORY_G8R8G8B8_422:
+ case GDK_MEMORY_R8G8B8G8_422:
+ case GDK_MEMORY_B8G8R8G8_422:
+ return 1;
+
+ case GDK_MEMORY_R16G16B16:
+ case GDK_MEMORY_R16G16B16A16_PREMULTIPLIED:
+ case GDK_MEMORY_R16G16B16A16:
+ case GDK_MEMORY_G16:
+ case GDK_MEMORY_G16A16:
+ case GDK_MEMORY_G16A16_PREMULTIPLIED:
+ case GDK_MEMORY_A16:
+ case GDK_MEMORY_G10X6_B10X6R10X6_420:
+ case GDK_MEMORY_G12X4_B12X4R12X4_420:
+ case GDK_MEMORY_G16_B16R16_420:
+ case GDK_MEMORY_X6G10_X6B10_X6R10_420:
+ case GDK_MEMORY_X6G10_X6B10_X6R10_422:
+ case GDK_MEMORY_X6G10_X6B10_X6R10_444:
+ case GDK_MEMORY_X4G12_X4B12_X4R12_420:
+ case GDK_MEMORY_X4G12_X4B12_X4R12_422:
+ case GDK_MEMORY_X4G12_X4B12_X4R12_444:
+ case GDK_MEMORY_G16_B16_R16_420:
+ case GDK_MEMORY_G16_B16_R16_422:
+ case GDK_MEMORY_G16_B16_R16_444:
+ case GDK_MEMORY_R16G16B16_FLOAT:
+ case GDK_MEMORY_R16G16B16A16_FLOAT_PREMULTIPLIED:
+ case GDK_MEMORY_R16G16B16A16_FLOAT:
+ case GDK_MEMORY_A16_FLOAT:
+ return 2;
+
+ case GDK_MEMORY_R32G32B32_FLOAT:
+ case GDK_MEMORY_R32G32B32A32_FLOAT_PREMULTIPLIED:
+ case GDK_MEMORY_R32G32B32A32_FLOAT:
+ case GDK_MEMORY_A32_FLOAT:
+ return 4;
+
+ case GDK_MEMORY_N_FORMATS:
+ default:
+ g_assert_not_reached ();
+ return 1;
+ }
+}
+
void
gdk_memory_pixel_print (const guchar *data,
const GdkMemoryLayout *layout,
@@ -658,8 +741,11 @@
int width,
int height)
{
- gdk_memory_layout_init (&builder->layout, format, width, height, 1);
- gdk_memory_layout_fudge (&builder->layout, 1);
+ gsize align;
+
+ align = gdk_memory_format_get_alignment (format);
+ gdk_memory_layout_init (&builder->layout, format, width, height, align);
+ gdk_memory_layout_fudge (&builder->layout, align);
builder->pixels = g_malloc0 (builder->layout.size);
}
--- End Message ---
--- Begin Message ---
Source: gtk4
Source-Version: 4.20.2+ds-2
Done: Jeremy Bícha <[email protected]>
We believe that the bug you reported is fixed in the latest version of
gtk4, which is due to be installed in the Debian FTP archive.
A summary of the changes between this version and the previous one is
attached.
Thank you for reporting the bug, which will now be closed. If you
have further comments please address them to [email protected],
and the maintainer will reopen the bug report if appropriate.
Debian distribution maintenance software
pp.
Jeremy Bícha <[email protected]> (supplier of updated gtk4 package)
(This message was generated automatically at their request; if you
believe that there is a problem with it please contact the archive
administrators by mailing [email protected])
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512
Format: 1.8
Date: Mon, 27 Oct 2025 12:40:34 -0400
Source: gtk4
Built-For-Profiles: noudeb
Architecture: source
Version: 4.20.2+ds-2
Distribution: unstable
Urgency: medium
Maintainer: Debian GNOME Maintainers
<[email protected]>
Changed-By: Jeremy Bícha <[email protected]>
Closes: 1118780 1118961 1118962
Changes:
gtk4 (4.20.2+ds-2) unstable; urgency=medium
.
[ John Paul Adrian Glaubitz ]
* Set DRAW_USE_LLVM=0 for softpipe architectures (Closes: #1118961)
* Remove loong64 from the list of slow qemu architectures (Closes: #1118962)
.
[ Jeremy Bícha ]
* Cherry-pick patch to fix some test failures on sparc64 (Closes: #1118780)
* Remove Suggests: devhelp
Checksums-Sha1:
0ff308e225e95c7e543d244514e00e70580b7ebd 4902 gtk4_4.20.2+ds-2.dsc
1fa592329fb18e252b33d6de4d25f9b67101ab69 3756036 gtk4_4.20.2+ds-2.debian.tar.xz
cbbce7e58f9bddd12c539f17032750d96d83399c 18513
gtk4_4.20.2+ds-2_source.buildinfo
Checksums-Sha256:
28c33d8c825857b89ea0cfcdb8de7fb6fabd10a1a6ef761b4bd66f4891fcd8b1 4902
gtk4_4.20.2+ds-2.dsc
66423f97990129f25162e0e2a0f4d1700861a3209534464f3f26c3783ad13fe4 3756036
gtk4_4.20.2+ds-2.debian.tar.xz
b9cdb362d5dab6dadb8ed2ac79bda35d96393dd7733eab1ba9764c99bd37c2d2 18513
gtk4_4.20.2+ds-2_source.buildinfo
Files:
28ad3d61d35b84b73d47001923f19225 4902 libs optional gtk4_4.20.2+ds-2.dsc
d2b0a905a3b68cca24b2baca2a640f2e 3756036 libs optional
gtk4_4.20.2+ds-2.debian.tar.xz
a6bcc2e27111364653eac18994f562a8 18513 libs optional
gtk4_4.20.2+ds-2_source.buildinfo
-----BEGIN PGP SIGNATURE-----
iQIzBAEBCgAdFiEETQvhLw5HdtiqzpaW5mx3Wuv+bH0FAmj/oNIACgkQ5mx3Wuv+
bH2JCRAA3wiNSkl+wQ+sbVsWc5krIqXrdHENp1+P1/UfwQ66uYeDlViNSuaOg/76
mbZKkG1JvF6RgccMpR10s5iQeUk1beVt+/YtZwgkRf2ng775AnY29Of6CsDuOVis
EsTzXQtF3sSVek7jeLzx8YYKQVjxSN7/3WwA27vY2aFM0vfzx62OSy0EG/KTC0Q0
kdAiVqeMK/Sn+li8g5f9Lu8I/Q7xkr3WjQCswSuuV6yN+XSuaxCKm4mpqi33lrJt
WTthfKG1q9aVsSPPNvtr67lAgrOU6q+XKtN9SGLer/3tqWj9IBhu18ugxlYrcXcm
UVO+YLOixQg5fCLjyEaPuEdUOyZI7SFlYxnkghAAYzy/vhzaBZbwC/XOsPvSszAB
noVifDZ6c9/z91l49Njkk0Nu0VZysDGxHVcmFmX03f/6LQdyratgy78yOwGuxqNh
MAxlqtUrbowIEKyE2kgpVZlk1dUuzYHlTmE0J5ELSzvFFcE10wOEdwSYqCLt9zc6
T8ct2/IjKFhWmUa9F1nMq3UL+iRo7DFHuVTpMLDbjYQRVBWtx1JlwUca3kCPW77x
6D+jcX/OURUDWGFFwoQCtN52A6uZjXfYp/ZCyFRnJWBTQhZ/wBe2kvQGsaenPWx+
W1lAa5Uxaq3dqdEXHUGXUZgcZCOE7YfNGEnRWClGIyZ3WurcypQ=
=RWHx
-----END PGP SIGNATURE-----
pgpPxeSREuXfH.pgp
Description: PGP signature
--- End Message ---
