Re: [PATCH] Don't dereference NULL upon lookup_tree failure.
From: Junio C Hamano <hidden>
Date: 2016-06-15 22:44:01
Jim Meyering [off-list ref] writes:
quoted hunk
When running on an x86_64 system (either debian unstable or rawhide) I see only this: 0 blocks error: Object 0d57588da39d10795486bd5451bc2660832228e6 is a commit, not a tree fatal: The remote end hung up unexpectedly ...diff --git a/object.c b/object.c index 16793d9..eb59550 100644 --- a/object.c +++ b/object.c@@ -142,10 +142,14 @@ struct object *parse_object_buffer(const unsigned char *sha1, enum object_type t obj = &blob->object; } else if (type == OBJ_TREE) { struct tree *tree = lookup_tree(sha1); - obj = &tree->object; - if (!tree->object.parsed) { - parse_tree_buffer(tree, buffer, size); - eaten = 1; + if (!tree) + obj = NULL; + else { + obj = &tree->object; + if (!tree->object.parsed) { + parse_tree_buffer(tree, buffer, size); + eaten = 1; + } } } else if (type == OBJ_COMMIT) { struct commit *commit = lookup_commit(sha1);
While this change may be a prudent safeguard, there is something else going on. Can you provide the callchain that led to the parse_object_buffer() that gave SHA1 of a commit object with type set to OBJ_TREE? Which caller does that bogus combination?