On May 24, 2012, at 8:51 PM, Jeff King wrote: > On Thu, May 24, 2012 at 05:40:41PM -0400, Timothy Normand Miller wrote: > >> I've run into a problem that I cannot debug. I've talked with people >> at length on IRC, I've made ample use of Google. I'm getting nowhere. >> I'm not even getting any attention on stackexchange (where usually, >> questions are answered with surprising alacrity). >> >> This is not the common scenario of Windows and git-daemon that I have >> seen answered elsewhere. This is Linux to Linux, using ssh. On both >> the client and server, git version is 1.7.8.6. Thank you for helping! > > I'd first start with trying to remove as many variables as possible. > Does the problem only happen over ssh, or does it also happen when > pushing across a pipe to a repo on the local machine? If so, does it > also happen during a fetch of the same data? If the local repo I'm pushing to is given by pathname, it's fine. If I'm pushing to another account via ssh on the localhost, it has the same hangup. All fetches work fine. > > If you can reproduce it at will (which it sounds like you can), you > could also try some older or newer git versions to see if they work any > better. If you can find a working version, it might be worth trying to > bisect and find the commit that introduces the breakage. There's this one CentOS 6 machine where I know for a fact that git hasn't been updated since I was last able to push this particular repo. That machine has git version 1.7.1. That's where I first encountered the problem. So I copied the repo to my Mac (version 1.7.8.6), but it freezes there at 11%. Then I tried copying it to the same machine that hosts the repo (Gentoo Linux with git version 1.7.8.6), and push from there (still using ssh, but locally), and it also freezes at 11%. So there's something wonky about the repo that git doesn't like, although it only has the problem over ssh. I haven't tried git's native protocol. > > If the problem still exists in the latest version, then I'd start by > stracing as much as possible. On the client side, you can use "strace > -f" to see what all of the processes are doing; you'll probably also > want to pass: > > --receive-pack='strace -f -o foo.out git-receive-pack' First, I ran the push and then killed it, and I got this: http://www.cse.ohio-state.edu/~millerti/foo.out But then I realized that you'd want to see where it hung up, so I can it again and then sent the file before killing the push: http://www.cse.ohio-state.edu/~millerti/foo2.out > > to git-push to ask the remote side to strace. There's a reasonable > chance you'll simply see that the client side is waiting on the server > side for I/O, so you'll want to know what the server side is doing. I really don't know how to interpret the trace. > > I see you posted an strace snippet of a process waiting in select() on > stack overflow. It's hard to tell what's going on from there, though, > because we can't see which processes are which (we see the pids, but we > don't know which programs they're running, or where the commands go). A > full strace log would help a lot (if it's long and you need a place to > post it, try something like https://gist.github.com). Try this: http://www.cse.ohio-state.edu/~millerti/revue_strace3.txt This one was from earlier in the day. It's from a push from the same machine that hosts the repo. > > And finally, if the repo is something you can make public, I can try to > reproduce on my machine. That might tell us if the problem is with your > repo, or something else about your machines or setup. That would make things a lot easier, but I'm not at liberty to share it. Thanks again! -- 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