{"thread":{"id":"7189","subject":"git-upload-pack: the timeout gets corrupted?!","startedAt":"2007-03-11T01:45:28Z","lastAt":"2007-03-11T22:01:21Z","messageCount":10,"participants":["H. Peter Anvin","Junio C Hamano","Johannes Schindelin"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"36770","messageId":"45F35F38.1080206@zytor.com","threadId":"7189","inReplyTo":null,"subject":"git-upload-pack: the timeout gets corrupted?!","fromName":"H. Peter Anvin","fromEmail":"hpa@zytor.com","sentAt":"2007-03-11T01:45:28Z","receivedAt":"2007-03-11T01:45:28Z","isPatch":false,"sender":{"key":"hpa@zytor.com","avatar":null},"body":"git-1.5.0.3-1.i386 rpm from Junio's repository on kernel.org:\n\nSince we got the new git server on kernel.org, we are having a problem \nwith git-upload-pack processes getting reparented to init, and then \nsitting there forever.  Going in with gdb, it appears the \"timeout\" \nvariable gets overwritten:\n\n(gdb) p timeout\n$1 = 608471321\n\n... which should have been 600.\n\nThe process spends effectively forever waiting in on the fflush() in \nshow_commit() (in upload-pack.c); /proc/*/fd shows it is trying to write \nto a pipe, but I'm not sure what is at the other end of that same pipe.\n\n\t-hpa\n"},{"id":"36793","messageId":"7vy7m4wcfb.fsf@assigned-by-dhcp.cox.net","threadId":"7189","inReplyTo":"45F35F38.1080206@zytor.com","subject":"Re: git-upload-pack: the timeout gets corrupted?!","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2007-03-11T05:56:40Z","receivedAt":"2007-03-11T05:56:40Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"\"H. Peter Anvin\" <hpa@zytor.com> writes:\n\n> ...  Going in with gdb, it appears the \"timeout\"\n> variable gets overwritten:\n>\n> (gdb) p timeout\n> $1 = 608471321\n>\n> ... which should have been 600.\n\nI do not see offhand what can cause this.  The only new code\nsince 1.4.4 series is \"shallow clone\" stuff,...\n\n> The process spends effectively forever waiting in on the fflush() in\n> show_commit() (in upload-pack.c); /proc/*/fd shows it is trying to\n> write to a pipe, but I'm not sure what is at the other end of that\n> same pipe.\n\nThe process forks and the one that runs show_commit() is running\nrev-list internally while the other end is a pack-objects that\nreads from it and sends its output back to the client.\n"},{"id":"36795","messageId":"45F3C830.8090301@zytor.com","threadId":"7189","inReplyTo":"7vy7m4wcfb.fsf@assigned-by-dhcp.cox.net","subject":"Re: git-upload-pack: the timeout gets corrupted?!","fromName":"H. Peter Anvin","fromEmail":"hpa@zytor.com","sentAt":"2007-03-11T09:13:20Z","receivedAt":"2007-03-11T09:13:20Z","isPatch":false,"sender":{"key":"hpa@zytor.com","avatar":null},"body":"Junio C Hamano wrote:\n> \"H. Peter Anvin\" <hpa@zytor.com> writes:\n> \n>> ...  Going in with gdb, it appears the \"timeout\"\n>> variable gets overwritten:\n>>\n>> (gdb) p timeout\n>> $1 = 608471321\n>>\n>> ... which should have been 600.\n> \n> I do not see offhand what can cause this.  The only new code\n> since 1.4.4 series is \"shallow clone\" stuff,...\n> \n>> The process spends effectively forever waiting in on the fflush() in\n>> show_commit() (in upload-pack.c); /proc/*/fd shows it is trying to\n>> write to a pipe, but I'm not sure what is at the other end of that\n>> same pipe.\n> \n> The process forks and the one that runs show_commit() is running\n> rev-list internally while the other end is a pack-objects that\n> reads from it and sends its output back to the client.\n> \n\nYup; the pack-objects process has apparently died.\n\n\t-hpa\n"},{"id":"36796","messageId":"45F3CAAF.7030909@zytor.com","threadId":"7189","inReplyTo":"7vy7m4wcfb.fsf@assigned-by-dhcp.cox.net","subject":"Re: git-upload-pack: the timeout gets corrupted?!","fromName":"H. Peter Anvin","fromEmail":"hpa@zytor.com","sentAt":"2007-03-11T09:23:59Z","receivedAt":"2007-03-11T09:23:59Z","isPatch":false,"sender":{"key":"hpa@zytor.com","avatar":null},"body":"Junio C Hamano wrote:\n> \n>> The process spends effectively forever waiting in on the fflush() in\n>> show_commit() (in upload-pack.c); /proc/*/fd shows it is trying to\n>> write to a pipe, but I'm not sure what is at the other end of that\n>> same pipe.\n> \n> The process forks and the one that runs show_commit() is running\n> rev-list internally while the other end is a pack-objects that\n> reads from it and sends its output back to the client.\n> \n\nNow, given that the fact that the git-pack-object process has already \ndied, normally one would expect the write() to get SIGPIPE which would \nkill the process.  Does git-upload-pack not close the read end of the \npipe in the writer?  From the looks of the fd directory, I would say it \ndoes not.\n\n\t-hpa\n"},{"id":"36798","messageId":"Pine.LNX.4.63.0703111314150.22628@wbgn013.biozentrum.uni-wuerzburg.de","threadId":"7189","inReplyTo":"45F3CAAF.7030909@zytor.com","subject":"Re: git-upload-pack: the timeout gets corrupted?!","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-03-11T12:14:53Z","receivedAt":"2007-03-11T12:14:53Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Sun, 11 Mar 2007, H. Peter Anvin wrote:\n\n> Junio C Hamano wrote:\n> > \n> > > The process spends effectively forever waiting in on the fflush() in\n> > > show_commit() (in upload-pack.c); /proc/*/fd shows it is trying to\n> > > write to a pipe, but I'm not sure what is at the other end of that\n> > > same pipe.\n> > \n> > The process forks and the one that runs show_commit() is running\n> > rev-list internally while the other end is a pack-objects that\n> > reads from it and sends its output back to the client.\n> > \n> \n> Now, given that the fact that the git-pack-object process has already died,\n> normally one would expect the write() to get SIGPIPE which would kill the\n> process.  Does git-upload-pack not close the read end of the pipe in the\n> writer?  From the looks of the fd directory, I would say it does not.\n\nSomething like this (totally untested):\n\n upload-pack.c |    6 ++++++\n 1 files changed, 6 insertions(+), 0 deletions(-)\n\ndiff --git a/upload-pack.c b/upload-pack.c\nindex 498bf50..bafd90f 100644\n--- a/upload-pack.c\n+++ b/upload-pack.c\n@@ -119,6 +119,8 @@ static void create_pack_file(void)\n \t\tint i;\n \t\tstruct rev_info revs;\n \n+\t\tclose(0);\n+\n \t\tpack_pipe = fdopen(lp_pipe[1], \"w\");\n \n \t\tif (create_full_pack)\n@@ -167,6 +169,10 @@ static void create_pack_file(void)\n \t\tconst char *argv[10];\n \t\tint i = 0;\n \n+\t\tclose(0);\n+\t\tclose(1);\n+\t\tclose(2);\n+\n \t\tdup2(lp_pipe[0], 0);\n \t\tdup2(pu_pipe[1], 1);\n \t\tdup2(pe_pipe[1], 2);\n\nCiao,\nDscho\n"},{"id":"36815","messageId":"45F427EA.8000905@zytor.com","threadId":"7189","inReplyTo":"Pine.LNX.4.63.0703111314150.22628@wbgn013.biozentrum.uni-wuerzburg.de","subject":"Re: git-upload-pack: the timeout gets corrupted?!","fromName":"H. Peter Anvin","fromEmail":"hpa@zytor.com","sentAt":"2007-03-11T16:01:46Z","receivedAt":"2007-03-11T16:01:46Z","isPatch":false,"sender":{"key":"hpa@zytor.com","avatar":null},"body":"Johannes Schindelin wrote:\n> \n> Something like this (totally untested):\n> \n>  upload-pack.c |    6 ++++++\n>  1 files changed, 6 insertions(+), 0 deletions(-)\n> \n> diff --git a/upload-pack.c b/upload-pack.c\n> index 498bf50..bafd90f 100644\n> --- a/upload-pack.c\n> +++ b/upload-pack.c\n> @@ -119,6 +119,8 @@ static void create_pack_file(void)\n>  \t\tint i;\n>  \t\tstruct rev_info revs;\n>  \n> +\t\tclose(0);\n> +\n>  \t\tpack_pipe = fdopen(lp_pipe[1], \"w\");\n>  \n>  \t\tif (create_full_pack)\n\nShouldn't that be close(lp_pipe[0]);?\n\n> @@ -167,6 +169,10 @@ static void create_pack_file(void)\n>  \t\tconst char *argv[10];\n>  \t\tint i = 0;\n>  \n> +\t\tclose(0);\n> +\t\tclose(1);\n> +\t\tclose(2);\n> +\n>  \t\tdup2(lp_pipe[0], 0);\n>  \t\tdup2(pu_pipe[1], 1);\n>  \t\tdup2(pe_pipe[1], 2);\n> \n\nThose close()'s are redundant with the dup2's...\n\n\t-hpa\n"},{"id":"36823","messageId":"45F439E9.1080204@zytor.com","threadId":"7189","inReplyTo":"7vy7m4wcfb.fsf@assigned-by-dhcp.cox.net","subject":"Re: git-upload-pack: the timeout gets corrupted?!","fromName":"H. Peter Anvin","fromEmail":"hpa@zytor.com","sentAt":"2007-03-11T17:18:33Z","receivedAt":"2007-03-11T17:18:33Z","isPatch":false,"sender":{"key":"hpa@zytor.com","avatar":null},"body":"Junio C Hamano wrote:\n> \"H. Peter Anvin\" <hpa@zytor.com> writes:\n> \n>> ...  Going in with gdb, it appears the \"timeout\"\n>> variable gets overwritten:\n>>\n>> (gdb) p timeout\n>> $1 = 608471321\n>>\n>> ... which should have been 600.\n> \n> I do not see offhand what can cause this.  The only new code\n> since 1.4.4 series is \"shallow clone\" stuff,...\n\nWell, we changed servers from an x86-64 box to an i386 box, so we're \ndefinitely running different binaries.\n\n\t-hpa\n"},{"id":"36824","messageId":"45F43B29.5040608@zytor.com","threadId":"7189","inReplyTo":"45F35F38.1080206@zytor.com","subject":"Re: git-upload-pack: the timeout gets corrupted?!","fromName":"H. Peter Anvin","fromEmail":"hpa@zytor.com","sentAt":"2007-03-11T17:23:53Z","receivedAt":"2007-03-11T17:23:53Z","isPatch":false,"sender":{"key":"hpa@zytor.com","avatar":null},"body":"H. Peter Anvin wrote:\n> git-1.5.0.3-1.i386 rpm from Junio's repository on kernel.org:\n> \n> Since we got the new git server on kernel.org, we are having a problem \n> with git-upload-pack processes getting reparented to init, and then \n> sitting there forever.  Going in with gdb, it appears the \"timeout\" \n> variable gets overwritten:\n> \n> (gdb) p timeout\n> $1 = 608471321\n> \n> ... which should have been 600.\n> \n> The process spends effectively forever waiting in on the fflush() in \n> show_commit() (in upload-pack.c); /proc/*/fd shows it is trying to write \n> to a pipe, but I'm not sure what is at the other end of that same pipe.\n> \n\nAnother observation:\n\nThe value is always 608471321 (0x24448919) across all stuck processes \nthat I've examined.  This is neither a recent time_t value (it would be \nThu Apr 13 11:48:41 UTC 1989) nor is it a valid pointer value in any of \nthe processes I've looked at.\n\n\t-hpa\n"},{"id":"36825","messageId":"45F43E42.6000707@zytor.com","threadId":"7189","inReplyTo":"45F43B29.5040608@zytor.com","subject":"Re: git-upload-pack: the timeout gets corrupted?!","fromName":"H. Peter Anvin","fromEmail":"hpa@zytor.com","sentAt":"2007-03-11T17:37:06Z","receivedAt":"2007-03-11T17:37:06Z","isPatch":false,"sender":{"key":"hpa@zytor.com","avatar":null},"body":"H. Peter Anvin wrote:\n> Another observation:\n> \n> The value is always 608471321 (0x24448919) across all stuck processes \n> that I've examined.  This is neither a recent time_t value (it would be \n> Thu Apr 13 11:48:41 UTC 1989) nor is it a valid pointer value in any of \n> the processes I've looked at.\n\nNevermind!  I just noticed that git-debuginfo RPM isn't from the same \nbuild as the git-core RPM, so anything obtained with gdb is baloney...\n\n\t-hpa\n"},{"id":"36873","messageId":"Pine.LNX.4.63.0703112300520.22628@wbgn013.biozentrum.uni-wuerzburg.de","threadId":"7189","inReplyTo":"45F427EA.8000905@zytor.com","subject":"Re: git-upload-pack: the timeout gets corrupted?!","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-03-11T22:01:21Z","receivedAt":"2007-03-11T22:01:21Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Sun, 11 Mar 2007, H. Peter Anvin wrote:\n\n> Johannes Schindelin wrote:\n> > \n> > Something like this (totally untested):\n> > \n> >  upload-pack.c |    6 ++++++\n> >  1 files changed, 6 insertions(+), 0 deletions(-)\n> > \n> > diff --git a/upload-pack.c b/upload-pack.c\n> > index 498bf50..bafd90f 100644\n> > --- a/upload-pack.c\n> > +++ b/upload-pack.c\n> > @@ -119,6 +119,8 @@ static void create_pack_file(void)\n> >  \t\tint i;\n> >  \t\tstruct rev_info revs;\n> >  +\t\tclose(0);\n> > +\n> >  \t\tpack_pipe = fdopen(lp_pipe[1], \"w\");\n> >   \t\tif (create_full_pack)\n> \n> Shouldn't that be close(lp_pipe[0]);?\n\nYes, of course!\n\n> > @@ -167,6 +169,10 @@ static void create_pack_file(void)\n> >  \t\tconst char *argv[10];\n> >  \t\tint i = 0;\n> >  +\t\tclose(0);\n> > +\t\tclose(1);\n> > +\t\tclose(2);\n> > +\n> >  \t\tdup2(lp_pipe[0], 0);\n> >  \t\tdup2(pu_pipe[1], 1);\n> >  \t\tdup2(pe_pipe[1], 2);\n> > \n> \n> Those close()'s are redundant with the dup2's...\n\nI didn't know that, but that makes sense.\n\nCiao,\nDscho\n"}]}