Bug#1118780: gtk4: Mipmap tests fail 16/32-bit pixel format conversions due to memory alignment issues

[John Paul Adrian Glaubitz]

Control: forwarded -1 https://gitlab.gnome.org/GNOME/gtk/-/issues/7801
Control: tags -1 +patch

Hi Gregor,

On Sat, 2025-10-25 at 13:50 +0200, Gregor Riepl wrote:
> 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.

Thanks a lot for the detailed analysis and trial patch. I have already created an upstream issue [1] for this bug
some weeks ago but my proposed patch isn't really working and just a really poor shot in the dark.

I am adding the URL to the upstream bug report and will also give your patch a try on the Debian sparc64 porterbox.

Adrian

> [1] https://gitlab.gnome.org/GNOME/gtk/-/issues/7801

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer
`. `'   Physicist
  `-    GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913