Re: Bug: segfault during git-prune

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 




On Thu, 28 Jun 2007, Andy Parkins wrote:
> 
> I ran git-prune on a repository and got this:
> 
> $ git-prune
> error: Object 228f8065b930120e35fc0c154c237487ab02d64a is a blob, not a commit
> Segmentation fault (core dumped)

Do you have subprojects in that git repo?

What happens is that all git object handling *refuses* (correctly) to 
touch an object of the wrong type. If it's been marked as a commit at some 
point, it had better be looked up as a commit the *next* time we see that 
same object too.

And every normal git object traversal will specify in advance what kind of 
object it expects (except for the initial refs lookups, that don't know, 
and use a totally different interface for "give me any kind of object, and 
figure it out").

So the error in this case is that we decided it was a commit once, and a 
blob once, and git is very unhappy.

And the only case I know of that does that is using an old git binary, or 
a unconverted git code-path program, on a repository with subprojects when 
the code-path doesn't understand that a tree can contain pointers to 
commits.

So what happens is that something traverses a tree object, looks at each 
entry, sees that it's not a tree, and tries to look it up as a blob. But 
subprojects are commits, not blobs, and then when you look at the object 
more closely, you get the above kind of object type confusion.

And I did that very early on, and wanted to make sure that git objects 
were "strongly typed", and you get a big fat error if you try to use the 
wrong type.

> $ git-cat-file -t 228f8065b930120e35fc0c154c237487ab02d64a
> commit
> 
> git-show of the object shows it looks okay.  git-fsck just shows a load
> of dangling objects - which isn't a surprise, that's why I was running
> git-prune.

Yeah, git-fsck knows about subprojects. I bet git-prune just doesn't. 

And indeed.. Here's a patch for it, but the fact is, you really should 
*not* prune that repository, because you'll prune away all the subproject 
data, which you seem to have in the same repo!

(General rule: never *ever* prune a shared object repository!)

		Linus

---
 reachable.c |   11 +++++++++++
 1 files changed, 11 insertions(+), 0 deletions(-)

diff --git a/reachable.c b/reachable.c
index ff3dd34..17ff929 100644
--- a/reachable.c
+++ b/reachable.c
@@ -21,6 +21,15 @@ static void process_blob(struct blob *blob,
 	/* Nothing to do, really .. The blob lookup was the important part */
 }
 
+static void process_gitlink(const unsigned char *sha1,
+			    struct object_array *p,
+			    struct name_path *path,
+			    const char *name)
+{
+	/* I don't think we want to recurse into this, really. */
+}
+
+
 static void process_tree(struct tree *tree,
 			 struct object_array *p,
 			 struct name_path *path,
@@ -47,6 +56,8 @@ static void process_tree(struct tree *tree,
 	while (tree_entry(&desc, &entry)) {
 		if (S_ISDIR(entry.mode))
 			process_tree(lookup_tree(entry.sha1), p, &me, entry.path);
+		else if (S_ISGITLINK(entry.mode))
+			process_gitlink(entry.sha1, p, &me, entry.path);
 		else
 			process_blob(lookup_blob(entry.sha1), p, &me, entry.path);
 	}
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]

  Powered by Linux