{"thread":{"id":"50146","subject":"Suspicious fetch-pack behaviour","startedAt":"2019-01-03T09:53:03Z","lastAt":"2019-01-08T07:26:56Z","messageCount":4,"participants":["Guilhem Bonnefille","brian m. carlson","Jeff King"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"366081","messageId":"CA+BUw6jXTt6QGXvdFjRDNqJcij+1hNP5xybUUuGqo3bY0=ueuA@mail.gmail.com","threadId":"50146","inReplyTo":null,"subject":"Suspicious fetch-pack behaviour","fromName":"Guilhem Bonnefille","fromEmail":"guilhem.bonnefille@gmail.com","sentAt":"2019-01-03T09:52:48Z","receivedAt":"2019-01-03T09:53:03Z","isPatch":false,"sender":{"key":"guilhem.bonnefille@gmail.com","avatar":"https://gravatar.com/avatar/375364bfee1f61197c540e37465abe3619fc24eb3a36b0edcea7f15b124036b0?d=mp&s=160"},"body":"Hi,\n\nOne of my users reported a strange problem: a simple HTTPS clone did\nnot work with Git 1.8.3.1 on RedHat 7.\nI did many tests and I was not able to understand why his clone don't\nwork while I'm able to do it on other similar host.\n\nNevertheless, we did more investigations. One of them: a raw strace.\nI discovered two strange behaviours:\n- fetch-pack closes its standard input and standard output and then\ntries to print the references on standard input and finaly dies.\n- git-remote-https does not react to fetch-pack death and continue\npolling an empty set of FD.\n\nReading fetch-pack code, the behaviour is explicit:\nWhen \"--stateless-rpc\" is provided, fd is filled with standard input\nand standard ouput which are then closed.\nhttps://git.kernel.org/pub/scm/git/git.git/tree/builtin/fetch-pack.c?h=v1.8.3.1#n156\n\nReading this, I did not understand why it could work.\nAny help appreciated.\n\nHere is the strace's extract:\n\n2801  getdents(3, /* 2 entries */, 32768) = 48\n2801  getdents(3, /* 0 entries */, 32768) = 0\n2801  close(3)                          = 0\n2801  close(0)                          = 0\n2801  close(1)                          = 0\n2801  fstat(1, 0x7ffe10ab4730)          = -1 EBADF (Bad file descriptor)\n2801  mmap(NULL, 8192, PROT_READ|PROT_WRITE,\nMAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f220c9e3000\n2801  fstat(1, 0x7ffe10ab5040)          = -1 EBADF (Bad file descriptor)\n2801  write(1, \"4df1dbf3224064cc5dd2e4c095da2dda\"..., 159) = -1 EBADF\n(Bad file descriptor)\n2801  exit_group(0)                     = ?\n2801  +++ exited with 0 +++\n2769  <... poll resumed> )              = ? ERESTART_RESTARTBLOCK\n(Interrupted by signal)\n2769  --- SIGCHLD {si_signo=SIGCHLD, si_code=CLD_EXITED, si_pid=2801,\nsi_uid=7561, si_status=0, si_utime=0, si_stime=0} ---\n2769  restart_syscall(<... resuming interrupted poll ...>) = 0\n2769  poll(NULL, 0, 1000)               = 0 (Timeout)\n2769  poll(NULL, 0, 1000)               = 0 (Timeout)\n2769  poll(NULL, 0, 1000)               = 0 (Timeout)\n2769  poll(NULL, 0, 1000)               = 0 (Timeout)\n2769  poll(NULL, 0, 1000)               = 0 (Timeout)\n2769  poll(NULL, 0, 1000)               = 0 (Timeout)\n\n-- \nGuilhem BONNEFILLE\n-=- JID: guyou@im.apinc.org MSN: guilhem_bonnefille@hotmail.com\n-=- mailto:guilhem.bonnefille@gmail.com\n-=- http://nathguil.free.fr/\n"},{"id":"366230","messageId":"20190107033702.GI423984@genre.crustytoothpaste.net","threadId":"50146","inReplyTo":"CA+BUw6jXTt6QGXvdFjRDNqJcij+1hNP5xybUUuGqo3bY0=ueuA@mail.gmail.com","subject":"Re: Suspicious fetch-pack behaviour","fromName":"brian m. carlson","fromEmail":"sandals@crustytoothpaste.net","sentAt":"2019-01-07T03:37:02Z","receivedAt":"2019-01-07T03:38:14Z","isPatch":false,"sender":{"key":"sandals@crustytoothpaste.net","avatar":"https://avatars.githubusercontent.com/u/497054?v=4"},"body":"On Thu, Jan 03, 2019 at 10:52:48AM +0100, Guilhem Bonnefille wrote:\n> Hi,\n> \n> One of my users reported a strange problem: a simple HTTPS clone did\n> not work with Git 1.8.3.1 on RedHat 7.\n> I did many tests and I was not able to understand why his clone don't\n> work while I'm able to do it on other similar host.\n> \n> Nevertheless, we did more investigations. One of them: a raw strace.\n> I discovered two strange behaviours:\n> - fetch-pack closes its standard input and standard output and then\n> tries to print the references on standard input and finaly dies.\n> - git-remote-https does not react to fetch-pack death and continue\n> polling an empty set of FD.\n> \n> Reading fetch-pack code, the behaviour is explicit:\n> When \"--stateless-rpc\" is provided, fd is filled with standard input\n> and standard ouput which are then closed.\n> https://git.kernel.org/pub/scm/git/git.git/tree/builtin/fetch-pack.c?h=v1.8.3.1#n156\n> \n> Reading this, I did not understand why it could work.\n> Any help appreciated.\n\nWhen --stateless-rpc is passed, git fetch-pack usually has its standard\ninput and output wired up to the ends of a socket. Those file\ndescriptors are then passed to do_fetch_pack, which calls get_common to\nnegotiate refs with the remote side and get_pack to get the resulting\npack data. The negotiation should function regardless of the final ref\nprinting.\n\nIt's true that attempting to write to the standard output fails in that\ncase, but that's okay, since we wouldn't have wanted to write that data\nto the socket anyway.\n-- \nbrian m. carlson: Houston, Texas, US\nOpenPGP: https://keybase.io/bk2204\n"},{"id":"366316","messageId":"20190108063456.GA17588@sigill.intra.peff.net","threadId":"50146","inReplyTo":"CA+BUw6jXTt6QGXvdFjRDNqJcij+1hNP5xybUUuGqo3bY0=ueuA@mail.gmail.com","subject":"Re: Suspicious fetch-pack behaviour","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2019-01-08T06:34:56Z","receivedAt":"2019-01-08T06:35:00Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Thu, Jan 03, 2019 at 10:52:48AM +0100, Guilhem Bonnefille wrote:\n\n> One of my users reported a strange problem: a simple HTTPS clone did\n> not work with Git 1.8.3.1 on RedHat 7.\n> I did many tests and I was not able to understand why his clone don't\n> work while I'm able to do it on other similar host.\n> \n> Nevertheless, we did more investigations. One of them: a raw strace.\n> I discovered two strange behaviours:\n> - fetch-pack closes its standard input and standard output and then\n> tries to print the references on standard input and finaly dies.\n> - git-remote-https does not react to fetch-pack death and continue\n> polling an empty set of FD.\n>\n> [...]\n>\n> 2769  poll(NULL, 0, 1000)               = 0 (Timeout)\n\nWe actually don't use poll() very much in Git. And poking around the\nv1.8.3.1 source, I do not see any places where remote-https would call\npoll(), and none outside of \"git help\" and \"git credential-cache-daemon\"\nthat would ever provide a timeout like \"1000\".\n\nI wonder if this poll is actually being run by libcurl.  Is it possible\nto get a backtrace of the looping process with gdb?\n\nI'd also point out that v1.8.3.1 is over 5 years old, and there have\nbeen quite a few http-related fixes over the years. There is a good\nchance that if this is a Git bug, it has long since been fixed. Is it\npossible to reproduce with a more modern version of Git?\n\n-Peff\n"},{"id":"366320","messageId":"CA+BUw6h5YdimR7cBV_=Mp4KqUMvJr6-njFPEpp-pjPBCcOKx6A@mail.gmail.com","threadId":"50146","inReplyTo":"20190108063456.GA17588@sigill.intra.peff.net","subject":"Re: Suspicious fetch-pack behaviour","fromName":"Guilhem Bonnefille","fromEmail":"guilhem.bonnefille@gmail.com","sentAt":"2019-01-08T07:26:42Z","receivedAt":"2019-01-08T07:26:56Z","isPatch":false,"sender":{"key":"guilhem.bonnefille@gmail.com","avatar":"https://gravatar.com/avatar/375364bfee1f61197c540e37465abe3619fc24eb3a36b0edcea7f15b124036b0?d=mp&s=160"},"body":"Le mar. 8 janv. 2019 à 07:34, Jeff King <peff@peff.net> a écrit :\n>\n> On Thu, Jan 03, 2019 at 10:52:48AM +0100, Guilhem Bonnefille wrote:\n>\n> > One of my users reported a strange problem: a simple HTTPS clone did\n> > not work with Git 1.8.3.1 on RedHat 7.\n> > I did many tests and I was not able to understand why his clone don't\n> > work while I'm able to do it on other similar host.\n> >\n> > Nevertheless, we did more investigations. One of them: a raw strace.\n> > I discovered two strange behaviours:\n> > - fetch-pack closes its standard input and standard output and then\n> > tries to print the references on standard input and finaly dies.\n> > - git-remote-https does not react to fetch-pack death and continue\n> > polling an empty set of FD.\n> >\n> > [...]\n> >\n> > 2769  poll(NULL, 0, 1000)               = 0 (Timeout)\n>\n> We actually don't use poll() very much in Git. And poking around the\n> v1.8.3.1 source, I do not see any places where remote-https would call\n> poll(), and none outside of \"git help\" and \"git credential-cache-daemon\"\n> that would ever provide a timeout like \"1000\".\n>\n> I wonder if this poll is actually being run by libcurl.  Is it possible\n> to get a backtrace of the looping process with gdb?\n\nQuite hard to debug as it occured on a computer provided by a\ncustomer, far from me...\n\n> I'd also point out that v1.8.3.1 is over 5 years old, and there have\n> been quite a few http-related fixes over the years.\n\nYes, it is an old version, but it is the version provided with RedHat 7.\n\n> There is a good\n> chance that if this is a Git bug, it has long since been fixed. Is it\n> possible to reproduce with a more modern version of Git?\n>\n\nWhat is surprisingly is that I was unable to reproduce with the same\nversion on an other computer.\n\nDuring this time, my user discovered the IT team of the customer\nprvide a much more recent version of Git (2.X). With this new version,\nthe problem was not reproduced.\n\n\nThanks for all your investigations.\n\n\n-- \nGuilhem BONNEFILLE\n-=- JID: guyou@im.apinc.org MSN: guilhem_bonnefille@hotmail.com\n-=- mailto:guilhem.bonnefille@gmail.com\n-=- http://nathguil.free.fr/\n"}]}