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

[John Paul Adrian Glaubitz]

Hi,

upstream has fixed this issue now [1]. I'm attaching their patch.

Could you include this patch in the next upload?

Adrian

> [1] https://gitlab.gnome.org/GNOME/gtk/-/merge_requests/9085

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer
`. `'   Physicist
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913
From 5139eebd189602c9938b837386db7f54ef84861d Mon Sep 17 00:00:00 2001
From: Gregor Riepl 
Date: Mon, 27 Oct 2025 08:50:19 +0100
Subject: [PATCH] testsuite: Fix alignment handling in testutils

We need to respect gdk_memory_alignment() when creating fudged buffers,
because we use internal APIs to access those buffers and those internal
APIs require the alignment.

For public API usage this already happens because we copy the memory if
necessary.

This broke the mipmap test on sparc64.

Fixes #7801

Part-of: 
---
 testsuite/gdk/gdktestutils.c | 7 +--
 1 file changed, 5 insertions(+), 2 deletions(-)

diff --git a/testsuite/gdk/gdktestutils.c b/testsuite/gdk/gdktestutils.c
index 91ec99af5ef..02e901bf37f 100644
--- a/testsuite/gdk/gdktestutils.c
+++ b/testsuite/gdk/gdktestutils.c
@@ -658,8 +658,11 @@ texture_builder_init (TextureBuilder  *builder,
   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_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);
 }
 
-- 
GitLab

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

[John Paul Adrian Glaubitz]

On Sat, 2025-10-25 at 22:12 +0200, John Paul Adrian Glaubitz wrote:
> On Sat, 2025-10-25 at 21:46 +0200, Gregor Riepl wrote:
> > > I have tested your patch now and it seems it just reduced the number of 
> > > failures by one.
> > 
> > There's already a workaround for the "Missing JIT" error, but it seems to 
> > be broken on sparc...
> > 
> > https://salsa.debian.org/gnome-team/gtk4/-/blob/debian/latest/debian/rules?ref_type=heads#L279-294
> 
> Well, for some reason the setting "export GALLIUM_DRIVER=softpipe" is 
> ignored. I'm currently
> reading the Mesa documentation to figure out why that's the case.

Oh, nice. Setting "export DRAW_USE_LLVM=0" gets the failures down to 4:

--- debian/rules.orig   2025-10-14 03:51:42.0 +0200
+++ debian/rules2025-10-25 22:13:13.930249247 +0200
@@ -282,6 +282,7 @@
 ifneq ($(filter mips% powerpc sparc%,$(DEB_HOST_ARCH_CPU)),)
 $(info Disabling use of llvmpipe on this CPU)
 export GALLIUM_DRIVER=softpipe
+export DRAW_USE_LLVM=0
 # https://bugs.debian.org/1077178
 ignore_reftests += label-shadows
 # These succeed with llvmpipe, but fail with softpipe

Result:

Ok:723
Fail:  4
Skipped:   28

Adrian

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

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

[John Paul Adrian Glaubitz]

On Sat, 2025-10-25 at 21:46 +0200, Gregor Riepl wrote:
> > I have tested your patch now and it seems it just reduced the number of 
> > failures by one.
> 
> There's already a workaround for the "Missing JIT" error, but it seems to be 
> broken on sparc...
> 
> https://salsa.debian.org/gnome-team/gtk4/-/blob/debian/latest/debian/rules?ref_type=heads#L279-294

Well, for some reason the setting "export GALLIUM_DRIVER=softpipe" is ignored. 
I'm currently
reading the Mesa documentation to figure out why that's the case.

Adrian

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

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

[John Paul Adrian Glaubitz]

On Sat, 2025-10-25 at 21:35 +0200, Gregor Riepl wrote:
> > I have tested your patch now and it seems it just reduced the number of 
> > failures by one.
> 
> Great that it worked - although there's apparently a better way to do this: 
> https://gitlab.gnome.org/GNOME/gtk/-/issues/7801#note_2586231
> 
> I did expect that it would only resolve that one test.
> 
> All the other errors are caused by this:
> 
> stderr:
> Target has no JIT support

Known issue, see this discussion: 
https://github.com/llvm/llvm-project/issues/47229

Adrian

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

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

[Gregor Riepl]

I have tested your patch now and it seems it just reduced the number of 
failures by one.


There's already a workaround for the "Missing JIT" error, but it seems to be 
broken on sparc...

https://salsa.debian.org/gnome-team/gtk4/-/blob/debian/latest/debian/rules?ref_type=heads#L279-294

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

[Gregor Riepl]

I have tested your patch now and it seems it just reduced the number of 
failures by one.


Great that it worked - although there's apparently a better way to do this: 
https://gitlab.gnome.org/GNOME/gtk/-/issues/7801#note_2586231

I did expect that it would only resolve that one test.

All the other errors are caused by this:

stderr:
Target has no JIT support

(test program exited with status code 1)

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

[John Paul Adrian Glaubitz]

Hi,

I have tested your patch now and it seems it just reduced the number of 
failures by one.

Before:

Ok:536
Fail:  191
Skipped:   28

After:

Ok:537
Fail:  190
Skipped:   28

Adrian

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

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

[John Paul Adrian Glaubitz]

Hi Gregor,

On Sat, 2025-10-25 at 16:06 +0200, Gregor Riepl wrote:
> > 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.
> 
> Thanks for that! I can see that upstream has already identified the issue, 
> but it seems like they're unsure about how to address it properly.
> 
> By the way: I do intend to test my patch, but building gtk4 takes a whole day 
> on my Ultra 10.

You can test build SPARC code on cfarm202.cfarm.net which is SPARC T5.

Get an account here: https://gcc.gnu.org/wiki/CompileFarm

Adrian

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

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

[Gregor Riepl]

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.


Thanks for that! I can see that upstream has already identified the issue, but 
it seems like they're unsure about how to address it properly.

By the way: I do intend to test my patch, but building gtk4 takes a whole day 
on my Ultra 10.

Re: 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

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

[John Paul Adrian Glaubitz]

Hi Gregor,

On Sat, 2025-10-25 at 14:45 +0200, Gregor Riepl wrote:
> I traced one of the build errors in the gtk4 package on sparc64: [1]

Thanks for tracking this down and finding a solution for the problem.

FWIW, I have created an issue in the upstream bug tracker [1]. You might want
to post your patch in this issue.

> For some reason, the sparc64 usertag got lost in the process, and it's
> now an RC bug on gtk4. Changing the usertag and bug owner also didn't
> work (the BTS reported no error, but the bug remains unchanged), I don't
> understand what's going on...
> 
> Any help?

You can send control commands to the bug tracker by preceeding them with
"Control:", for example:

Control: -1 severity normal
Control: tags +sparc64

where "-1" is a place holder for the current bug report.

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