hang in git-upload-pack

hang in git-upload-pack

[Joachim Schmitz]

Hi there

In HP-Nonstop we're experiencing hangs in git-upload-pack, which seems to 
be the result of reads from / writes to pipes don't ever finish or don't 
get interrupted properly (SIGPIPE, SIGCHLD?)

Any idea why that might be and how to fix it?


bye, Jojo

RE: hang in git-upload-pack

[Randall S. Becker]

> -----Original Message-----
>Sent: February 7, 2015 11:26 AM
>In HP-Nonstop we're experiencing hangs in git-upload-pack, which seems to
be the result
>of reads from / writes to pipes don't ever finish or don't get interrupted
properly (SIGPIPE, SIGCHLD?)
>Any idea why that might be and how to fix it?

More context on this issue:
This is a new port of Git 2.3 to HP NonStop OSS (POSIX-ish). With very
minimal changes in git_compat-util.h to include floss and wrapper.c (below),
we are able to clone remote repositories and work on local repositories
without issue. However, when attempting to fetch from a local bare
repository (set up as a remote but on the same server) into a working
repository, or when a remote client attempts to clone from any repository on
the server over any protocol, we end up with git-upload-pack hanging as the
common point of failure. Note that this function has not worked in prior
version of git, so we have no working reference to compare. The team is
suspecting differences in how the OS deals with pipes but our primary need
from the community is some guidance on continuing our investigation in
resolving this.

Most git tests succeed except for: t0025(test 2), t0301(test
12-expected),t5507(test 4 - suspicious of this),t9001(expected).

A sample trace showing the issue is below. There are no external clients
involved in this sample. This is git to git locally. The condition appears
to be representative of all of the hangs.

GIT_TRACE=1 /usr/local/bin/git --exec-path=/usr/local/bin fetch
old_floss_tail
09:52:01.198401 trace: built-in: git 'fetch' 'old_floss_tail'
09:52:01.226684 trace: run_command: 'git-upload-pack
'\''/home/git/floss.git/.git'\'''
09:52:01.229229 trace: exec: '/usr/local/bin/bash' '-c' 'git-upload-pack
'\''/home/git/floss.git/.git'\''' 'git-upload-pack
'\''/home/git/floss.git/.git'\'''
09:52:01.303638 trace: run_command: 'rev-list' '--objects' '--stdin' '--not'
'--all' '--quiet'
warning: no common commits
09:52:01.438320 trace: run_command: 'pack-objects' '--revs' '--thin'
'--stdout' '--progress' '--delta-base-offset' '--include-tag'
remote: 09:52:01.445274 trace: exec: 'git' 'pack-objects' '--revs' '--thin'
'--stdout' '--progress' '--delta-base-offset' '--include-tag'
remote: 09:52:01.463846 trace: built-in: git 'pack-objects' '--revs'
'--thin' '--stdout' '--progress' '--delta-base-offset' '--include-tag'
remote: Counting objects: 485, done.
remote: Compressing objects: 100% (472/472), done.
<<<< Hangs forever at this point. >>>> 

The git-unpack-load is stopped at (not that the addresses might mean much):
  xread + 0x130 (UCr)
  create_pack_file + 0x18F0 (UCr)
  upload_pack + 0x450 (UCr)
  .

There are two git processes at:
  xread + 0x130 (UCr)
  read_in_full + 0x130 (UCr)
  get_packet_data + 0x4A0 (UCr)
  .

And one git is at:
  xwrite + 0x130 (UCr)
  flush + 0x530 (UCr)
  sha1write + 0x600 (UCr)
  write_no_reuse_object + 0x1390 (UCr)
  .

Wrapper.c change:
@@ -173,7 +173,12 @@ void *xcalloc(size_t nmemb, size_t size)
  * the absence of bugs, large chunks can result in bad latencies when
  * you decide to kill the process.
  */
-#define MAX_IO_SIZE (8*1024*1024)
+#ifdef __TANDEM
+# include <limits.h> /* SSIZE_MAX == 52k */
+# define MAX_IO_SIZE SSIZE_MAX
+#else
+# define MAX_IO_SIZE (8*1024*1024)
+#endif

Best Regards,
Randall
-- Brief whoami: NonStop&UNIX developer since approximately
UNIX(421664400)/NonStop(211288444200000000)