# git-upload-pack: the timeout gets corrupted?! 10 messages from 2007-03-11 to 2007-03-11. Participants: H. Peter Anvin, Junio C Hamano, Johannes Schindelin. Thread: https://gitlist.dev/t/7189 ## H. Peter Anvin, 2007-03-11 01:45 Subject: git-upload-pack: the timeout gets corrupted?! Message-ID: <45F35F38.1080206@zytor.com> URL: https://gitlist.dev/e/45F35F38.1080206%40zytor.com ``` git-1.5.0.3-1.i386 rpm from Junio's repository on kernel.org: Since we got the new git server on kernel.org, we are having a problem with git-upload-pack processes getting reparented to init, and then sitting there forever. Going in with gdb, it appears the "timeout" variable gets overwritten: (gdb) p timeout $1 = 608471321 ... which should have been 600. The process spends effectively forever waiting in on the fflush() in show_commit() (in upload-pack.c); /proc/*/fd shows it is trying to write to a pipe, but I'm not sure what is at the other end of that same pipe. -hpa ``` ## Junio C Hamano, 2007-03-11 05:56 Subject: Re: git-upload-pack: the timeout gets corrupted?! Message-ID: <7vy7m4wcfb.fsf@assigned-by-dhcp.cox.net> URL: https://gitlist.dev/e/7vy7m4wcfb.fsf%40assigned-by-dhcp.cox.net In-Reply-To: <45F35F38.1080206@zytor.com> ``` "H. Peter Anvin" writes: > ... Going in with gdb, it appears the "timeout" > variable gets overwritten: > > (gdb) p timeout > $1 = 608471321 > > ... which should have been 600. I do not see offhand what can cause this. The only new code since 1.4.4 series is "shallow clone" stuff,... > The process spends effectively forever waiting in on the fflush() in > show_commit() (in upload-pack.c); /proc/*/fd shows it is trying to > write to a pipe, but I'm not sure what is at the other end of that > same pipe. The process forks and the one that runs show_commit() is running rev-list internally while the other end is a pack-objects that reads from it and sends its output back to the client. ``` ## H. Peter Anvin, 2007-03-11 09:13 Subject: Re: git-upload-pack: the timeout gets corrupted?! Message-ID: <45F3C830.8090301@zytor.com> URL: https://gitlist.dev/e/45F3C830.8090301%40zytor.com In-Reply-To: <7vy7m4wcfb.fsf@assigned-by-dhcp.cox.net> ``` Junio C Hamano wrote: > "H. Peter Anvin" writes: > >> ... Going in with gdb, it appears the "timeout" >> variable gets overwritten: >> >> (gdb) p timeout >> $1 = 608471321 >> >> ... which should have been 600. > > I do not see offhand what can cause this. The only new code > since 1.4.4 series is "shallow clone" stuff,... > >> The process spends effectively forever waiting in on the fflush() in >> show_commit() (in upload-pack.c); /proc/*/fd shows it is trying to >> write to a pipe, but I'm not sure what is at the other end of that >> same pipe. > > The process forks and the one that runs show_commit() is running > rev-list internally while the other end is a pack-objects that > reads from it and sends its output back to the client. > Yup; the pack-objects process has apparently died. -hpa ``` ## H. Peter Anvin, 2007-03-11 09:23 Subject: Re: git-upload-pack: the timeout gets corrupted?! Message-ID: <45F3CAAF.7030909@zytor.com> URL: https://gitlist.dev/e/45F3CAAF.7030909%40zytor.com In-Reply-To: <7vy7m4wcfb.fsf@assigned-by-dhcp.cox.net> ``` Junio C Hamano wrote: > >> The process spends effectively forever waiting in on the fflush() in >> show_commit() (in upload-pack.c); /proc/*/fd shows it is trying to >> write to a pipe, but I'm not sure what is at the other end of that >> same pipe. > > The process forks and the one that runs show_commit() is running > rev-list internally while the other end is a pack-objects that > reads from it and sends its output back to the client. > Now, given that the fact that the git-pack-object process has already died, normally one would expect the write() to get SIGPIPE which would kill the process. Does git-upload-pack not close the read end of the pipe in the writer? From the looks of the fd directory, I would say it does not. -hpa ``` ## Johannes Schindelin, 2007-03-11 12:14 Subject: Re: git-upload-pack: the timeout gets corrupted?! Message-ID: URL: https://gitlist.dev/e/Pine.LNX.4.63.0703111314150.22628%40wbgn013.biozentrum.uni-wuerzburg.de In-Reply-To: <45F3CAAF.7030909@zytor.com> ``` Hi, On Sun, 11 Mar 2007, H. Peter Anvin wrote: > Junio C Hamano wrote: > > > > > The process spends effectively forever waiting in on the fflush() in > > > show_commit() (in upload-pack.c); /proc/*/fd shows it is trying to > > > write to a pipe, but I'm not sure what is at the other end of that > > > same pipe. > > > > The process forks and the one that runs show_commit() is running > > rev-list internally while the other end is a pack-objects that > > reads from it and sends its output back to the client. > > > > Now, given that the fact that the git-pack-object process has already died, > normally one would expect the write() to get SIGPIPE which would kill the > process. Does git-upload-pack not close the read end of the pipe in the > writer? From the looks of the fd directory, I would say it does not. Something like this (totally untested): upload-pack.c | 6 ++++++ 1 files changed, 6 insertions(+), 0 deletions(-) diff --git a/upload-pack.c b/upload-pack.c index 498bf50..bafd90f 100644 --- a/upload-pack.c +++ b/upload-pack.c @@ -119,6 +119,8 @@ static void create_pack_file(void) int i; struct rev_info revs; + close(0); + pack_pipe = fdopen(lp_pipe[1], "w"); if (create_full_pack) @@ -167,6 +169,10 @@ static void create_pack_file(void) const char *argv[10]; int i = 0; + close(0); + close(1); + close(2); + dup2(lp_pipe[0], 0); dup2(pu_pipe[1], 1); dup2(pe_pipe[1], 2); Ciao, Dscho ``` ## H. Peter Anvin, 2007-03-11 16:01 Subject: Re: git-upload-pack: the timeout gets corrupted?! Message-ID: <45F427EA.8000905@zytor.com> URL: https://gitlist.dev/e/45F427EA.8000905%40zytor.com In-Reply-To: ``` Johannes Schindelin wrote: > > Something like this (totally untested): > > upload-pack.c | 6 ++++++ > 1 files changed, 6 insertions(+), 0 deletions(-) > > diff --git a/upload-pack.c b/upload-pack.c > index 498bf50..bafd90f 100644 > --- a/upload-pack.c > +++ b/upload-pack.c > @@ -119,6 +119,8 @@ static void create_pack_file(void) > int i; > struct rev_info revs; > > + close(0); > + > pack_pipe = fdopen(lp_pipe[1], "w"); > > if (create_full_pack) Shouldn't that be close(lp_pipe[0]);? > @@ -167,6 +169,10 @@ static void create_pack_file(void) > const char *argv[10]; > int i = 0; > > + close(0); > + close(1); > + close(2); > + > dup2(lp_pipe[0], 0); > dup2(pu_pipe[1], 1); > dup2(pe_pipe[1], 2); > Those close()'s are redundant with the dup2's... -hpa ``` ## H. Peter Anvin, 2007-03-11 17:18 Subject: Re: git-upload-pack: the timeout gets corrupted?! Message-ID: <45F439E9.1080204@zytor.com> URL: https://gitlist.dev/e/45F439E9.1080204%40zytor.com In-Reply-To: <7vy7m4wcfb.fsf@assigned-by-dhcp.cox.net> ``` Junio C Hamano wrote: > "H. Peter Anvin" writes: > >> ... Going in with gdb, it appears the "timeout" >> variable gets overwritten: >> >> (gdb) p timeout >> $1 = 608471321 >> >> ... which should have been 600. > > I do not see offhand what can cause this. The only new code > since 1.4.4 series is "shallow clone" stuff,... Well, we changed servers from an x86-64 box to an i386 box, so we're definitely running different binaries. -hpa ``` ## H. Peter Anvin, 2007-03-11 17:23 Subject: Re: git-upload-pack: the timeout gets corrupted?! Message-ID: <45F43B29.5040608@zytor.com> URL: https://gitlist.dev/e/45F43B29.5040608%40zytor.com In-Reply-To: <45F35F38.1080206@zytor.com> ``` H. Peter Anvin wrote: > git-1.5.0.3-1.i386 rpm from Junio's repository on kernel.org: > > Since we got the new git server on kernel.org, we are having a problem > with git-upload-pack processes getting reparented to init, and then > sitting there forever. Going in with gdb, it appears the "timeout" > variable gets overwritten: > > (gdb) p timeout > $1 = 608471321 > > ... which should have been 600. > > The process spends effectively forever waiting in on the fflush() in > show_commit() (in upload-pack.c); /proc/*/fd shows it is trying to write > to a pipe, but I'm not sure what is at the other end of that same pipe. > Another observation: The value is always 608471321 (0x24448919) across all stuck processes that I've examined. This is neither a recent time_t value (it would be Thu Apr 13 11:48:41 UTC 1989) nor is it a valid pointer value in any of the processes I've looked at. -hpa ``` ## H. Peter Anvin, 2007-03-11 17:37 Subject: Re: git-upload-pack: the timeout gets corrupted?! Message-ID: <45F43E42.6000707@zytor.com> URL: https://gitlist.dev/e/45F43E42.6000707%40zytor.com In-Reply-To: <45F43B29.5040608@zytor.com> ``` H. Peter Anvin wrote: > Another observation: > > The value is always 608471321 (0x24448919) across all stuck processes > that I've examined. This is neither a recent time_t value (it would be > Thu Apr 13 11:48:41 UTC 1989) nor is it a valid pointer value in any of > the processes I've looked at. Nevermind! I just noticed that git-debuginfo RPM isn't from the same build as the git-core RPM, so anything obtained with gdb is baloney... -hpa ``` ## Johannes Schindelin, 2007-03-11 22:01 Subject: Re: git-upload-pack: the timeout gets corrupted?! Message-ID: URL: https://gitlist.dev/e/Pine.LNX.4.63.0703112300520.22628%40wbgn013.biozentrum.uni-wuerzburg.de In-Reply-To: <45F427EA.8000905@zytor.com> ``` Hi, On Sun, 11 Mar 2007, H. Peter Anvin wrote: > Johannes Schindelin wrote: > > > > Something like this (totally untested): > > > > upload-pack.c | 6 ++++++ > > 1 files changed, 6 insertions(+), 0 deletions(-) > > > > diff --git a/upload-pack.c b/upload-pack.c > > index 498bf50..bafd90f 100644 > > --- a/upload-pack.c > > +++ b/upload-pack.c > > @@ -119,6 +119,8 @@ static void create_pack_file(void) > > int i; > > struct rev_info revs; > > + close(0); > > + > > pack_pipe = fdopen(lp_pipe[1], "w"); > > if (create_full_pack) > > Shouldn't that be close(lp_pipe[0]);? Yes, of course! > > @@ -167,6 +169,10 @@ static void create_pack_file(void) > > const char *argv[10]; > > int i = 0; > > + close(0); > > + close(1); > > + close(2); > > + > > dup2(lp_pipe[0], 0); > > dup2(pu_pipe[1], 1); > > dup2(pe_pipe[1], 2); > > > > Those close()'s are redundant with the dup2's... I didn't know that, but that makes sense. Ciao, Dscho ```