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

2017-06-24 Thread Junio C Hamano
Christian Couder  writes:

> 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.

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



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

2017-06-24 Thread Christian Couder
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 ' or 'git rm '
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.
0x0050bcf1 in entry_equals (map=0x8cef80 ,
e1=0xa2d2d2d2d2d2d00, e2=0x7fffce10,
keydata=0x0) at hashmap.c:98
98  return (e1 == e2) || (e1->hash == e2->hash &&
!map->cmpfn(e1, e2, keydata));
(gdb) bt
#0  0x0050bcf1 in entry_equals (map=0x8cef80 ,
e1=0xa2d2d2d2d2d2d00, e2=0x7fffce10,
keydata=0x0) at hashmap.c:98
#1  0x0050bec6 in find_entry_ptr (map=0x8cef80 ,
key=0x7fffce10, keydata=0x0)
at hashmap.c:138
#2  0x0050c044 in hashmap_get (map=0x8cef80 ,
key=0x7fffce10, keydata=0x0)
at hashmap.c:182
#3  0x00525a1d in hashmap_get_from_hash (map=0x8cef80
, hash=1625022057, keydata=0x0)
at hashmap.h:78
#4  0x00526edd in index_file_exists (istate=0x8cef40
, name=0x8f19d0 "unrelated",
namelen=9, icase=0) at name-hash.c:701
#5  0x004f55ba in treat_one_path (dir=0x7fffd0b0,
untracked=0x0, istate=0x8cef40 ,
path=0x7fffcf80, baselen=0, pathspec=0x88c2b8 , dtype=8,
de=0x8f8a00) at dir.c:1550
#6  0x004f5914 in treat_path (dir=0x7fffd0b0,
untracked=0x0, cdir=0x7fffcfa0,
istate=0x8cef40 , path=0x7fffcf80, baselen=0,
pathspec=0x88c2b8 ) at dir.c:1660
#7  0x004f6006 in read_directory_recursive
(dir=0x7fffd0b0, istate=0x8cef40 ,
base=0x61561b "", baselen=0, untracked=0x0, check_only=0,
pathspec=0x88c2b8 ) 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.