threads / discuss / 38522

hang in git-upload-pack

Subject: hang in git-upload-pack

## tl;dr

2 messages between Feb 7, 2015 and Feb 7, 2015.

replies: 1people: 2as markdown or json

Joachim Schmitz· Feb 7, 2015, 16:25 UTC · lore
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
Randall S. Becker· Feb 7, 2015, 16:48 UTC · re: Joachim Schmitz · lore

RE: hang in git-upload-pack

> -----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)

← back to recent threads