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@xxxxxxxxx] Sent: Thursday, May 05, 2011 12:07 PM To: Kibler, Bill Cc: git@xxxxxxxxxxxxxxx; Richard Lloyd Subject: Re: git failure on HP-UX "Kibler, Bill" <bill.kibler@xxxxxx> 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. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html