On Wed, Nov 28, 2012 at 6:12 AM, Ivan Kanis <ivan.kanis@xxxxxxxxxxxxxx> wrote: > We are using git with the smart HTTP protocol. We are seeing the client > freeze with Jenkins poll. It stops the continuous build which is a bit > of a pain. It happens with the latest release 1.8.0 on the client side. > The server is using 1.7.0.4. > > On the server we are seeing the following error message: > > var/log/apache2/error.log.1:[Mon Nov 19 15:17:12 2012] [error] [client 192.168.50.15] fatal: git upload-pack: not our ref aa92ca2076c2421433f89ee0b0ae89cd36d27481 multi_ack_detailed side-band-64k thin-pack no-progress ofs-delta Upgrade your server. What happened here is a race condition that is only possible in the smart HTTP protocol. The client makes an initial request to ask where the branches are. Then it makes a second (and possibly more) subsequent request to negotiate a common ancestor and actually obtain the necessary objects. If a branch is updated between that initial request and any subsequent request, the server fails with this error message. More recent servers handle this more gracefully by looking to see if the object the client wants is reachable within some reasonable distance from a current branch. If so, the request is still allowed to continue, rather than die() with a failure. > On the client side I compiled git with debugging symbols. I then > attached the debugger to the process that gets hosed. I get the > following backtrace: > > #5 0x000000010f8a1246 in packet_read_line (fd=0, buffer=0x10f981eb0 "", size=1000) at pkt-line.c:211 > #6 0x000000010f7b5196 in get_ack (fd=0, result_sha1=0x7fff6f377450 "") at builtin/fetch-pack.c:227 > #7 0x000000010f7b4074 in find_common (fd=0x7fff6f377668, result_sha1=0x7fff6f377450 "", refs=0x0) at builtin/fetch-pack.c:416 > > The file descriptor being 0 in #6 seems a bit suspicious. I am not > familiar with the git protocol. Could I get some guidance on how to > troubleshoot some more so that I come up with a patch? There is actually a parent process in front of this one called git-remote-http (or git-remote-https depending on protocol). That parent is doing the HTTP transport and is sending whatever the server provides into this child's stdin. I'm not surprised there is yet another deadlock condition in here, its a rather heinous process setup and way to handle the protocol. fd in frame #7 is an address of an int array. fd in frame #6 is an actual fd, the one to read from, which in this case should be 0 to read from stdin, because its trying to get data from the HTTP server by way of reading it from the pipe the parent supplied to it on stdin. So the stack frames are correct. Its just a problem that the parent didn't identify the server crashing and closing its side of the pipe on stdin to force it to EOF to prevent the child from getting hung here in a read. -- 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