"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