On Wed, Nov 28, 2012 at 6:12 AM, Ivan Kanis 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 0x00010f8a1246 in packet_read_line (fd=0, buffer=0x10f981eb0 "",
> size=1000) at pkt-line.c:211
> #6 0x00010f7b5196 in get_ack (fd=0, result_sha1=0x7fff6f377450 "") at
> builtin/fetch-pack.c:227
> #7 0x00010f7b4074 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 majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
