On Wed, Dec 30, 2015 at 6:26 PM, Duy Nguyen <pclouds@xxxxxxxxx> wrote: > On Wed, Dec 30, 2015 at 6:17 PM, Dennis Kaarsemaker > <dennis@xxxxxxxxxxxxxxx> wrote: >> On wo, 2015-12-30 at 10:24 +0100, Dennis Kaarsemaker wrote: >>> spirit:~/code/git (master)$ cat .git/logs/HEAD >>> 2635c2b8bfc9aec07b7f023d8e3b3d02df715344 54bc41416c5d3ecb978acb0df80d57aa3e54494c Dennis Kaarsemaker <dennis@xxxxxxxxxxxxxxx> 1446765642 +0100 >>> 74c855f87d25a5b5c12d0485ec77c785a1c734c5 54bc41416c5d3ecb978acb0df80d57aa3e54494c Dennis Kaarsemaker <dennis@xxxxxxxxxxxxxxx> 1446765951 +0100 checkout: moving from 3c3d3f629a6176b401ebec455c5dd59ed1b5f910 to master Ah... I came from a different angle and did not realize the tag sha1 is from your reflog. So yeah maybe reflog parsing code should check object type first, don't assume it's a commit! >> >> 74c855f87d25a5b5c12d0485ec77c785a1c734c5 is actually a tag, pointing to >> 3c3d3f629a6176b401ebec455c5dd59ed1b5f910. I'm not sure if that is >> relevant. > > It is. save_parents() expects "commit" to be a commit because it needs > commit->index, which is not available from struct tag. So when > saved_parents_at() tries to read commit->index, it gets random value > (from the tag). Hell breaks loose from there because this index field > points to some memory in the slab mem allocator. The question is, how > come a tag is passed in here. Maybe we can sprinkle some > assert(object->type == OBJ_COMMIT) in revision.c and see.. > -- > Duy -- Duy -- 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