Re: Git Stash brake splitIndex

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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




[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]

  Powered by Linux