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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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.








[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]

  Powered by Linux