summary | shortlog | log | commit | commitdiff | tree
raw | patch | inline | side by side (parent: 93c1e07)
raw | patch | inline | side by side (parent: 93c1e07)
author | Linus Torvalds <torvalds@osdl.org> | |
Thu, 11 Jan 2007 22:09:31 +0000 (14:09 -0800) | ||
committer | Junio C Hamano <junkio@cox.net> | |
Thu, 11 Jan 2007 22:44:17 +0000 (14:44 -0800) |
This fixes another problem that Andy's case showed: git-fsck-objects
reports nonsensical results for corrupt objects.
There were actually two independent and confusing problems:
- when we had a zero-sized file and used map_sha1_file, mmap() would
return EINVAL, and git-fsck-objects would report that as an insane and
confusing error. I don't know when this was introduced, it might have
been there forever.
- when "parse_object()" returned NULL, fsck would say "object not found",
which can be very confusing, since obviously the object might "exist",
it's just unparseable because it's totally corrupt.
So this just makes "xmmap()" return NULL for a zero-sized object (which is
a valid thing pointer, exactly the same way "malloc()" can return NULL for
a zero-sized allocation). That fixes the first problem (but we could have
fixed it in the caller too - I don't personally much care whichever way it
goes, but maybe somebody should check that the NO_MMAP case does
something sane in this case too?).
And the second problem is solved by just making the error message slightly
clearer - the failure to parse an object may be because it's missing or
corrupt, not necessarily because it's not "found".
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
reports nonsensical results for corrupt objects.
There were actually two independent and confusing problems:
- when we had a zero-sized file and used map_sha1_file, mmap() would
return EINVAL, and git-fsck-objects would report that as an insane and
confusing error. I don't know when this was introduced, it might have
been there forever.
- when "parse_object()" returned NULL, fsck would say "object not found",
which can be very confusing, since obviously the object might "exist",
it's just unparseable because it's totally corrupt.
So this just makes "xmmap()" return NULL for a zero-sized object (which is
a valid thing pointer, exactly the same way "malloc()" can return NULL for
a zero-sized allocation). That fixes the first problem (but we could have
fixed it in the caller too - I don't personally much care whichever way it
goes, but maybe somebody should check that the NO_MMAP case does
something sane in this case too?).
And the second problem is solved by just making the error message slightly
clearer - the failure to parse an object may be because it's missing or
corrupt, not necessarily because it's not "found".
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
fsck-objects.c | patch | blob | history | |
git-compat-util.h | patch | blob | history |
diff --git a/fsck-objects.c b/fsck-objects.c
index 0d8a8ebb4615c832a116a0278dfac3da1a737268..81f00db90b2f31d5362654a3e6a86f9cb93cf474 100644 (file)
--- a/fsck-objects.c
+++ b/fsck-objects.c
{
struct object *obj = parse_object(sha1);
if (!obj)
- return error("%s: object not found", sha1_to_hex(sha1));
+ return error("%s: object corrupt or missing", sha1_to_hex(sha1));
if (obj->flags & SEEN)
return 0;
obj->flags |= SEEN;
diff --git a/git-compat-util.h b/git-compat-util.h
index f8d46d587bec2b4dbab0263fa3df97e60beb08e4..8781e8e22d575c155967c8766f5d74835c0b1f78 100644 (file)
--- a/git-compat-util.h
+++ b/git-compat-util.h
{
void *ret = mmap(start, length, prot, flags, fd, offset);
if (ret == MAP_FAILED) {
+ if (!length)
+ return NULL;
release_pack_memory(length);
ret = mmap(start, length, prot, flags, fd, offset);
if (ret == MAP_FAILED)