RE: [BUG] Weird breakages in t1450 #2 on NonStop
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 2112884442 UNIX developer since approximately 421664400 -- In my real life, I talk too much.
Re: [BUG] Weird breakages in t1450 #2 on NonStop
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
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(2112884442) UNIX developer since approximately 421664400 -- In my real life, I talk too much.
