RE: [BUG] Weird breakages in t1450 #2 on NonStop

From: Randall S. Becker <rsbecker@nexbridge.com>
Date: Jan 11, 2018, 21:39 UTC
Message-ID: <000201d38b24$9e27ac40$da7704c0$@nexbridge.com>
In-Reply-To: <003601d38aea$e0e08ff0$a2a1afd0$@nexbridge.com>

On January 11, 2018 9:46 AM, I wrote:

> This one has me scratching my head:
> 
> The object file name being reported below in t1450, subtest 2 is corrupt,

but I

> can't figure out why the script might be generating this condition -

there's

> nothing apparent, but it looks like the git commit -m C step is reporting

or

> using a bad name. This breakage was not present in 2.8.5 (now at 7234152
> (2.13.5) and is persistent (i.e. always happens). This is the only test in

all of

> git where I have observed this particular situation.
> Adding set -x to test_commit is unrevealing. The git fsck in this test is

never

> executed because the test_commit fails with a non-zero git commit
> completion code. There is no rn---- (actual r n 252 252 252 252) in the

objects

> directory - even the 'rn' does not correspond to anything.. I am

suspecting an

> unterminated string that ran into freed memory somewhere, but that's
> speculative.

Does anyone recall fixing this one at or near dfe46c5ce6e68d682f80f9874f0eb107e9fee797? There was a rewrite of sha1_file.c including link_alt_odb_entry where I am finding memory corruptions. I think I'm chasing something that was already fixed some time after 2.13.5 but the common parent to where I am is pretty far back compared to master.

Thanks, Randall

-- Brief whoami:
  NonStop developer since approximately NonStop(211288444200000000)
  UNIX developer since approximately 421664400
-- In my real life, I talk too much.