[PATCH v3 2/6] sha1_file.c: do not die failing to malloc in unpack_compressed_entry
Fewer die() gives better control to the caller, provided that the caller _can_ handle it. And in unpack_compressed_entry() case, it can, because unpack_compressed_entry() already returns NULL if it fails to inflate data. A side effect from this is fsck continues to run when very large blobs are present (and do not fit in memory). Noticed-by: Dale R. Worley wor...@alum.mit.edu Signed-off-by: Nguyễn Thái Ngọc Duy pclo...@gmail.com --- sha1_file.c | 4 +++- t/t1050-large.sh | 6 ++ 2 files changed, 9 insertions(+), 1 deletion(-) diff --git a/sha1_file.c b/sha1_file.c index 3f70b1d..330862b 100644 --- a/sha1_file.c +++ b/sha1_file.c @@ -1923,7 +1923,9 @@ static void *unpack_compressed_entry(struct packed_git *p, git_zstream stream; unsigned char *buffer, *in; - buffer = xmallocz(size); + buffer = xmallocz_gentle(size); + if (!buffer) + return NULL; memset(stream, 0, sizeof(stream)); stream.next_out = buffer; stream.avail_out = size + 1; diff --git a/t/t1050-large.sh b/t/t1050-large.sh index aea4936..5642f84 100755 --- a/t/t1050-large.sh +++ b/t/t1050-large.sh @@ -163,4 +163,10 @@ test_expect_success 'zip achiving, deflate' ' git archive --format=zip HEAD /dev/null ' +test_expect_success 'fsck' ' + test_must_fail git fsck 2err + n=$(grep error: attempting to allocate .* over limit err | wc -l) + test $n -gt 1 +' + test_done -- 2.1.0.rc0.78.gc0d8480 -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 2/6] sha1_file.c: do not die failing to malloc in unpack_compressed_entry
Looks very sensible. Thanks. On Wed, Aug 13, 2014 at 3:57 AM, Nguyễn Thái Ngọc Duy pclo...@gmail.com wrote: Fewer die() gives better control to the caller, provided that the caller _can_ handle it. And in unpack_compressed_entry() case, it can, because unpack_compressed_entry() already returns NULL if it fails to inflate data. A side effect from this is fsck continues to run when very large blobs are present (and do not fit in memory). Noticed-by: Dale R. Worley wor...@alum.mit.edu Signed-off-by: Nguyễn Thái Ngọc Duy pclo...@gmail.com --- sha1_file.c | 4 +++- t/t1050-large.sh | 6 ++ 2 files changed, 9 insertions(+), 1 deletion(-) diff --git a/sha1_file.c b/sha1_file.c index 3f70b1d..330862b 100644 --- a/sha1_file.c +++ b/sha1_file.c @@ -1923,7 +1923,9 @@ static void *unpack_compressed_entry(struct packed_git *p, git_zstream stream; unsigned char *buffer, *in; - buffer = xmallocz(size); + buffer = xmallocz_gentle(size); + if (!buffer) + return NULL; memset(stream, 0, sizeof(stream)); stream.next_out = buffer; stream.avail_out = size + 1; diff --git a/t/t1050-large.sh b/t/t1050-large.sh index aea4936..5642f84 100755 --- a/t/t1050-large.sh +++ b/t/t1050-large.sh @@ -163,4 +163,10 @@ test_expect_success 'zip achiving, deflate' ' git archive --format=zip HEAD /dev/null ' +test_expect_success 'fsck' ' + test_must_fail git fsck 2err + n=$(grep error: attempting to allocate .* over limit err | wc -l) + test $n -gt 1 +' + test_done -- 2.1.0.rc0.78.gc0d8480 -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html