From: Jeff King <peff@peff.net>
Date: Thu, 20 Nov 2025 08:16:11 GMT
Subject: Re: t8020-last-modified.sh failure on s390x (Re: [PATCH v4] last-modified: implement faster algorithm)
Message-ID: <20251120081611.GC1283645@coredump.intra.peff.net>
In-Reply-To: <ceacc47b-9d29-4e32-9d83-6bd68279c83c@mit.edu>

On Wed, Nov 19, 2025 at 12:06:35PM -0800, Anders Kaseorg wrote:

> On 11/19/25 05:49, Kristoffer Haugsbakk wrote:
> > On Wed, Nov 19, 2025, at 12:34, Anders Kaseorg wrote: >>
> > t8020-last-modified.sh is broken on the s390x platform in v2.52.0.
> >> Bisection implicates commit >> 2a04e8c293766a4976ceceb4c663dd2963e0339e
> “last-modified: implement >> faster algorithm” [1]. > > Does
> `./t8020-last-modified.sh --verbose` give any interesting > output?
> I quoted that output in my previous message. The failures in subtests 16 and
> 19 come with these diffs:
> 
> --- expect    2025-11-19 11:28:57.966106204 +0000
> +++ actual    2025-11-19 11:28:58.110112543 +0000
> @@ -1,2 +1,2 @@
> +ac29b6e974b49803f1c6ec5a705d1bf7dbfa7d2f m1.t
>  m2 m2.t
> -m1 m1.t
> 
> […]
> 
> --- expect    2025-11-19 11:29:03.492349022 +0000
> +++ actual    2025-11-19 11:29:03.648355864 +0000
> @@ -1,2 +1,2 @@
> -b5 file2
> -b2 file
> +da1857e0652b6f264c0038d684ddecddc273e506 file2
> +da1857e0652b6f264c0038d684ddecddc273e506 file

Interestingly, the commits it returns are merges. E.g., here is the
state after test 16:

  $ git log --oneline --graph
  *   ac29b6e (HEAD) Merge tag 'm1' into HEAD
  |\
  | * 53e7187 (tag: m1) m1
  * | 9b81a41 (tag: m2) m2
  |/
  * 08525b6 (master) remove a
  * 664d121 (tag: 3) 3
  * a732b0c (tag: 2) 2
  * 1edf6f6 (tag: 1) 1

Though it is also the first commit we start traversing from. The same is
true after test 19 (da1857e is the tip of HEAD there). So I am not sure
if the bug is "we are not passing down blame from the merge", or just
"we are not passing down blame at all".

I can't help but notice that this same failure is seen on s390x and HP
NonStop[1], both of which are (I think) big-endian. And not on any of
our usual little-endian platforms.

I don't see anything that looks questionable in terms of casting or
integer handling in the patch that introduced the problem, though.
Probably a long shot, but if you are able to build with "make
SANITIZE=address,undefined" and re-run t8020, that would let us check
for endian-specific memory access issues.

-Peff

[1] https://lore.kernel.org/git/003901dc596c$40bfbd80$c23f3880$@nexbridge.com/