RE: git failure on HP-UX

["Kibler, Bill" <bill.kibler@hp.com>]

Let me say first off that my change seems to work, but clearly I feel it
was more a lucky guess on my part than hunting down the actual cause since
I feel it is a combination of git actions and HP-UX libraries. I can't really
debug all of HP-UX libc, so I have to make an educated guess as to what might
be happening. For me, I felt that some mechanism inside of git should be
possible to set on the client side to limit transfer buffer sizes without
a recompile.

Now having said that and had a chance to consider my explanation as stated,
it might be more accurate to say that what I think is happening is closer to
this - as I understand the SIGBUS and other messages around the action,
I think the library call is setting up the pipe buffer as 8k of memory,
while git is assuming(?) a 64K space and returns a pointer to the libc
function that is well beyond - 48K beyond - the size of the buffer.
As I take what is happing, one of these processes is returning a pointer
that points outside approved space and causing the system to fault.
The debug steps all showed the values from git as being reasonable or
what I thought them to be, yet HP-UX faulted when entering the called
function. 

Since I was unable to date to clearly understand all the coding associated with
the fetch-pack process, just running out of time on the project, I was hoping
to get more data from the git email group, that might highlight something I missed
debugging the problem. I clearly was unable to find enough text to explain both
sides of the side-band handshake and how sideband values are used - maybe if
I had more time to understand the code fully, but I don't.

Bill. 

-----Original Message-----
From: Junio C Hamano [mailto:gitster@pobox.com] 
Sent: Thursday, May 05, 2011 12:07 PM
To: Kibler, Bill
Cc: git@vger.kernel.org; Richard Lloyd
Subject: Re: git failure on HP-UX

"Kibler, Bill" <bill.kibler@hp.com> writes:

> 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".

This does not make any sense.  We may make write(2) and read(2) system
calls with 64k (or maybe bit more) chunk, but that does not mean the
implementation of these system calls must take that as a whole.  Your
write(2) is allowed to write only whatever fits your pipe buffer, and tell
the caller "I wrote only 8192 bytes", and the code is supposed to loop,
advancing the write pointer by 8k and calling write(2) again, until you
write everything to whoever is reading the other end of the pipe.  The
same thing for the read(2).

If you can find a place where we make write(2)/read(2) and blindly assumes
that a non-negative return means everything was written/read successfully,
then you have found a bug.

If the symptom _were_ a deadlock where the writer of one pipe expected to
be able to send 64k to the other end of the pipe and then hear back from
the other side with a separate read, I would understand that could happen
(actually we know a local pipe transfer without ssh has that kind of
potential deadlock but I think the size we assume that can fit in the pipe
buffer is far smaller than 8k).  But I do not understand where a SIGBUS
can come from.