All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Kibler, Bill" <bill.kibler@hp.com>
To: "git@vger.kernel.org" <git@vger.kernel.org>
Cc: "Kibler, Bill" <bill.kibler@hp.com>,
	Richard Lloyd <richard.lloyd@connectinternetsolutions.com>
Subject: git failure on HP-UX
Date: Thu, 5 May 2011 18:04:38 +0000	[thread overview]
Message-ID: <88C5107F36BD7E4BBFDFDB140E3D81077FA78CF12C@GVW1362EXC.americas.hpqcorp.net> (raw)

An outside HP service provides open source packages compiled to run on HP-UX systems. Our group within HP is currently moving to git with the majority of the git usage on linux systems. However, some older work still needs to be done on HP-UX systems and will require a working git set of tools. The current set of git tools works properly except for accessing gitolite, where ssh access and support is used. When trying to "clone" a gitolite hosted repo over ssh, the HP-UX git session fails with a core dump and "SIGBUS" error.

I went through updating the HP-UX system with all the latest patches and was unable to alter the response in any way. After trying many options it became clear that the problem was inside git. I used wdb/gdb and tusc, where I tracked the failure down to a call to "recv_sideband" in sideband.c. It cores when the call is made. The calling process is "sideband_demux" in builtin/fetch-pack.c. "tusc" output showed a "pipe" of size 8192 being used prior to the core. I believe that git "forks" off a "ssh user@hostanme upload-pack 'repo_name'" that is "piped" back to the git stream process.

In looking at the code, "sideband.h" defines "LARGE_PACKET_MAX 65520" and is related to the passed flag "side-band-64k" as discussed in git document pack-protocol.txt. The current default usage seems to be 64K transfers, yet if we check the "include/limits.h" of HP-UX we see a "PIPE_BUF" set to 8192. Along with the tusc indication of 8K pipe size, I suspect that HP-UX is coring due to git trying to use a 64K pipe when 8K is max.

I solved the probem for now, by changing the file sideband.h to use "LARGE_PACKET_MAX 8208". If you use 8192 or less, you get a failure of too small size in "packet_read_line". So I added 16 bytes to 8192 to get the 8208 value. I noticed the previous value and some comments indicating an 8 to 10 byte overhead was needed and thus a few bytes more is needed in this define.

I suspect the correct process would be making the HP-UX git use/send "side-band" and not "side-band-64k" in the get packet protocol, but I was unable to find out how to do that. The pack-protocol.txt discussion completely ignores this topic and how to handle clients with smaller abilities than servers. It appeared to me that the server set the transfer size and the client is just suppose to accept it. Under HPUX as a client, that is not an option, as it has a 8K max limit.

             reply	other threads:[~2011-05-05 18:06 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-05-05 18:04 Kibler, Bill [this message]
2011-05-05 19:06 ` git failure on HP-UX Junio C Hamano
2011-05-05 20:51   ` Kibler, Bill
2011-05-06 19:02   ` git failure on HP-UX - more data Kibler, Bill
2011-05-06 20:11     ` Junio C Hamano
2011-05-06 21:34       ` Kibler, Bill

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=88C5107F36BD7E4BBFDFDB140E3D81077FA78CF12C@GVW1362EXC.americas.hpqcorp.net \
    --to=bill.kibler@hp.com \
    --cc=git@vger.kernel.org \
    --cc=richard.lloyd@connectinternetsolutions.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.