> On 04 Mar 2017, at 05:11, Junio C Hamano <gits...@pobox.com> wrote: > > On Fri, Mar 3, 2017 at 4:03 PM, Junio C Hamano <gits...@pobox.com> wrote: >> >> I only recently started looking at Travis logs, so I cannot tell if >> it is just a usual flake (e.g. some builds a few days ago seems to >> have failed due to not being able to check out the tree being >> tested, which I do not think is our fault) that we shouldn't worry >> about, or if it is a sign of a real problem. > > Tonight's pushout also seems to stall the same way. Dscho's > unversioned one didn't exhibit the problem? > https://travis-ci.org/git/git/jobs/206811396
Did Travis find our first 32bit bug? I briefly looked into it and the following new topic on pu seems to cause the issue: http://public-inbox.org/git/20170302172902.16850-1-allan.x.xav...@oracle.com/ https://github.com/git/git/commit/aaae0bf787f09ba102f69c3cf85d37e6554ab9fd The "git log" call in the new 4211 test fails with: *** Error in `/usr/src/git/git': malloc: top chunk is corrupt: 0x09ff4a78 *** More output here: https://travis-ci.org/larsxschneider/git/builds/207715343 >> Unrelated to linux-32, the same build has hard failure with Apple >> clang in t0021 with the rot13-filter.pl thing, by the way. > > This one may be a Heisenbug which may indicate some raciness in the > clean/smudge filter protocol. > The latest build of 'pu' https://travis-ci.org/git/git/jobs/207550171 seems to > have passed OK. I agree, there seems to be some kind of race condition in "t0021.15 - required process filter should filter data". I try to look into it. - Lars
