threads / patch / 29283

patchfix hang in git fetch if pointed at a 0 length bundle

Subject: [PATCH] fix hang in git fetch if pointed at a 0 length bundle

## tl;dr

6 messages between Jan 3, 2012 and Jan 3, 2012. Diffs are folded; open one to read it.

replies: 5people: 4as markdown or json

Brian Harring· Jan 3, 2012, 01:13 UTC · lore

git-repo if interupted at the exact wrong time will generate zero length bundles- literal empty files. git-repo is wrong here, but git fetch shouldn't effectively spin loop if pointed at a zero length bundle.

Signed-off-by: Brian Harring <ferringb@chromium.org>
---
 bundle.c          |    2 +-
 t/t5704-bundle.sh |   10 ++++++++++
 2 files changed, 11 insertions(+), 1 deletions(-)
Show changes to 2 files +11 −1

bundle.c, t/t5704-bundle.sh

diff --git a/bundle.c b/bundle.c
index 4742f27..ac9cc20 100644
--- a/bundle.c
+++ b/bundle.c
@@ -31,7 +31,7 @@ static int strbuf_readline_fd(struct strbuf *sb, int fd)
 	while (1) {
 		char ch;
 		ssize_t len = xread(fd, &ch, 1);
-		if (len < 0)
+		if (len <= 0)
 			return -1;
 		strbuf_addch(sb, ch);
 		if (ch == '\n')
diff --git a/t/t5704-bundle.sh b/t/t5704-bundle.sh
index 728ccd8..75ce5b8 100755
--- a/t/t5704-bundle.sh
+++ b/t/t5704-bundle.sh
@@ -53,4 +53,14 @@ test_expect_failure 'bundle --stdin <rev-list options>' '
 
 '
 
+test_expect_success 'die if bundle file is empty' '
+
+   echo -n > empty-bundle
+   timeout 5 git fetch empty-bundle
+   ret=$?
+   [ $ret == 128 ] && return 0
+   return $ret
+
+'
+
 test_done
-- 
1.7.8.2
Johannes Sixt· Jan 3, 2012, 08:35 UTC · re: Brian Harring · lore

Re: [PATCH] fix hang in git fetch if pointed at a 0 length bundle

Am 03.01.2012 02:13, schrieb Brian Harring:
> git-repo if interupted at the exact wrong time will generate zero
> length bundles- literal empty files.  git-repo is wrong here, but
> git fetch shouldn't effectively spin loop if pointed at a zero
> length bundle.
Adding a test case is very much appreciated.
> +test_expect_success 'die if bundle file is empty' '
How about 'empty bundle file is rejected'?
> +
> +   echo -n > empty-bundle
'echo -n' is not portable; use simply
	>empty-bundle &&
(note the style: no blank after >). Also chain commands using &&.
> +   timeout 5 git fetch empty-bundle

Yes, there was an infinite loop. But we do not specifically protect our git invocations in the test suite against this sort of failure. Just write

	test_must_fail git fetch empty-bundle
and end the test case here.
Show 5 quoted lines
> +   ret=$?
> +   [ $ret == 128 ] && return 0
> +   return $ret
> +
> +'
Furthermore, indentation should be one tabstop, not blanks.
-- Hannes
Nguyen Thai Ngoc Duy· Jan 3, 2012, 12:07 UTC · re: Brian Harring · lore

Re: [PATCH] fix hang in git fetch if pointed at a 0 length bundle

On Tue, Jan 3, 2012 at 8:13 AM, Brian Harring <ferringb@gmail.com> wrote:
Show 9 quoted lines
> @@ -31,7 +31,7 @@ static int strbuf_readline_fd(struct strbuf *sb, int fd)
>        while (1) {
>                char ch;
>                ssize_t len = xread(fd, &ch, 1);
> -               if (len < 0)
> +               if (len <= 0)
>                        return -1;
>                strbuf_addch(sb, ch);
>                if (ch == '\n')

I think it should return 0 when len == 0 because strictly speaking eof is not a fault. It's not really important though because the two callers in this file work fine either way.

FWIW I went through all xread call sites. All seem to handle return value <= 0 correctly.

-- 
Duy
Junio C Hamano· Jan 3, 2012, 20:11 UTC · re: Nguyen Thai Ngoc Duy · lore

Re: [PATCH] fix hang in git fetch if pointed at a 0 length bundle

Nguyen Thai Ngoc Duy <pclouds@gmail.com> writes:
Show 13 quoted lines
> On Tue, Jan 3, 2012 at 8:13 AM, Brian Harring <ferringb@gmail.com> wrote:
>> @@ -31,7 +31,7 @@ static int strbuf_readline_fd(struct strbuf *sb, int fd)
>>        while (1) {
>>                char ch;
>>                ssize_t len = xread(fd, &ch, 1);
>> -               if (len < 0)
>> +               if (len <= 0)
>>                        return -1;
>>                strbuf_addch(sb, ch);
>>                if (ch == '\n')
>
> I think it should return 0 when len == 0 because strictly speaking eof
> is not a fault.

Even if you do not strictly speak, end of file is a perfectly normal thing to see, no? IOW wouldn't the original patch actively _break_ callers that read the whole file from the file descriptor to the end?

> FWIW I went through all xread call sites. All seem to handle return
> value <= 0 correctly.
Thanks.
Brian Harring· Jan 3, 2012, 13:46 UTC · re: Brian Harring · lore

git-repo if interupted at the exact wrong time will generate zero length bundles- literal empty files. git-repo is wrong here, but git fetch shouldn't effectively spin loop if pointed at a zero length bundle.

Signed-off-by: Brian Harring <ferringb@chromium.org>
---
 bundle.c          |    4 ++--
 t/t5704-bundle.sh |    6 ++++++
 2 files changed, 8 insertions(+), 2 deletions(-)
Show changes to 2 files +8 −2

bundle.c, t/t5704-bundle.sh

diff --git a/bundle.c b/bundle.c
index 4742f27..b8acf3c 100644
--- a/bundle.c
+++ b/bundle.c
@@ -31,8 +31,8 @@ static int strbuf_readline_fd(struct strbuf *sb, int fd)
 	while (1) {
 		char ch;
 		ssize_t len = xread(fd, &ch, 1);
-		if (len < 0)
-			return -1;
+		if (len <= 0)
+			return len;
 		strbuf_addch(sb, ch);
 		if (ch == '\n')
 			break;
diff --git a/t/t5704-bundle.sh b/t/t5704-bundle.sh
index 728ccd8..4ae127d 100755
--- a/t/t5704-bundle.sh
+++ b/t/t5704-bundle.sh
@@ -53,4 +53,10 @@ test_expect_failure 'bundle --stdin <rev-list options>' '
 
 '
 
+test_expect_success 'empty bundle file is rejected' '
+
+    >empty-bundle && test_must_fail git fetch empty-bundle
+
+'
+
 test_done
-- 
1.7.8.2
Junio C Hamano· Jan 3, 2012, 20:13 UTC · re: Brian Harring · lore

Re: [PATCH] fix hang in git fetch if pointed at a 0 length bundle

Brian Harring <ferringb@gmail.com> writes:
Show 7 quoted lines
> git-repo if interupted at the exact wrong time will generate zero
> length bundles- literal empty files.  git-repo is wrong here, but
> git fetch shouldn't effectively spin loop if pointed at a zero
> length bundle.
>
> Signed-off-by: Brian Harring <ferringb@chromium.org>
> ---
Thanks.
Also thanks to all reviewers.

← back to recent threads