Bug#607346: FTBFS [hurd]: git: t5500.12 "fetch same depth in shallow repo" hangs
Source: git
Version: 1:1.7.2.3-1
Severity: important
Jonathan Nieder wrote [1]:
> You might have noticed that git's test suite is somewhat unreliable on
> hppa.
A different problem occurs on the hurd (but aside from hurd and hppa,
all is well). Hmm.
1:1.7.2.3-1 2010-09-08 12.28 mozart
5500.12 "fetch same depth in shallow repo" hangs
1:1.7.2.3-2 2010-10-18 16.18 bach
5500.12 "fetch same depth in shallow repo" hangs
1:1.7.2.3-2.1 2010-11-25 05.33 bach
5500.12 "fetch same depth in shallow repo" hangs
1:1.7.2.3-2.2 2010-12-17 04.10 bach
5500.12 "fetch same depth in shallow repo" hangs
Commit v1.7.1.1~82 (2010-05-20) seems relevant:
start_command: close cmd->err descriptor when fork/spawn fails
Fix the problem where the cmd->err passed into start_command wasn't
being properly closed when certain types of errors occurr. (Compare
the affected code with the clean shutdown code later in the function.)
On Windows, this problem would be triggered if mingw_spawnvpe()
failed, which would happen if the command to be executed was malformed
(e.g. a text file that didn't start with a #! line). If cmd->err was
a pipe, the failure to close it could result in a hang while the other
side was waiting (forever) for either input or pipe close, e.g. while
trying to shove the output into the side band. On msysGit, this
problem was causing a hang in t5516-fetch-push.
[J6t: With a slight adjustment of the test case, the hang is also
observed on Linux.]
Signed-off-by: bert Dvornik <dvornik+git@gmail.com>
Signed-off-by: Johannes Sixt <j6t@kdbg.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Towards solving this: output from
git clone git://repo.or.cz/git.git
cd git
make -j2 NO_OPENSSL=1 NO_EXPAT=1 NO_CURL=1
cd t
GIT_TRACE=1 strace -f sh t5400-send-pack.sh -v -i
and
cd git
git revert v1.7.1.1~82
make -j2 NO_OPENSSL=1 NO_EXPAT=1 NO_CURL=1
cd t
sh t5400-send-pack.sh -v -i
would be interesting. Ideas would be nice, too. :)
Regards,
Jonathan
[1] http://lists.debian.org/debian-hppa/2010/12/msg00005.html
Reply to: