[BUG] Weird breakages in t1450 #2 on NonStop

[BUG] Weird breakages in t1450 #2 on NonStop

[Randall S. Becker]

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 have a perspective on this - was it subsequently fixed?

Thanks,
Randall

Initialized empty Git repository in /home/git/git/t/trash
directory.t1450-fsck/another/.git/
error: object directory /home/git/git/t/trash
directory.t1450-fsck/another/.git/objects/rn---- does not exist; check
.git/objects/info/alternates.
[master (root-commit) 1aac250] C
 Author: A U Thor <author@example.com>
 1 file changed, 1 insertion(+)
 create mode 100644 fileC
error: object directory /home/git/git/t/trash
directory.t1450-fsck/another/.git/objects/rn---- does not exist; check
.git/objects/info/alternates.
--- empty       2018-01-11 13:57:30 +0000
+++ actual      2018-01-11 13:57:40 +0000
@@ -0,0 +1 @@
+error: object directory /home/git/git/t/trash
directory.t1450-fsck/another/.git/objects/rn---- does not exist; check
.git/objects/info/alternates.
not ok 2 - loose objects borrowed from alternate are not missing
#
#               mkdir another &&
#               (
#                       cd another &&
#                       git init &&
#                       echo ../../../.git/objects
>.git/objects/info/alternates &&
#                       test_commit C fileC one &&
#                       git fsck --no-dangling >../actual 2>&1
#               ) &&
#               test_cmp empty actual
#

Ls -l of the objects directory:
drwxrwxr-x 1 randall ITUGLIB 4096 Jan 11 08:26 .
drwxrwxr-x 1 randall ITUGLIB 4096 Jan 11 08:26 ..
drwxrwxr-x 1 randall ITUGLIB 4096 Jan 11 08:26 13
drwxrwxr-x 1 randall ITUGLIB 4096 Jan 11 08:26 56
drwxrwxr-x 1 randall ITUGLIB 4096 Jan 11 08:26 bd
drwxrwxr-x 1 randall ITUGLIB 4096 Jan 11 08:26 c9
drwxrwxr-x 1 randall ITUGLIB 4096 Jan 11 08:26 f7
drwxrwxr-x 1 randall ITUGLIB 4096 Jan 11 08:26 info
drwxrwxr-x 1 randall ITUGLIB 4096 Jan 11 08:26 pack
from find:
./13
./13/4756353796a5439d93586be27999eea3807a34
./56
./56/26abf0f72e58d7a153368ba57db4c673c0e171
./bd
./bd/04fbdc74c1ad468ee1cc86d49860490ab3e6c7
./c9
./c9/145d6720f85544cc4bb6009a2e541660aa156b
./c9/176b0dd1a95c80ad8de21784b1eeffd3681f49
./f7
./f7/19efd430d52bcfc8566a43b2eb655688d38871
./info
./pack

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

[Randall S. Becker]

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.

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

[Jeff King]

On Thu, Jan 11, 2018 at 04:39:04PM -0500, Randall S. Becker wrote:

> > 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.

I did a lot of work on link_alt_odb_entry() in the past year or so, and
I seem to recall seeing some cases where we could run into unterminated
memory in the error message.

Maybe dc732bd5cb (read_info_alternates: read contents into strbuf,
2017-09-19)?

-Peff

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

[Randall S. Becker]

On January 12, 2018 9:39 AM, Jeff King wrote:
> On Thu, Jan 11, 2018 at 04:39:04PM -0500, Randall S. Becker wrote:
> 
> > > 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.
> 
> I did a lot of work on link_alt_odb_entry() in the past year or so, and I seem
> to recall seeing some cases where we could run into unterminated memory
> in the error message.
> 
> Maybe dc732bd5cb (read_info_alternates: read contents into strbuf, 2017-
> 09-19)?

In that case, I think I'm going to jump right to 2.16.0-rc2. I think I would have preferred 2.15.2 - but there isn't one yet 😉

Cheers,
Randall

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