* Re: Git Stash brake splitIndex
2020-04-28 13:19 Git Stash brake splitIndex Son Luong Ngoc
@ 2020-04-28 13:57 ` Christian Couder
2020-04-28 14:17 ` Son Luong Ngoc
2020-05-04 10:26 ` Alban Gruin
1 sibling, 1 reply; 4+ messages in thread
From: Christian Couder @ 2020-04-28 13:57 UTC (permalink / raw)
To: Son Luong Ngoc; +Cc: git, Junio C Hamano
Hi,
On Tue, Apr 28, 2020 at 3:21 PM Son Luong Ngoc <sluongng@gmail.com> wrote:
> I am on git version 2.26.2.526.g744177e7f7 (latest next)
> When you do a git stash while using splitIndex, it seems like the index will get corrupted
>
> Using configs:
> core.splitindex=true
> splitindex.maxpercentchange=50
> splitindex.sharedindexexpire=now
>
> Reproduce steps:
>
> mkdir repo
> cd repo && git init
> echo a > a
> commit -a -m 'add a'
It looks like it should be `git commit -a -m 'add a'`
When I try to reproduce the steps using git version 2.26.2.526.g744177e7f7:
mkdir repo
cd repo && git init
git config core.splitindex true
git config splitindex.maxpercentchange 50
git config splitindex.sharedindexexpire now
echo a > a
git commit -a -m 'add a'
I get a segfault then:
Program received signal SIGSEGV, Segmentation fault.
0x00005555556ccf89 in ewah_each_bit (self=0x0, callback=0x5555557af648
<replace_entry>, payload=0x555555b47480 <the_index>)
at ewah/ewah_bitmap.c:252
252 while (pointer < self->buffer_size) {
(gdb) bt
#0 0x00005555556ccf89 in ewah_each_bit (self=0x0,
callback=0x5555557af648 <replace_entry>, payload=0x555555b47480
<the_index>)
at ewah/ewah_bitmap.c:252
#1 0x00005555557af90c in merge_base_index (istate=0x555555b47480
<the_index>) at split-index.c:162
#2 0x0000555555748b9f in read_index_from (istate=0x555555b47480
<the_index>, path=0x555555b4cd80 ".git/index",
gitdir=0x555555b4ac20 ".git") at read-cache.c:2335
#3 0x000055555576faf3 in repo_read_index (repo=0x555555b33f20
<the_repo>) at repository.c:271
#4 0x000055555559b91b in prepare_to_commit (index_file=0x555555b4d760
"/tmp/git/repo/.git/index.lock", prefix=0x0,
current_head=0x0, s=0x555555b04420 <s>,
author_ident=0x7fffffffd810) at builtin/commit.c:927
#5 0x000055555559d6a4 in cmd_commit (argc=0, argv=0x7fffffffdcf0,
prefix=0x0) at builtin/commit.c:1595
#6 0x0000555555570fda in run_builtin (p=0x555555af1218
<commands+504>, argc=4, argv=0x7fffffffdcf0) at git.c:447
#7 0x000055555557134b in handle_builtin (argc=4, argv=0x7fffffffdcf0)
at git.c:672
#8 0x0000555555571610 in run_argv (argcp=0x7fffffffdb9c,
argv=0x7fffffffdb90) at git.c:739
#9 0x0000555555571aba in cmd_main (argc=4, argv=0x7fffffffdcf0) at git.c:870
#10 0x0000555555641bc4 in main (argc=5, argv=0x7fffffffdce8) at common-main.c:52
It looks like merge_base_index() in split-index.c is calling
ewah_each_bit(si->replace_bitmap, replace_entry, istate) when
si->replace_bitmap is NULL.
^ permalink raw reply [flat|nested] 4+ messages in thread* Re: Git Stash brake splitIndex
2020-04-28 13:19 Git Stash brake splitIndex Son Luong Ngoc
2020-04-28 13:57 ` Christian Couder
@ 2020-05-04 10:26 ` Alban Gruin
1 sibling, 0 replies; 4+ messages in thread
From: Alban Gruin @ 2020-05-04 10:26 UTC (permalink / raw)
To: Son Luong Ngoc, git; +Cc: Junio C Hamano
Hi,
Le 28/04/2020 à 15:19, Son Luong Ngoc a écrit :
> Hi folks,
>
> I am on git version 2.26.2.526.g744177e7f7 (latest next)
> When you do a git stash while using splitIndex, it seems like the index will get corrupted
>
> Using configs:
> core.splitindex=true
> splitindex.maxpercentchange=50
> splitindex.sharedindexexpire=now
>
> Reproduce steps:
>
> mkdir repo
> cd repo && git init
> echo a > a
> commit -a -m 'add a'
> echo b > b
> git add b
> git stash
> Saved working directory and index state WIP on master: 1955b62 add a
> fatal: .git/sharedindex.8ddd8dad6ccb4858f27d4ff20f4d8bf6654441e0: index file open failed: No such file or directory
>
> Some traces:
> master ~/test/git/repo> GIT_TRACE2=1 GIT_TRACE2_NESTING=5 git stash
> 15:18:15.442295 common-main.c:48 version 2.26.2.526.g744177e7f7
> 15:18:15.442914 common-main.c:49 start git stash
> 15:18:15.443284 repository.c:134 worktree /Users/sluongngoc/test/git/repo
> 15:18:15.443491 git.c:442 cmd_name stash (stash)
> 15:18:15.448579 run-command.c:735 child_start[0] git update-index --ignore-skip-worktree-entries -z --add --remove --stdin
> 15:18:15.455972 common-main.c:48 version 2.26.2.526.g744177e7f7
> 15:18:15.456514 common-main.c:49 start /Users/sluongngoc/libexec/git-core/git update-index --ignore-skip-worktree-entries -z --add --remove --stdin
> 15:18:15.456788 repository.c:134 worktree /Users/sluongngoc/test/git/repo
> 15:18:15.456927 git.c:442 cmd_name update-index (stash/update-index)
> 15:18:15.458444 git.c:672 exit elapsed:0.004021 code:0
> 15:18:15.458457 trace2/tr2_tgt_normal.c:123 atexit elapsed:0.004039 code:0
> 15:18:15.458774 run-command.c:990 child_exit[0] pid:1813 code:0 elapsed:0.010169
> Saved working directory and index state WIP on master: 1955b62 add a
> 15:18:15.461082 run-command.c:735 child_start[1] git reset --hard -q --no-recurse-submodules
> 15:18:15.467260 common-main.c:48 version 2.26.2.526.g744177e7f7
> 15:18:15.467553 common-main.c:49 start /Users/sluongngoc/libexec/git-core/git reset --hard -q --no-recurse-submodules
> 15:18:15.467931 repository.c:134 worktree /Users/sluongngoc/test/git/repo
> 15:18:15.468071 git.c:442 cmd_name reset (stash/reset)
> 15:18:15.468555 usage.c:64 error .git/sharedindex.8ddd8dad6ccb4858f27d4ff20f4d8bf6654441e0: index file open failed: No such file or directory
> fatal: .git/sharedindex.8ddd8dad6ccb4858f27d4ff20f4d8bf6654441e0: index file open failed: No such file or directory
> 15:18:15.468587 usage.c:68 exit elapsed:0.002714 code:128
> 15:18:15.468595 trace2/tr2_tgt_normal.c:123 atexit elapsed:0.002726 code:128
> 15:18:15.468889 run-command.c:990 child_exit[1] pid:1814 code:128 elapsed:0.007797
> 15:18:15.468930 git.c:672 exit elapsed:0.028400 code:1
> 15:18:15.468947 trace2/tr2_tgt_normal.c:123 atexit elapsed:0.028418 code:1
> exit 1
>
Thank you for the bug report.
Looking at git-stash.c, it uses a second index, which is sometimes a
copy of the first. At least, it's the case in stash_working_tree(),
used by `git stash': in do_create_stash(), &info->i_tree is created to
save the content of the index, then save_untracked_files() is skipped as
we did not call stash with the `--include-untracked' switch, then
stash_working_tree() is called as we are not in patch mode. Here, the
index did not change. stash_working_tree() then unpacks &info->i_tree
in a second index.
After this, `git update-index' is called, which modifies the second
index. This is not a problem in the non-split-index case, because both
index are stand alone; they can be modified without interfering with the
other. But not in the split-index case -- as the second is a copy of
the first one, and they both point to the same shared index file.
Modifying the second will delete this file (as the expiration is set to
"now") and create another one. So, anything using the first index will
try to open a file that no longer exists, and crash.
Here, `git reset' crashes (in do_create_stash(), after
stash_working_tree() returned), but adding a `discard_cache();
read_cache();' after running `update-index' (in stash_working_tree())
makes it crash at `read_cache();'.
Your configuration is a bit extreme, but I worry that it may happen with
`splitindex.sharedindexexpire' set to a higher value, albeit much less
frequently.
This double-index thing came from the shell script, perhaps it's about
time to remove it. I worked on a series to remove it this week-end, and
it fixes this crash. I still have to write the commit messages, then I
will send it to the list.
> Cheers,
> Son Luong.
>
Cheers,
Alban
^ permalink raw reply [flat|nested] 4+ messages in thread