Hi, I've encountered a particular merge that causes a segfault, and was
able to successfully bisect git to commit 36e3b5e. However, I'm unable
to come up with a simple repro that doesn't involve the source tree that
I found it on, which unfortunately I'm not able to share.
I've debugged this a bit, and it seems to happen only when there's
sufficient file creations and deletions to surpass rename_limit in
diffcore_rename, and a rename/delete conflict is encountered. I don't
know enough about the index operations that are performed at that point
to understand why it crashes git, though.
Here's a backtrace:
#0 0x080c071f in sha_eq (a=0x4 <Address 0x4 out of bounds>, b=0x8cd931c "\001:??????\tAR???`") at cache.h:597
#1 0x080c1c2d in merge_trees (o=0xbff274d0, head=0x8cd9338, merge=0x8cd9318, common=0x0, result=0xbff27484)
at merge-recursive.c:1155
#2 0x080c3613 in merge_recursive (o=0xbff274d0, h1=0x8ccd3a0, h2=0x8ccd310, ca=0x8d9abb8, result=0xbff27528)
at merge-recursive.c:1285
#3 0x0807b86e in try_merge_strategy (strategy=<value optimized out>, common=0x8d8f798,
head_arg=0x80fe14a "HEAD") at builtin-merge.c:565
#4 0x0807cc23 in cmd_merge (argc=1, argv=0xbff28c08, prefix=0x0) at builtin-merge.c:1110
#5 0x0804b777 in handle_internal_command (argc=2, argv=0xbff28c08) at git.c:247
#6 0x0804b962 in main (argc=2, argv=0xbff28c08) at git.c:438
common=0x0 in the merge_trees() call is the culprit, and that seems to
happen when a previous recursive call incurs "There are unmerged index
entries" in write_tree_from_memory, presumably due to the index issue
referenced above.
I was able to stop the segfault by copying the "make an empty tree"
block into the block following the return from recursion where
make_virtual_commit is called, but I suspect this is not the correct
solution.
Please let me know how I can further help debug this issue, or possibly
come up with a repro that will help someone else debug it. Thanks!
Dave Olszewski
--
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