Crash in t3507-cherry-pick-conflict.sh with GIT_TEST_SPLIT_INDEX set

Git from the master branch currently segfaults when running t3507-cherry-pick-conflict.sh with GIT_TEST_SPLIT_INDEX set:

expecting success:
        pristine_detach initial &&
        test_must_fail git cherry-pick -s picked-signed &&
        git commit -a -s &&
        test $(git show -s |grep -c "Signed-off-by") = 1

HEAD is now at df2a63d... initial Auto-merging foo CONFLICT (content): Merge conflict in foo error: could not apply e4ca149... picked-signed hint: after resolving the conflicts, mark the corrected paths hint: with 'git add <paths>' or 'git rm <paths>' hint: and commit the result with 'git commit' Segmentation fault not ok 29 - commit after failed cherry-pick does not add duplicated -s # # pristine_detach initial && # test_must_fail git cherry-pick -s picked-signed && # git commit -a -s && # test $(git show -s |grep -c "Signed-off-by") = 1 #

The crash happens during the `git commit -a -s` with a backtrace like this:

Program received signal SIGSEGV, Segmentation fault.
0x000000000050bcf1 in entry_equals (map=0x8cef80 <the_index+64>,
e1=0xa2d2d2d2d2d2d00, e2=0x7fffffffce10,
    keydata=0x0) at hashmap.c:98
98              return (e1 == e2) || (e1->hash == e2->hash &&
!map->cmpfn(e1, e2, keydata));
(gdb) bt
#0  0x000000000050bcf1 in entry_equals (map=0x8cef80 <the_index+64>,
e1=0xa2d2d2d2d2d2d00, e2=0x7fffffffce10,
    keydata=0x0) at hashmap.c:98
#1  0x000000000050bec6 in find_entry_ptr (map=0x8cef80 <the_index+64>,
key=0x7fffffffce10, keydata=0x0)
    at hashmap.c:138
#2  0x000000000050c044 in hashmap_get (map=0x8cef80 <the_index+64>,
key=0x7fffffffce10, keydata=0x0)
    at hashmap.c:182
#3  0x0000000000525a1d in hashmap_get_from_hash (map=0x8cef80
<the_index+64>, hash=1625022057, keydata=0x0)
    at hashmap.h:78
#4  0x0000000000526edd in index_file_exists (istate=0x8cef40
<the_index>, name=0x8f19d0 "unrelated",
    namelen=9, icase=0) at name-hash.c:701
#5  0x00000000004f55ba in treat_one_path (dir=0x7fffffffd0b0,
untracked=0x0, istate=0x8cef40 <the_index>,
    path=0x7fffffffcf80, baselen=0, pathspec=0x88c2b8 <s+24>, dtype=8,
de=0x8f8a00) at dir.c:1550
#6  0x00000000004f5914 in treat_path (dir=0x7fffffffd0b0,
untracked=0x0, cdir=0x7fffffffcfa0,
    istate=0x8cef40 <the_index>, path=0x7fffffffcf80, baselen=0,
pathspec=0x88c2b8 <s+24>) at dir.c:1660
#7  0x00000000004f6006 in read_directory_recursive
(dir=0x7fffffffd0b0, istate=0x8cef40 <the_index>,
    base=0x61561b "", baselen=0, untracked=0x0, check_only=0,
pathspec=0x88c2b8 <s+24>) at dir.c:1809

It bisects to f9d7abec2a (split-index: add and use unshare_split_index(), 2017-05-05) that is fixing memory leaks when discarding the index. It looks like we are freeing some cache entries that we shouldn't free.

Christian Couder <christian.couder@gmail.com> writes:

Ouch. Let's revert the merge for now so that we can figure out what is exactly broken in 'pu'.