Hello,
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)
$ 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.
Here's the backtrace:
parse_commit_buffer (item=0x0, buffer=0x81124b8, size=421) at commit.c:292
#1 0x0808ad22 in parse_object_buffer (sha1=0x8111ac5 "\"\217\200e¹0\022\0165ü\f\025L#t\207«\002ÖJ", type=OBJ_COMMIT, size=421, buffer=0x81124b8,
eaten_p=0xafdc6c40) at object.c:152
#2 0x0808adb7 in parse_object (sha1=0x8111ac5 "\"\217\200e¹0\022\0165ü\f\025L#t\207«\002ÖJ") at object.c:187
#3 0x0808d1a2 in add_one_ref (path=0x8111aed "refs/remotes/libswscale-svn", sha1=0x8111ac5 "\"\217\200e¹0\022\0165ü\f\025L#t\207«\002ÖJ", flag=6,
cb_data=0xafdc6d40) at reachable.c:124
#4 0x0809133e in do_one_ref (base=<value optimized out>, fn=0x808d190 <add_one_ref>, trim=0, cb_data=0xafdc6d40, entry=0x8111ac0) at refs.c:478
#5 0x08092be4 in do_for_each_ref (base=0x80c8e76 "refs/", fn=0x808d190 <add_one_ref>, trim=0, cb_data=0xafdc6d40) at refs.c:545
#6 0x0808cff4 in mark_reachable_objects (revs=0xafdc6d40, mark_reflog=1) at reachable.c:188
#7 0x08071c90 in cmd_prune (argc=1, argv=0xafdc7074, prefix=0x0) at builtin-prune.c:93
#8 0x0804aa24 in handle_internal_command (argc=1, argv=0xafdc7074, envp=<value optimized out>) at git.c:348
#9 0x0804b4c9 in main (argc=1, argv=Cannot access memory at address 0xe
So, I think there are two faults: git-prune is deciding that the object is
a blob, when it's actually a commit; and git-prune's error handling is broken
in that case, because it's continuing with the NULL pointer returned by
check_commit() when obj->type != OBJ_COMMIT.
Andy
--
Dr Andy Parkins, M Eng (hons), MIET
andyparkins@xxxxxxxxx
-
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
