SDK installer should have "reset" button for component selection #22
Labels
Comments
|
I am closing this because we decided to jump to MSys2 right ahead. Therefore, we won't have a |
jeffhostetler
pushed a commit
to jeffhostetler/git
that referenced
this issue
Oct 1, 2018
…ndex-gvfs Enable the filesystem cache (fscache) in refresh_index().
sceptical-coder
added a commit
to sceptical-coder/git
that referenced
this issue
Oct 30, 2022
In some setups, old-style submodules (i.e. the ones
with .git directory within theirs worktrees) with commondir
can be of tremendous help. For example, commondir link can be
used to avoid duplication of objects and also to keep branches
in sync with multiple copies of the repo's worktree, while keeping
the .git directory inside the worktree can be (ab?-)used to exploit
the sharing of the same submodule worktree across different projects
(this at least works on Windows with submodule directory being
a directory junction, but having a junction is not relevant for
reproducing the bug described below).
Unfortunately, at the moment, when `git status` is run in the root repo
of such a setup, it gives an output akin to this:
```sh
fatal: unable to access '�??\1?/config': Invalid argument
fatal: 'git status --porcelain=2' failed in submodule commonlibs
```
where `�??\1?` part of '�??\1?/config' varies from run to run, and
`commonlibs` is the name of submodule's directory.
Currently, when Git discovers old-style submodule , it spawns subprocess
to get its status, like this one:
```sh
cd commonlibs; unset GIT_PREFIX; GIT_DIR=.git git status --porcelain=2
```
Unsurprisingly, the following output is also quite unexpected:
```
fatal: unable to access '`??L&?/config': Invalid argument
```
The core reason for these is that global repository field for
commondir is not being cleared to `NULL` after being `free()`'d
in `repo_set_commondir()`, which is precisely what this commit fixes.
Regarding the further details of the case of investigation,
this value of struct pointed by the global `the_repository` pointer is
checked for being not-NULL down in the callstack in compatibility layer
for MinGW in a function that is called by `repo_set_commondir()` before
the `free()`'d value gets assigned in its body (i.e. the body of
`repo_set_commondir()`).
Backtrace from the check is:
#0 mingw_open (filename=0x<address-25> ".git/commondir", oflags=0)
at compat/mingw.c:784
git-for-windows#1 0x<address-27> in strbuf_read_file (sb=0x<address-26>,
path=0x<address-25> ".git/commondir", hint=0) at strbuf.c:758
git-for-windows#2 0x<address-24> in get_common_dir_noenv (sb=0x<address-23>,
gitdir=0x<address-22> ".git") at setup.c:313
git-for-windows#3 0x<address-21> in repo_set_commondir (repo=0x<address-19> <the_repo>,
commondir=0x0) at repository.c:57
git-for-windows#4 0x<address-20> in repo_set_gitdir (repo=0x<address-19> <the_repo>,
root=0x<address-15> ".git", o=0x<address-18>) at repository.c:76
git-for-windows#5 0x<address-17> in setup_git_env (git_dir=0x<address-15> ".git")
at environment.c:179
git-for-windows#6 0x<address-16> in set_git_dir_1 (path=0x<address-15> ".git")
at environment.c:334
git-for-windows#7 0x<address-14> in update_relative_gitdir (name=0x0,
old_cwd=0x<address-13> "C:/Users/%username%/<root-repo-name>/commonlibs",
new_cwd=0x<address-11> "C:/Users/%username%/<root-repo-name>/commonlibs", data=0x0) at environment.c:348
git-for-windows#8 0x<address-12> in chdir_notify (
new_cwd=0x<address-11> "C:/Users/%username%/<root-repo-name>/commonlibs") at chdir-notify.c:72
git-for-windows#9 0x<address-10> in setup_work_tree () at setup.c:428
git-for-windows#10 0x<address-9> in run_builtin (p=0x<address-8> <commands+2856>,
argc=2, argv=0x<address-2>) at git.c:458
git-for-windows#11 0x<address-7> in handle_builtin (argc=2, argv=0x<address-2>)
at git.c:721
git-for-windows#12 0x<address-6> in run_argv (argcp=0x<address-5>, argv=0x<address-4>)
at git.c:788
git-for-windows#13 0x<address-3> in cmd_main (argc=2, argv=0x<address-2>) at git.c:921
git-for-windows#14 0x<address-1> in main (argc=6, argv=0x<address-0>)
at common-main.c:56
Backtrace from the death is:
#0 die_errno (fmt=0x<address-42> <result_type+2002> "unable to access '%s'")
at usage.c:210
git-for-windows#1 0x<address-41> in access_or_die (
path=0x<address-40> "`\001\r��\004/config", mode=4, flag=0)
at wrapper.c:667
git-for-windows#2 0x<address-39> in do_git_config_sequence (opts=0x<address-35>,
fn=0x<address-37> <git_config_include>, data=0x<address-36>)
at config.c:2142
git-for-windows#3 0x<address-38> in config_with_options (
fn=0x<address-37> <git_config_include>, data=0x<address-36>,
config_source=0x0, opts=0x<address-35>) at config.c:2198
git-for-windows#4 0x<address-34> in repo_read_config (repo=0x<address-19> <the_repo>)
at config.c:2524
git-for-windows#5 0x<address-33> in git_config_check_init (
repo=0x<address-19> <the_repo>) at config.c:2543
git-for-windows#6 0x<address-32> in repo_config_get_bool (
repo=0x<address-19> <the_repo>,
key=0x<address-30> <pad+3116> "windows.appendatomically",
dest=0x<address-29> <append_atomically>) at config.c:2612
git-for-windows#7 0x<address-31> in git_config_get_bool (
key=0x<address-30> <pad+3116> "windows.appendatomically",
dest=0x<address-29> <append_atomically>) at config.c:2714
git-for-windows#8 0x<address-28> in mingw_open (
filename=0x<address-25> ".git/commondir", oflags=0) at compat/mingw.c:785
git-for-windows#9 0x<address-27> in strbuf_read_file (sb=0x<address-26>,
path=0x<address-25> ".git/commondir", hint=0) at strbuf.c:758
git-for-windows#10 0x<address-24> in get_common_dir_noenv (sb=0x<address-23>,
gitdir=0x<address-22> ".git") at setup.c:313
git-for-windows#11 0x<address-21> in repo_set_commondir (repo=0x<address-19> <the_repo>,
commondir=0x0) at repository.c:57
git-for-windows#12 0x<address-20> in repo_set_gitdir (repo=0x<address-19> <the_repo>,
root=0x<address-15> ".git", o=0x<address-18>) at repository.c:76
git-for-windows#13 0x<address-17> in setup_git_env (git_dir=0x<address-15> ".git")
at environment.c:179
git-for-windows#14 0x<address-16> in set_git_dir_1 (path=0x<address-15> ".git")
at environment.c:334
git-for-windows#15 0x<address-14> in update_relative_gitdir (name=0x0,
old_cwd=0x<address-13> "C:/Users/%username%/<root-repo-name>/commonlibs",
new_cwd=0x<address-11> "C:/Users/%username%/<root-repo-name>/commonlibs", data=0x0) at environment.c:348
git-for-windows#16 0x<address-12> in chdir_notify (
new_cwd=0x<address-11> "C:/Users/%username%/<root-repo-name>/commonlibs") at chdir-notify.c:72
git-for-windows#17 0x<address-10> in setup_work_tree () at setup.c:428
git-for-windows#18 0x<address-9> in run_builtin (p=0x<address-8> <commands+2856>,
argc=2, argv=0x<address-2>) at git.c:458
git-for-windows#19 0x<address-7> in handle_builtin (argc=2, argv=0x<address-2>)
at git.c:721
git-for-windows#20 0x<address-6> in run_argv (argcp=0x<address-5>, argv=0x<address-4>)
at git.c:788
git-for-windows#21 0x<address-3> in cmd_main (argc=2, argv=0x<address-2>) at git.c:921
git-for-windows#22 0x<address-1> in main (argc=6, argv=0x<address-0>)
at common-main.c:56
Signed-off-by: Andrey Zabavnikov <zabavnikov@gmail.com>
sceptical-coder
added a commit
to sceptical-coder/git
that referenced
this issue
Oct 31, 2022
In some setups, old-style submodules (i.e. the ones
with .git directory within theirs worktrees) with commondir
can be of tremendous help. For example, commondir link can be
used to avoid duplication of objects and also to keep branches
in sync with multiple copies of the repo's worktree, while keeping
the .git directory inside the worktree can be (ab?-)used to exploit
the sharing of the same submodule worktree across different projects
(this at least works on Windows with submodule directory being
a directory junction, but having a junction is not relevant for
reproducing the bug described below).
Unfortunately, at the moment, when `git status` is run in the root repo
of such a setup, it gives an output akin to this:
```sh
fatal: unable to access '�??\1?/config': Invalid argument
fatal: 'git status --porcelain=2' failed in submodule commonlibs
```
where `�??\1?` part of '�??\1?/config' varies from run to run, and
`commonlibs` is the name of submodule's directory.
Currently, when Git discovers old-style submodule , it spawns subprocess
to get its status, like this one:
```sh
cd commonlibs; unset GIT_PREFIX; GIT_DIR=.git git status --porcelain=2
```
Unsurprisingly, the following output is also quite unexpected:
```
fatal: unable to access '`??L&?/config': Invalid argument
```
The core reason for these is that global repository field for
commondir is not being cleared to `NULL` after being `free()`'d
in `repo_set_commondir()`, which is precisely what this commit fixes.
Regarding the further details of the case of investigation,
this value of struct pointed by the global `the_repository` pointer is
checked for being not-NULL down in the callstack in compatibility layer
for MinGW in a function that is called by `repo_set_commondir()` before
the `free()`'d value gets assigned in its body (i.e. the body of
`repo_set_commondir()`).
Backtrace from the check is:
```
#0 mingw_open (filename=0x<address-25> ".git/commondir", oflags=0)
at compat/mingw.c:784
git-for-windows#1 0x<address-27> in strbuf_read_file (sb=0x<address-26>,
path=0x<address-25> ".git/commondir", hint=0) at strbuf.c:758
git-for-windows#2 0x<address-24> in get_common_dir_noenv (sb=0x<address-23>,
gitdir=0x<address-22> ".git") at setup.c:313
git-for-windows#3 0x<address-21> in repo_set_commondir (repo=0x<address-19> <the_repo>,
commondir=0x0) at repository.c:57
git-for-windows#4 0x<address-20> in repo_set_gitdir (repo=0x<address-19> <the_repo>,
root=0x<address-15> ".git", o=0x<address-18>) at repository.c:76
git-for-windows#5 0x<address-17> in setup_git_env (git_dir=0x<address-15> ".git")
at environment.c:179
git-for-windows#6 0x<address-16> in set_git_dir_1 (path=0x<address-15> ".git")
at environment.c:334
git-for-windows#7 0x<address-14> in update_relative_gitdir (name=0x0,
old_cwd=0x<address-13> "C:/Users/%username%/<root-repo-name>/commonlibs",
new_cwd=0x<address-11> "C:/Users/%username%/<root-repo-name>/commonlibs", data=0x0) at environment.c:348
git-for-windows#8 0x<address-12> in chdir_notify (
new_cwd=0x<address-11> "C:/Users/%username%/<root-repo-name>/commonlibs") at chdir-notify.c:72
git-for-windows#9 0x<address-10> in setup_work_tree () at setup.c:428
git-for-windows#10 0x<address-9> in run_builtin (p=0x<address-8> <commands+2856>,
argc=2, argv=0x<address-2>) at git.c:458
git-for-windows#11 0x<address-7> in handle_builtin (argc=2, argv=0x<address-2>)
at git.c:721
git-for-windows#12 0x<address-6> in run_argv (argcp=0x<address-5>, argv=0x<address-4>)
at git.c:788
git-for-windows#13 0x<address-3> in cmd_main (argc=2, argv=0x<address-2>) at git.c:921
git-for-windows#14 0x<address-1> in main (argc=6, argv=0x<address-0>)
at common-main.c:56
```
Backtrace from the death is:
```
#0 die_errno (fmt=0x<address-42> <result_type+2002> "unable to access '%s'")
at usage.c:210
git-for-windows#1 0x<address-41> in access_or_die (
path=0x<address-40> "`\001\r��\004/config", mode=4, flag=0)
at wrapper.c:667
git-for-windows#2 0x<address-39> in do_git_config_sequence (opts=0x<address-35>,
fn=0x<address-37> <git_config_include>, data=0x<address-36>)
at config.c:2142
git-for-windows#3 0x<address-38> in config_with_options (
fn=0x<address-37> <git_config_include>, data=0x<address-36>,
config_source=0x0, opts=0x<address-35>) at config.c:2198
git-for-windows#4 0x<address-34> in repo_read_config (repo=0x<address-19> <the_repo>)
at config.c:2524
git-for-windows#5 0x<address-33> in git_config_check_init (
repo=0x<address-19> <the_repo>) at config.c:2543
git-for-windows#6 0x<address-32> in repo_config_get_bool (
repo=0x<address-19> <the_repo>,
key=0x<address-30> <pad+3116> "windows.appendatomically",
dest=0x<address-29> <append_atomically>) at config.c:2612
git-for-windows#7 0x<address-31> in git_config_get_bool (
key=0x<address-30> <pad+3116> "windows.appendatomically",
dest=0x<address-29> <append_atomically>) at config.c:2714
git-for-windows#8 0x<address-28> in mingw_open (
filename=0x<address-25> ".git/commondir", oflags=0) at compat/mingw.c:785
git-for-windows#9 0x<address-27> in strbuf_read_file (sb=0x<address-26>,
path=0x<address-25> ".git/commondir", hint=0) at strbuf.c:758
git-for-windows#10 0x<address-24> in get_common_dir_noenv (sb=0x<address-23>,
gitdir=0x<address-22> ".git") at setup.c:313
git-for-windows#11 0x<address-21> in repo_set_commondir (repo=0x<address-19> <the_repo>,
commondir=0x0) at repository.c:57
git-for-windows#12 0x<address-20> in repo_set_gitdir (repo=0x<address-19> <the_repo>,
root=0x<address-15> ".git", o=0x<address-18>) at repository.c:76
git-for-windows#13 0x<address-17> in setup_git_env (git_dir=0x<address-15> ".git")
at environment.c:179
git-for-windows#14 0x<address-16> in set_git_dir_1 (path=0x<address-15> ".git")
at environment.c:334
git-for-windows#15 0x<address-14> in update_relative_gitdir (name=0x0,
old_cwd=0x<address-13> "C:/Users/%username%/<root-repo-name>/commonlibs",
new_cwd=0x<address-11> "C:/Users/%username%/<root-repo-name>/commonlibs", data=0x0) at environment.c:348
git-for-windows#16 0x<address-12> in chdir_notify (
new_cwd=0x<address-11> "C:/Users/%username%/<root-repo-name>/commonlibs") at chdir-notify.c:72
git-for-windows#17 0x<address-10> in setup_work_tree () at setup.c:428
git-for-windows#18 0x<address-9> in run_builtin (p=0x<address-8> <commands+2856>,
argc=2, argv=0x<address-2>) at git.c:458
git-for-windows#19 0x<address-7> in handle_builtin (argc=2, argv=0x<address-2>)
at git.c:721
git-for-windows#20 0x<address-6> in run_argv (argcp=0x<address-5>, argv=0x<address-4>)
at git.c:788
git-for-windows#21 0x<address-3> in cmd_main (argc=2, argv=0x<address-2>) at git.c:921
git-for-windows#22 0x<address-1> in main (argc=6, argv=0x<address-0>)
at common-main.c:56
```
Signed-off-by: Andrey Zabavnikov <zabavnikov@gmail.com>
sceptical-coder
added a commit
to sceptical-coder/git
that referenced
this issue
Nov 3, 2022
In some setups, old-style submodules (i.e. the ones
with .git directory within theirs worktrees) with commondir
can be of tremendous help. For example, commondir link can be
used to avoid duplication of objects and also to keep branches
in sync with multiple copies of the repo's worktree, while keeping
the .git directory inside the worktree can be (ab?-)used to exploit
the sharing of the same submodule worktree across different projects
(this at least works on Windows with submodule directory being
a directory junction, but having a junction is not relevant for
reproducing the bug described below).
Unfortunately, at the moment, when `git status` is run in the root repo
of such a setup, it gives an output akin to this:
```sh
fatal: unable to access '�??\1?/config': Invalid argument
fatal: 'git status --porcelain=2' failed in submodule commonlibs
```
where `�??\1?` part of '�??\1?/config' varies from run to run, and
`commonlibs` is the name of submodule's directory.
Currently, when Git discovers old-style submodule , it spawns subprocess
to get its status, like this one:
```sh
cd commonlibs; unset GIT_PREFIX; GIT_DIR=.git git status --porcelain=2
```
Unsurprisingly, the following output is also quite unexpected:
```
fatal: unable to access '`??L&?/config': Invalid argument
```
The core reason for these is that global repository field for
commondir is not being cleared to `NULL` after being `free()`'d
in `repo_set_commondir()`, which is precisely what this commit fixes.
Regarding the further details of the case of investigation,
this value of struct pointed by the global `the_repository` pointer is
checked for being not-NULL down in the callstack in compatibility layer
for MinGW in a function that is called by `repo_set_commondir()` before
the `free()`'d value gets assigned in its body (i.e. the body of
`repo_set_commondir()`).
Backtrace from the check is:
```
#0 mingw_open (filename=0x<address-25> ".git/commondir", oflags=0)
at compat/mingw.c:784
git-for-windows#1 0x<address-27> in strbuf_read_file (sb=0x<address-26>,
path=0x<address-25> ".git/commondir", hint=0) at strbuf.c:758
git-for-windows#2 0x<address-24> in get_common_dir_noenv (sb=0x<address-23>,
gitdir=0x<address-22> ".git") at setup.c:313
git-for-windows#3 0x<address-21> in repo_set_commondir (repo=0x<address-19> <the_repo>,
commondir=0x0) at repository.c:57
git-for-windows#4 0x<address-20> in repo_set_gitdir (repo=0x<address-19> <the_repo>,
root=0x<address-15> ".git", o=0x<address-18>) at repository.c:76
git-for-windows#5 0x<address-17> in setup_git_env (git_dir=0x<address-15> ".git")
at environment.c:179
git-for-windows#6 0x<address-16> in set_git_dir_1 (path=0x<address-15> ".git")
at environment.c:334
git-for-windows#7 0x<address-14> in update_relative_gitdir (name=0x0,
old_cwd=0x<address-13> "C:/Users/%username%/<root-repo-name>/commonlibs",
new_cwd=0x<address-11> "C:/Users/%username%/<root-repo-name>/commonlibs", data=0x0) at environment.c:348
git-for-windows#8 0x<address-12> in chdir_notify (
new_cwd=0x<address-11> "C:/Users/%username%/<root-repo-name>/commonlibs") at chdir-notify.c:72
git-for-windows#9 0x<address-10> in setup_work_tree () at setup.c:428
git-for-windows#10 0x<address-9> in run_builtin (p=0x<address-8> <commands+2856>,
argc=2, argv=0x<address-2>) at git.c:458
git-for-windows#11 0x<address-7> in handle_builtin (argc=2, argv=0x<address-2>)
at git.c:721
git-for-windows#12 0x<address-6> in run_argv (argcp=0x<address-5>, argv=0x<address-4>)
at git.c:788
git-for-windows#13 0x<address-3> in cmd_main (argc=2, argv=0x<address-2>) at git.c:921
git-for-windows#14 0x<address-1> in main (argc=6, argv=0x<address-0>)
at common-main.c:56
```
Backtrace from the death is:
```
#0 die_errno (fmt=0x<address-42> <result_type+2002> "unable to access '%s'")
at usage.c:210
git-for-windows#1 0x<address-41> in access_or_die (
path=0x<address-40> "`\001\r��\004/config", mode=4, flag=0)
at wrapper.c:667
git-for-windows#2 0x<address-39> in do_git_config_sequence (opts=0x<address-35>,
fn=0x<address-37> <git_config_include>, data=0x<address-36>)
at config.c:2142
git-for-windows#3 0x<address-38> in config_with_options (
fn=0x<address-37> <git_config_include>, data=0x<address-36>,
config_source=0x0, opts=0x<address-35>) at config.c:2198
git-for-windows#4 0x<address-34> in repo_read_config (repo=0x<address-19> <the_repo>)
at config.c:2524
git-for-windows#5 0x<address-33> in git_config_check_init (
repo=0x<address-19> <the_repo>) at config.c:2543
git-for-windows#6 0x<address-32> in repo_config_get_bool (
repo=0x<address-19> <the_repo>,
key=0x<address-30> <pad+3116> "windows.appendatomically",
dest=0x<address-29> <append_atomically>) at config.c:2612
git-for-windows#7 0x<address-31> in git_config_get_bool (
key=0x<address-30> <pad+3116> "windows.appendatomically",
dest=0x<address-29> <append_atomically>) at config.c:2714
git-for-windows#8 0x<address-28> in mingw_open (
filename=0x<address-25> ".git/commondir", oflags=0) at compat/mingw.c:785
git-for-windows#9 0x<address-27> in strbuf_read_file (sb=0x<address-26>,
path=0x<address-25> ".git/commondir", hint=0) at strbuf.c:758
git-for-windows#10 0x<address-24> in get_common_dir_noenv (sb=0x<address-23>,
gitdir=0x<address-22> ".git") at setup.c:313
git-for-windows#11 0x<address-21> in repo_set_commondir (repo=0x<address-19> <the_repo>,
commondir=0x0) at repository.c:57
git-for-windows#12 0x<address-20> in repo_set_gitdir (repo=0x<address-19> <the_repo>,
root=0x<address-15> ".git", o=0x<address-18>) at repository.c:76
git-for-windows#13 0x<address-17> in setup_git_env (git_dir=0x<address-15> ".git")
at environment.c:179
git-for-windows#14 0x<address-16> in set_git_dir_1 (path=0x<address-15> ".git")
at environment.c:334
git-for-windows#15 0x<address-14> in update_relative_gitdir (name=0x0,
old_cwd=0x<address-13> "C:/Users/%username%/<root-repo-name>/commonlibs",
new_cwd=0x<address-11> "C:/Users/%username%/<root-repo-name>/commonlibs", data=0x0) at environment.c:348
git-for-windows#16 0x<address-12> in chdir_notify (
new_cwd=0x<address-11> "C:/Users/%username%/<root-repo-name>/commonlibs") at chdir-notify.c:72
git-for-windows#17 0x<address-10> in setup_work_tree () at setup.c:428
git-for-windows#18 0x<address-9> in run_builtin (p=0x<address-8> <commands+2856>,
argc=2, argv=0x<address-2>) at git.c:458
git-for-windows#19 0x<address-7> in handle_builtin (argc=2, argv=0x<address-2>)
at git.c:721
git-for-windows#20 0x<address-6> in run_argv (argcp=0x<address-5>, argv=0x<address-4>)
at git.c:788
git-for-windows#21 0x<address-3> in cmd_main (argc=2, argv=0x<address-2>) at git.c:921
git-for-windows#22 0x<address-1> in main (argc=6, argv=0x<address-0>)
at common-main.c:56
```
Signed-off-by: Andrey Zabavnikov <zabavnikov@gmail.com>
sceptical-coder
added a commit
to sceptical-coder/git
that referenced
this issue
Nov 3, 2022
In some setups, old-style submodules (i.e. the ones
with .git directory within theirs worktrees) with commondir
can be of tremendous help. For example, commondir link can be
used to avoid duplication of objects and also to keep branches
in sync with multiple copies of the repo's worktree, while keeping
the .git directory inside the worktree can be (ab?-)used to exploit
the sharing of the same submodule worktree across different projects
(this at least works on Windows with submodule directory being
a directory junction, but having a junction is not relevant for
reproducing the bug described below).
Unfortunately, at the moment, when `git status` is run in the root repo
of such a setup, it gives an output akin to this:
```sh
fatal: unable to access '�??\1?/config': Invalid argument
fatal: 'git status --porcelain=2' failed in submodule commonlibs
```
where `�??\1?` part of '�??\1?/config' varies from run to run, and
`commonlibs` is the name of submodule's directory.
Currently, when Git discovers old-style submodule , it spawns subprocess
to get its status, like this one:
```sh
cd commonlibs; unset GIT_PREFIX; GIT_DIR=.git git status --porcelain=2
```
Unsurprisingly, the following output is also quite unexpected:
```
fatal: unable to access '`??L&?/config': Invalid argument
```
The core reason for these is that global repository field for
commondir is not being cleared to `NULL` after being `free()`'d
in `repo_set_commondir()`, which is precisely what this commit fixes.
Regarding the further details of the case of investigation,
this value of struct pointed by the global `the_repository` pointer is
checked for being not-NULL down in the callstack in compatibility layer
for MinGW in a function that is called by `repo_set_commondir()` before
the `free()`'d value gets assigned in its body (i.e. the body of
`repo_set_commondir()`).
Backtrace from the check is:
```
#0 mingw_open (filename=0x<address-25> ".git/commondir", oflags=0)
at compat/mingw.c:784
git-for-windows#1 0x<address-27> in strbuf_read_file (sb=0x<address-26>,
path=0x<address-25> ".git/commondir", hint=0) at strbuf.c:758
git-for-windows#2 0x<address-24> in get_common_dir_noenv (sb=0x<address-23>,
gitdir=0x<address-22> ".git") at setup.c:313
git-for-windows#3 0x<address-21> in repo_set_commondir (repo=0x<address-19> <the_repo>,
commondir=0x0) at repository.c:57
git-for-windows#4 0x<address-20> in repo_set_gitdir (repo=0x<address-19> <the_repo>,
root=0x<address-15> ".git", o=0x<address-18>) at repository.c:76
git-for-windows#5 0x<address-17> in setup_git_env (git_dir=0x<address-15> ".git")
at environment.c:179
git-for-windows#6 0x<address-16> in set_git_dir_1 (path=0x<address-15> ".git")
at environment.c:334
git-for-windows#7 0x<address-14> in update_relative_gitdir (name=0x0,
old_cwd=0x<address-13> "C:/Users/%username%/<root-repo-name>/commonlibs",
new_cwd=0x<address-11> "C:/Users/%username%/<root-repo-name>/commonlibs", data=0x0) at environment.c:348
git-for-windows#8 0x<address-12> in chdir_notify (
new_cwd=0x<address-11> "C:/Users/%username%/<root-repo-name>/commonlibs") at chdir-notify.c:72
git-for-windows#9 0x<address-10> in setup_work_tree () at setup.c:428
git-for-windows#10 0x<address-9> in run_builtin (p=0x<address-8> <commands+2856>,
argc=2, argv=0x<address-2>) at git.c:458
git-for-windows#11 0x<address-7> in handle_builtin (argc=2, argv=0x<address-2>)
at git.c:721
git-for-windows#12 0x<address-6> in run_argv (argcp=0x<address-5>, argv=0x<address-4>)
at git.c:788
git-for-windows#13 0x<address-3> in cmd_main (argc=2, argv=0x<address-2>) at git.c:921
git-for-windows#14 0x<address-1> in main (argc=6, argv=0x<address-0>)
at common-main.c:56
```
Backtrace from the death is:
```
#0 die_errno (fmt=0x<address-42> <result_type+2002> "unable to access '%s'")
at usage.c:210
git-for-windows#1 0x<address-41> in access_or_die (
path=0x<address-40> "`\001\r��\004/config", mode=4, flag=0)
at wrapper.c:667
git-for-windows#2 0x<address-39> in do_git_config_sequence (opts=0x<address-35>,
fn=0x<address-37> <git_config_include>, data=0x<address-36>)
at config.c:2142
git-for-windows#3 0x<address-38> in config_with_options (
fn=0x<address-37> <git_config_include>, data=0x<address-36>,
config_source=0x0, opts=0x<address-35>) at config.c:2198
git-for-windows#4 0x<address-34> in repo_read_config (repo=0x<address-19> <the_repo>)
at config.c:2524
git-for-windows#5 0x<address-33> in git_config_check_init (
repo=0x<address-19> <the_repo>) at config.c:2543
git-for-windows#6 0x<address-32> in repo_config_get_bool (
repo=0x<address-19> <the_repo>,
key=0x<address-30> <pad+3116> "windows.appendatomically",
dest=0x<address-29> <append_atomically>) at config.c:2612
git-for-windows#7 0x<address-31> in git_config_get_bool (
key=0x<address-30> <pad+3116> "windows.appendatomically",
dest=0x<address-29> <append_atomically>) at config.c:2714
git-for-windows#8 0x<address-28> in mingw_open (
filename=0x<address-25> ".git/commondir", oflags=0) at compat/mingw.c:785
git-for-windows#9 0x<address-27> in strbuf_read_file (sb=0x<address-26>,
path=0x<address-25> ".git/commondir", hint=0) at strbuf.c:758
git-for-windows#10 0x<address-24> in get_common_dir_noenv (sb=0x<address-23>,
gitdir=0x<address-22> ".git") at setup.c:313
git-for-windows#11 0x<address-21> in repo_set_commondir (repo=0x<address-19> <the_repo>,
commondir=0x0) at repository.c:57
git-for-windows#12 0x<address-20> in repo_set_gitdir (repo=0x<address-19> <the_repo>,
root=0x<address-15> ".git", o=0x<address-18>) at repository.c:76
git-for-windows#13 0x<address-17> in setup_git_env (git_dir=0x<address-15> ".git")
at environment.c:179
git-for-windows#14 0x<address-16> in set_git_dir_1 (path=0x<address-15> ".git")
at environment.c:334
git-for-windows#15 0x<address-14> in update_relative_gitdir (name=0x0,
old_cwd=0x<address-13> "C:/Users/%username%/<root-repo-name>/commonlibs",
new_cwd=0x<address-11> "C:/Users/%username%/<root-repo-name>/commonlibs", data=0x0) at environment.c:348
git-for-windows#16 0x<address-12> in chdir_notify (
new_cwd=0x<address-11> "C:/Users/%username%/<root-repo-name>/commonlibs") at chdir-notify.c:72
git-for-windows#17 0x<address-10> in setup_work_tree () at setup.c:428
git-for-windows#18 0x<address-9> in run_builtin (p=0x<address-8> <commands+2856>,
argc=2, argv=0x<address-2>) at git.c:458
git-for-windows#19 0x<address-7> in handle_builtin (argc=2, argv=0x<address-2>)
at git.c:721
git-for-windows#20 0x<address-6> in run_argv (argcp=0x<address-5>, argv=0x<address-4>)
at git.c:788
git-for-windows#21 0x<address-3> in cmd_main (argc=2, argv=0x<address-2>) at git.c:921
git-for-windows#22 0x<address-1> in main (argc=6, argv=0x<address-0>)
at common-main.c:56
```
Signed-off-by: Andrey Zabavnikov <zabavnikov@gmail.com>
sceptical-coder
added a commit
to sceptical-coder/git
that referenced
this issue
Nov 3, 2022
In some setups, old-style submodules (i.e. the ones
with .git directory within theirs worktrees) with commondir
can be of tremendous help. For example, commondir link can be
used to avoid duplication of objects and also to keep branches
in sync with multiple copies of the repo's worktree, while keeping
the .git directory inside the worktree can be (ab?-)used to exploit
the sharing of the same submodule worktree across different projects
(this at least works on Windows with submodule directory being
a directory junction, but having a junction is not relevant for
reproducing the bug described below).
Unfortunately, at the moment, when `git status` is run in the root repo
of such a setup, it gives an output akin to this:
```sh
fatal: unable to access '�??\1?/config': Invalid argument
fatal: 'git status --porcelain=2' failed in submodule commonlibs
```
where `�??\1?` part of '�??\1?/config' varies from run to run, and
`commonlibs` is the name of submodule's directory.
Currently, when Git discovers old-style submodule , it spawns subprocess
to get its status, like this one:
```sh
cd commonlibs; unset GIT_PREFIX; GIT_DIR=.git git status --porcelain=2
```
Unsurprisingly, the following output is also quite unexpected:
```
fatal: unable to access '`??L&?/config': Invalid argument
```
The core reason for these is that global repository field for
commondir is not being cleared to `NULL` after being `free()`'d
in `repo_set_commondir()`, which is precisely what this commit fixes.
Regarding the further details of the case of investigation,
this value of struct pointed by the global `the_repository` pointer is
checked for being not-NULL down in the callstack in compatibility layer
for MinGW in a function that is called by `repo_set_commondir()` before
the `free()`'d value gets assigned in its body (i.e. the body of
`repo_set_commondir()`).
Backtrace from the check is:
```
#0 mingw_open (filename=0x<address-25> ".git/commondir", oflags=0)
at compat/mingw.c:784
git-for-windows#1 0x<address-27> in strbuf_read_file (sb=0x<address-26>,
path=0x<address-25> ".git/commondir", hint=0) at strbuf.c:758
git-for-windows#2 0x<address-24> in get_common_dir_noenv (sb=0x<address-23>,
gitdir=0x<address-22> ".git") at setup.c:313
git-for-windows#3 0x<address-21> in repo_set_commondir (repo=0x<address-19> <the_repo>,
commondir=0x0) at repository.c:57
git-for-windows#4 0x<address-20> in repo_set_gitdir (repo=0x<address-19> <the_repo>,
root=0x<address-15> ".git", o=0x<address-18>) at repository.c:76
git-for-windows#5 0x<address-17> in setup_git_env (git_dir=0x<address-15> ".git")
at environment.c:179
git-for-windows#6 0x<address-16> in set_git_dir_1 (path=0x<address-15> ".git")
at environment.c:334
git-for-windows#7 0x<address-14> in update_relative_gitdir (name=0x0,
old_cwd=0x<address-13> "C:/Users/%username%/<root-repo-name>/commonlibs",
new_cwd=0x<address-11> "C:/Users/%username%/<root-repo-name>/commonlibs", data=0x0) at environment.c:348
git-for-windows#8 0x<address-12> in chdir_notify (
new_cwd=0x<address-11> "C:/Users/%username%/<root-repo-name>/commonlibs") at chdir-notify.c:72
git-for-windows#9 0x<address-10> in setup_work_tree () at setup.c:428
git-for-windows#10 0x<address-9> in run_builtin (p=0x<address-8> <commands+2856>,
argc=2, argv=0x<address-2>) at git.c:458
git-for-windows#11 0x<address-7> in handle_builtin (argc=2, argv=0x<address-2>)
at git.c:721
git-for-windows#12 0x<address-6> in run_argv (argcp=0x<address-5>, argv=0x<address-4>)
at git.c:788
git-for-windows#13 0x<address-3> in cmd_main (argc=2, argv=0x<address-2>) at git.c:921
git-for-windows#14 0x<address-1> in main (argc=6, argv=0x<address-0>)
at common-main.c:56
```
Backtrace from the death is:
```
#0 die_errno (fmt=0x<address-42> <result_type+2002> "unable to access '%s'")
at usage.c:210
git-for-windows#1 0x<address-41> in access_or_die (
path=0x<address-40> "`\001\r��\004/config", mode=4, flag=0)
at wrapper.c:667
git-for-windows#2 0x<address-39> in do_git_config_sequence (opts=0x<address-35>,
fn=0x<address-37> <git_config_include>, data=0x<address-36>)
at config.c:2142
git-for-windows#3 0x<address-38> in config_with_options (
fn=0x<address-37> <git_config_include>, data=0x<address-36>,
config_source=0x0, opts=0x<address-35>) at config.c:2198
git-for-windows#4 0x<address-34> in repo_read_config (repo=0x<address-19> <the_repo>)
at config.c:2524
git-for-windows#5 0x<address-33> in git_config_check_init (
repo=0x<address-19> <the_repo>) at config.c:2543
git-for-windows#6 0x<address-32> in repo_config_get_bool (
repo=0x<address-19> <the_repo>,
key=0x<address-30> <pad+3116> "windows.appendatomically",
dest=0x<address-29> <append_atomically>) at config.c:2612
git-for-windows#7 0x<address-31> in git_config_get_bool (
key=0x<address-30> <pad+3116> "windows.appendatomically",
dest=0x<address-29> <append_atomically>) at config.c:2714
git-for-windows#8 0x<address-28> in mingw_open (
filename=0x<address-25> ".git/commondir", oflags=0) at compat/mingw.c:785
git-for-windows#9 0x<address-27> in strbuf_read_file (sb=0x<address-26>,
path=0x<address-25> ".git/commondir", hint=0) at strbuf.c:758
git-for-windows#10 0x<address-24> in get_common_dir_noenv (sb=0x<address-23>,
gitdir=0x<address-22> ".git") at setup.c:313
git-for-windows#11 0x<address-21> in repo_set_commondir (repo=0x<address-19> <the_repo>,
commondir=0x0) at repository.c:57
git-for-windows#12 0x<address-20> in repo_set_gitdir (repo=0x<address-19> <the_repo>,
root=0x<address-15> ".git", o=0x<address-18>) at repository.c:76
git-for-windows#13 0x<address-17> in setup_git_env (git_dir=0x<address-15> ".git")
at environment.c:179
git-for-windows#14 0x<address-16> in set_git_dir_1 (path=0x<address-15> ".git")
at environment.c:334
git-for-windows#15 0x<address-14> in update_relative_gitdir (name=0x0,
old_cwd=0x<address-13> "C:/Users/%username%/<root-repo-name>/commonlibs",
new_cwd=0x<address-11> "C:/Users/%username%/<root-repo-name>/commonlibs", data=0x0) at environment.c:348
git-for-windows#16 0x<address-12> in chdir_notify (
new_cwd=0x<address-11> "C:/Users/%username%/<root-repo-name>/commonlibs") at chdir-notify.c:72
git-for-windows#17 0x<address-10> in setup_work_tree () at setup.c:428
git-for-windows#18 0x<address-9> in run_builtin (p=0x<address-8> <commands+2856>,
argc=2, argv=0x<address-2>) at git.c:458
git-for-windows#19 0x<address-7> in handle_builtin (argc=2, argv=0x<address-2>)
at git.c:721
git-for-windows#20 0x<address-6> in run_argv (argcp=0x<address-5>, argv=0x<address-4>)
at git.c:788
git-for-windows#21 0x<address-3> in cmd_main (argc=2, argv=0x<address-2>) at git.c:921
git-for-windows#22 0x<address-1> in main (argc=6, argv=0x<address-0>)
at common-main.c:56
```
Signed-off-by: Andrey Zabavnikov <zabavnikov@gmail.com>
sceptical-coder
added a commit
to sceptical-coder/git
that referenced
this issue
Nov 3, 2022
In some setups, old-style submodules (i.e. the ones
with .git directory within theirs worktrees) with commondir
can be of tremendous help. For example, commondir link can be
used to avoid duplication of objects and also to keep branches
in sync with multiple copies of the repo's worktree, while keeping
the .git directory inside the worktree can be (ab?-)used to exploit
the sharing of the same submodule worktree across different projects
(this at least works on Windows with submodule directory being
a directory junction, but having a junction is not relevant for
reproducing the bug described below).
Unfortunately, at the moment, when `git status` is run in the root repo
of such a setup, it gives an output akin to this:
```sh
fatal: unable to access '�??\1?/config': Invalid argument
fatal: 'git status --porcelain=2' failed in submodule commonlibs
```
where `�??\1?` part of '�??\1?/config' varies from run to run, and
`commonlibs` is the name of submodule's directory.
Currently, when Git discovers old-style submodule , it spawns subprocess
to get its status, like this one:
```sh
cd commonlibs; unset GIT_PREFIX; GIT_DIR=.git git status --porcelain=2
```
Unsurprisingly, the following output is also quite unexpected:
```
fatal: unable to access '`??L&?/config': Invalid argument
```
The core reason for these is that global repository field for
commondir is not being cleared to `NULL` after being `free()`'d
in `repo_set_commondir()`, which is precisely what this commit fixes.
Regarding the further details of the case of investigation,
this value of struct pointed by the global `the_repository` pointer is
checked for being not-NULL down in the callstack in compatibility layer
for MinGW in a function that is called by `repo_set_commondir()` before
the `free()`'d value gets assigned in its body (i.e. the body of
`repo_set_commondir()`).
Backtrace from the check is:
```
#0 mingw_open (filename=0x<address-25> ".git/commondir", oflags=0)
at compat/mingw.c:784
git-for-windows#1 0x<address-27> in strbuf_read_file (sb=0x<address-26>,
path=0x<address-25> ".git/commondir", hint=0) at strbuf.c:758
git-for-windows#2 0x<address-24> in get_common_dir_noenv (sb=0x<address-23>,
gitdir=0x<address-22> ".git") at setup.c:313
git-for-windows#3 0x<address-21> in repo_set_commondir (repo=0x<address-19> <the_repo>,
commondir=0x0) at repository.c:57
git-for-windows#4 0x<address-20> in repo_set_gitdir (repo=0x<address-19> <the_repo>,
root=0x<address-15> ".git", o=0x<address-18>) at repository.c:76
git-for-windows#5 0x<address-17> in setup_git_env (git_dir=0x<address-15> ".git")
at environment.c:179
git-for-windows#6 0x<address-16> in set_git_dir_1 (path=0x<address-15> ".git")
at environment.c:334
git-for-windows#7 0x<address-14> in update_relative_gitdir (name=0x0,
old_cwd=0x<address-13> "C:/Users/%username%/<root-repo-name>/commonlibs",
new_cwd=0x<address-11> "C:/Users/%username%/<root-repo-name>/commonlibs", data=0x0) at environment.c:348
git-for-windows#8 0x<address-12> in chdir_notify (
new_cwd=0x<address-11> "C:/Users/%username%/<root-repo-name>/commonlibs") at chdir-notify.c:72
git-for-windows#9 0x<address-10> in setup_work_tree () at setup.c:428
git-for-windows#10 0x<address-9> in run_builtin (p=0x<address-8> <commands+2856>,
argc=2, argv=0x<address-2>) at git.c:458
git-for-windows#11 0x<address-7> in handle_builtin (argc=2, argv=0x<address-2>)
at git.c:721
git-for-windows#12 0x<address-6> in run_argv (argcp=0x<address-5>, argv=0x<address-4>)
at git.c:788
git-for-windows#13 0x<address-3> in cmd_main (argc=2, argv=0x<address-2>) at git.c:921
git-for-windows#14 0x<address-1> in main (argc=6, argv=0x<address-0>)
at common-main.c:56
```
Backtrace from the death is:
```
#0 die_errno (fmt=0x<address-42> <result_type+2002> "unable to access '%s'")
at usage.c:210
git-for-windows#1 0x<address-41> in access_or_die (
path=0x<address-40> "`\001\r��\004/config", mode=4, flag=0)
at wrapper.c:667
git-for-windows#2 0x<address-39> in do_git_config_sequence (opts=0x<address-35>,
fn=0x<address-37> <git_config_include>, data=0x<address-36>)
at config.c:2142
git-for-windows#3 0x<address-38> in config_with_options (
fn=0x<address-37> <git_config_include>, data=0x<address-36>,
config_source=0x0, opts=0x<address-35>) at config.c:2198
git-for-windows#4 0x<address-34> in repo_read_config (repo=0x<address-19> <the_repo>)
at config.c:2524
git-for-windows#5 0x<address-33> in git_config_check_init (
repo=0x<address-19> <the_repo>) at config.c:2543
git-for-windows#6 0x<address-32> in repo_config_get_bool (
repo=0x<address-19> <the_repo>,
key=0x<address-30> <pad+3116> "windows.appendatomically",
dest=0x<address-29> <append_atomically>) at config.c:2612
git-for-windows#7 0x<address-31> in git_config_get_bool (
key=0x<address-30> <pad+3116> "windows.appendatomically",
dest=0x<address-29> <append_atomically>) at config.c:2714
git-for-windows#8 0x<address-28> in mingw_open (
filename=0x<address-25> ".git/commondir", oflags=0) at compat/mingw.c:785
git-for-windows#9 0x<address-27> in strbuf_read_file (sb=0x<address-26>,
path=0x<address-25> ".git/commondir", hint=0) at strbuf.c:758
git-for-windows#10 0x<address-24> in get_common_dir_noenv (sb=0x<address-23>,
gitdir=0x<address-22> ".git") at setup.c:313
git-for-windows#11 0x<address-21> in repo_set_commondir (repo=0x<address-19> <the_repo>,
commondir=0x0) at repository.c:57
git-for-windows#12 0x<address-20> in repo_set_gitdir (repo=0x<address-19> <the_repo>,
root=0x<address-15> ".git", o=0x<address-18>) at repository.c:76
git-for-windows#13 0x<address-17> in setup_git_env (git_dir=0x<address-15> ".git")
at environment.c:179
git-for-windows#14 0x<address-16> in set_git_dir_1 (path=0x<address-15> ".git")
at environment.c:334
git-for-windows#15 0x<address-14> in update_relative_gitdir (name=0x0,
old_cwd=0x<address-13> "C:/Users/%username%/<root-repo-name>/commonlibs",
new_cwd=0x<address-11> "C:/Users/%username%/<root-repo-name>/commonlibs", data=0x0) at environment.c:348
git-for-windows#16 0x<address-12> in chdir_notify (
new_cwd=0x<address-11> "C:/Users/%username%/<root-repo-name>/commonlibs") at chdir-notify.c:72
git-for-windows#17 0x<address-10> in setup_work_tree () at setup.c:428
git-for-windows#18 0x<address-9> in run_builtin (p=0x<address-8> <commands+2856>,
argc=2, argv=0x<address-2>) at git.c:458
git-for-windows#19 0x<address-7> in handle_builtin (argc=2, argv=0x<address-2>)
at git.c:721
git-for-windows#20 0x<address-6> in run_argv (argcp=0x<address-5>, argv=0x<address-4>)
at git.c:788
git-for-windows#21 0x<address-3> in cmd_main (argc=2, argv=0x<address-2>) at git.c:921
git-for-windows#22 0x<address-1> in main (argc=6, argv=0x<address-0>)
at common-main.c:56
```
Signed-off-by: Andrey Zabavnikov <zabavnikov@gmail.com>
sceptical-coder
added a commit
to sceptical-coder/git
that referenced
this issue
Nov 3, 2022
In some setups, old-style submodules (i.e. the ones
with .git directory within theirs worktrees) with commondir
can be of tremendous help. For example, commondir link can be
used to avoid duplication of objects and also to keep branches
in sync with multiple copies of the repo's worktree, while keeping
the .git directory inside the worktree can be (ab?-)used to exploit
the sharing of the same submodule worktree across different projects
(this at least works on Windows with submodule directory being
a directory junction, but having a junction is not relevant for
reproducing the bug described below).
Unfortunately, at the moment, when `git status` is run in the root repo
of such a setup, it gives an output akin to this:
```sh
fatal: unable to access '�??\1?/config': Invalid argument
fatal: 'git status --porcelain=2' failed in submodule commonlibs
```
where `�??\1?` part of '�??\1?/config' varies from run to run, and
`commonlibs` is the name of submodule's directory.
Currently, when Git discovers old-style submodule , it spawns subprocess
to get its status, like this one:
```sh
cd commonlibs; unset GIT_PREFIX; GIT_DIR=.git git status --porcelain=2
```
Unsurprisingly, the following output is also quite unexpected:
```
fatal: unable to access '`??L&?/config': Invalid argument
```
The core reason for these is that global repository field for
commondir is not being cleared to `NULL` after being `free()`'d
in `repo_set_commondir()`, which is precisely what this commit fixes.
Regarding the further details of the case of investigation,
this value of struct pointed by the global `the_repository` pointer is
checked for being not-NULL down in the callstack in compatibility layer
for MinGW in a function that is called by `repo_set_commondir()` before
the `free()`'d value gets assigned in its body (i.e. the body of
`repo_set_commondir()`).
Backtrace from the check is:
```
#0 mingw_open (filename=0x<address-25> ".git/commondir", oflags=0)
at compat/mingw.c:784
git-for-windows#1 0x<address-27> in strbuf_read_file (sb=0x<address-26>,
path=0x<address-25> ".git/commondir", hint=0) at strbuf.c:758
git-for-windows#2 0x<address-24> in get_common_dir_noenv (sb=0x<address-23>,
gitdir=0x<address-22> ".git") at setup.c:313
git-for-windows#3 0x<address-21> in repo_set_commondir (repo=0x<address-19> <the_repo>,
commondir=0x0) at repository.c:57
git-for-windows#4 0x<address-20> in repo_set_gitdir (repo=0x<address-19> <the_repo>,
root=0x<address-15> ".git", o=0x<address-18>) at repository.c:76
git-for-windows#5 0x<address-17> in setup_git_env (git_dir=0x<address-15> ".git")
at environment.c:179
git-for-windows#6 0x<address-16> in set_git_dir_1 (path=0x<address-15> ".git")
at environment.c:334
git-for-windows#7 0x<address-14> in update_relative_gitdir (name=0x0,
old_cwd=0x<address-13> "C:/Users/%username%/<root-repo-name>/commonlibs",
new_cwd=0x<address-11> "C:/Users/%username%/<root-repo-name>/commonlibs", data=0x0) at environment.c:348
git-for-windows#8 0x<address-12> in chdir_notify (
new_cwd=0x<address-11> "C:/Users/%username%/<root-repo-name>/commonlibs") at chdir-notify.c:72
git-for-windows#9 0x<address-10> in setup_work_tree () at setup.c:428
git-for-windows#10 0x<address-9> in run_builtin (p=0x<address-8> <commands+2856>,
argc=2, argv=0x<address-2>) at git.c:458
git-for-windows#11 0x<address-7> in handle_builtin (argc=2, argv=0x<address-2>)
at git.c:721
git-for-windows#12 0x<address-6> in run_argv (argcp=0x<address-5>, argv=0x<address-4>)
at git.c:788
git-for-windows#13 0x<address-3> in cmd_main (argc=2, argv=0x<address-2>) at git.c:921
git-for-windows#14 0x<address-1> in main (argc=6, argv=0x<address-0>)
at common-main.c:56
```
Backtrace from the death is:
```
#0 die_errno (fmt=0x<address-42> <result_type+2002> "unable to access '%s'")
at usage.c:210
git-for-windows#1 0x<address-41> in access_or_die (
path=0x<address-40> "`\001\r��\004/config", mode=4, flag=0)
at wrapper.c:667
git-for-windows#2 0x<address-39> in do_git_config_sequence (opts=0x<address-35>,
fn=0x<address-37> <git_config_include>, data=0x<address-36>)
at config.c:2142
git-for-windows#3 0x<address-38> in config_with_options (
fn=0x<address-37> <git_config_include>, data=0x<address-36>,
config_source=0x0, opts=0x<address-35>) at config.c:2198
git-for-windows#4 0x<address-34> in repo_read_config (repo=0x<address-19> <the_repo>)
at config.c:2524
git-for-windows#5 0x<address-33> in git_config_check_init (
repo=0x<address-19> <the_repo>) at config.c:2543
git-for-windows#6 0x<address-32> in repo_config_get_bool (
repo=0x<address-19> <the_repo>,
key=0x<address-30> <pad+3116> "windows.appendatomically",
dest=0x<address-29> <append_atomically>) at config.c:2612
git-for-windows#7 0x<address-31> in git_config_get_bool (
key=0x<address-30> <pad+3116> "windows.appendatomically",
dest=0x<address-29> <append_atomically>) at config.c:2714
git-for-windows#8 0x<address-28> in mingw_open (
filename=0x<address-25> ".git/commondir", oflags=0) at compat/mingw.c:785
git-for-windows#9 0x<address-27> in strbuf_read_file (sb=0x<address-26>,
path=0x<address-25> ".git/commondir", hint=0) at strbuf.c:758
git-for-windows#10 0x<address-24> in get_common_dir_noenv (sb=0x<address-23>,
gitdir=0x<address-22> ".git") at setup.c:313
git-for-windows#11 0x<address-21> in repo_set_commondir (repo=0x<address-19> <the_repo>,
commondir=0x0) at repository.c:57
git-for-windows#12 0x<address-20> in repo_set_gitdir (repo=0x<address-19> <the_repo>,
root=0x<address-15> ".git", o=0x<address-18>) at repository.c:76
git-for-windows#13 0x<address-17> in setup_git_env (git_dir=0x<address-15> ".git")
at environment.c:179
git-for-windows#14 0x<address-16> in set_git_dir_1 (path=0x<address-15> ".git")
at environment.c:334
git-for-windows#15 0x<address-14> in update_relative_gitdir (name=0x0,
old_cwd=0x<address-13> "C:/Users/%username%/<root-repo-name>/commonlibs",
new_cwd=0x<address-11> "C:/Users/%username%/<root-repo-name>/commonlibs", data=0x0) at environment.c:348
git-for-windows#16 0x<address-12> in chdir_notify (
new_cwd=0x<address-11> "C:/Users/%username%/<root-repo-name>/commonlibs") at chdir-notify.c:72
git-for-windows#17 0x<address-10> in setup_work_tree () at setup.c:428
git-for-windows#18 0x<address-9> in run_builtin (p=0x<address-8> <commands+2856>,
argc=2, argv=0x<address-2>) at git.c:458
git-for-windows#19 0x<address-7> in handle_builtin (argc=2, argv=0x<address-2>)
at git.c:721
git-for-windows#20 0x<address-6> in run_argv (argcp=0x<address-5>, argv=0x<address-4>)
at git.c:788
git-for-windows#21 0x<address-3> in cmd_main (argc=2, argv=0x<address-2>) at git.c:921
git-for-windows#22 0x<address-1> in main (argc=6, argv=0x<address-0>)
at common-main.c:56
```
Signed-off-by: Andrey Zabavnikov <zabavnikov@gmail.com>
sceptical-coder
added a commit
to sceptical-coder/git
that referenced
this issue
Nov 3, 2022
Add config option `windows.appendAtomically`
Atomic append on windows is only supported on local disk files, and it may
cause errors in other situations, e.g. network file system. If that is the
case, this config option should be used to turn atomic append off.
With these edits, status for old-style submodules with commondir
needs to be fixed, due to the following.
In some setups, old-style submodules (i.e. the ones
with .git directory within theirs worktrees) with commondir
can be of tremendous help. For example, commondir link can be
used to avoid duplication of objects and also to keep branches
in sync with multiple copies of the repo's worktree, while keeping
the .git directory inside the worktree can be (ab?-)used to exploit
the sharing of the same submodule worktree across different projects
(this at least works on Windows with submodule directory being
a directory junction, but having a junction is not relevant for
reproducing the bug described below).
Unfortunately, at the moment, when `git status` is run in the root repo
of such a setup, it gives an output akin to this:
```sh
fatal: unable to access '�??\1?/config': Invalid argument
fatal: 'git status --porcelain=2' failed in submodule commonlibs
```
where `�??\1?` part of '�??\1?/config' varies from run to run, and
`commonlibs` is the name of submodule's directory.
Currently, when Git discovers old-style submodule , it spawns subprocess
to get its status, like this one:
```sh
cd commonlibs; unset GIT_PREFIX; GIT_DIR=.git git status --porcelain=2
```
Unsurprisingly, the following output is also quite unexpected:
```
fatal: unable to access '`??L&?/config': Invalid argument
```
The core reason for these is that global repository field for
commondir is not being cleared to `NULL` after being `free()`'d
in `repo_set_commondir()`, which is precisely what this commit fixes.
Regarding the further details of the case of investigation,
this value of struct pointed by the global `the_repository` pointer is
checked for being not-NULL down in the callstack in compatibility layer
for MinGW in a function that is called by `repo_set_commondir()` before
the `free()`'d value gets assigned in its body (i.e. the body of
`repo_set_commondir()`).
Backtrace from the check is:
```
#0 mingw_open (filename=0x<address-25> ".git/commondir", oflags=0)
at compat/mingw.c:784
git-for-windows#1 0x<address-27> in strbuf_read_file (sb=0x<address-26>,
path=0x<address-25> ".git/commondir", hint=0) at strbuf.c:758
git-for-windows#2 0x<address-24> in get_common_dir_noenv (sb=0x<address-23>,
gitdir=0x<address-22> ".git") at setup.c:313
git-for-windows#3 0x<address-21> in repo_set_commondir (repo=0x<address-19> <the_repo>,
commondir=0x0) at repository.c:57
git-for-windows#4 0x<address-20> in repo_set_gitdir (repo=0x<address-19> <the_repo>,
root=0x<address-15> ".git", o=0x<address-18>) at repository.c:76
git-for-windows#5 0x<address-17> in setup_git_env (git_dir=0x<address-15> ".git")
at environment.c:179
git-for-windows#6 0x<address-16> in set_git_dir_1 (path=0x<address-15> ".git")
at environment.c:334
git-for-windows#7 0x<address-14> in update_relative_gitdir (name=0x0,
old_cwd=0x<address-13> "C:/Users/%username%/<root-repo-name>/commonlibs",
new_cwd=0x<address-11> "C:/Users/%username%/<root-repo-name>/commonlibs", data=0x0) at environment.c:348
git-for-windows#8 0x<address-12> in chdir_notify (
new_cwd=0x<address-11> "C:/Users/%username%/<root-repo-name>/commonlibs") at chdir-notify.c:72
git-for-windows#9 0x<address-10> in setup_work_tree () at setup.c:428
git-for-windows#10 0x<address-9> in run_builtin (p=0x<address-8> <commands+2856>,
argc=2, argv=0x<address-2>) at git.c:458
git-for-windows#11 0x<address-7> in handle_builtin (argc=2, argv=0x<address-2>)
at git.c:721
git-for-windows#12 0x<address-6> in run_argv (argcp=0x<address-5>, argv=0x<address-4>)
at git.c:788
git-for-windows#13 0x<address-3> in cmd_main (argc=2, argv=0x<address-2>) at git.c:921
git-for-windows#14 0x<address-1> in main (argc=6, argv=0x<address-0>)
at common-main.c:56
```
Backtrace from the death is:
```
#0 die_errno (fmt=0x<address-42> <result_type+2002> "unable to access '%s'")
at usage.c:210
git-for-windows#1 0x<address-41> in access_or_die (
path=0x<address-40> "`\001\r��\004/config", mode=4, flag=0)
at wrapper.c:667
git-for-windows#2 0x<address-39> in do_git_config_sequence (opts=0x<address-35>,
fn=0x<address-37> <git_config_include>, data=0x<address-36>)
at config.c:2142
git-for-windows#3 0x<address-38> in config_with_options (
fn=0x<address-37> <git_config_include>, data=0x<address-36>,
config_source=0x0, opts=0x<address-35>) at config.c:2198
git-for-windows#4 0x<address-34> in repo_read_config (repo=0x<address-19> <the_repo>)
at config.c:2524
git-for-windows#5 0x<address-33> in git_config_check_init (
repo=0x<address-19> <the_repo>) at config.c:2543
git-for-windows#6 0x<address-32> in repo_config_get_bool (
repo=0x<address-19> <the_repo>,
key=0x<address-30> <pad+3116> "windows.appendatomically",
dest=0x<address-29> <append_atomically>) at config.c:2612
git-for-windows#7 0x<address-31> in git_config_get_bool (
key=0x<address-30> <pad+3116> "windows.appendatomically",
dest=0x<address-29> <append_atomically>) at config.c:2714
git-for-windows#8 0x<address-28> in mingw_open (
filename=0x<address-25> ".git/commondir", oflags=0) at compat/mingw.c:785
git-for-windows#9 0x<address-27> in strbuf_read_file (sb=0x<address-26>,
path=0x<address-25> ".git/commondir", hint=0) at strbuf.c:758
git-for-windows#10 0x<address-24> in get_common_dir_noenv (sb=0x<address-23>,
gitdir=0x<address-22> ".git") at setup.c:313
git-for-windows#11 0x<address-21> in repo_set_commondir (repo=0x<address-19> <the_repo>,
commondir=0x0) at repository.c:57
git-for-windows#12 0x<address-20> in repo_set_gitdir (repo=0x<address-19> <the_repo>,
root=0x<address-15> ".git", o=0x<address-18>) at repository.c:76
git-for-windows#13 0x<address-17> in setup_git_env (git_dir=0x<address-15> ".git")
at environment.c:179
git-for-windows#14 0x<address-16> in set_git_dir_1 (path=0x<address-15> ".git")
at environment.c:334
git-for-windows#15 0x<address-14> in update_relative_gitdir (name=0x0,
old_cwd=0x<address-13> "C:/Users/%username%/<root-repo-name>/commonlibs",
new_cwd=0x<address-11> "C:/Users/%username%/<root-repo-name>/commonlibs", data=0x0) at environment.c:348
git-for-windows#16 0x<address-12> in chdir_notify (
new_cwd=0x<address-11> "C:/Users/%username%/<root-repo-name>/commonlibs") at chdir-notify.c:72
git-for-windows#17 0x<address-10> in setup_work_tree () at setup.c:428
git-for-windows#18 0x<address-9> in run_builtin (p=0x<address-8> <commands+2856>,
argc=2, argv=0x<address-2>) at git.c:458
git-for-windows#19 0x<address-7> in handle_builtin (argc=2, argv=0x<address-2>)
at git.c:721
git-for-windows#20 0x<address-6> in run_argv (argcp=0x<address-5>, argv=0x<address-4>)
at git.c:788
git-for-windows#21 0x<address-3> in cmd_main (argc=2, argv=0x<address-2>) at git.c:921
git-for-windows#22 0x<address-1> in main (argc=6, argv=0x<address-0>)
at common-main.c:56
```
Co-Authored-By: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: 孙卓识 <sunzhuoshi@gmail.com>
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Andrey Zabavnikov <zabavnikov@gmail.com>
sceptical-coder
added a commit
to sceptical-coder/git
that referenced
this issue
Nov 3, 2022
Add config option `windows.appendAtomically`
Atomic append on windows is only supported on local disk files, and it may
cause errors in other situations, e.g. network file system. If that is the
case, this config option should be used to turn atomic append off.
With these edits, the status command for old-style submodules with commondir
needs to be fixed, due to the following.
In some setups, old-style submodules (i.e. the ones
with .git directory within theirs worktrees) with commondir
can be of tremendous help. For example, commondir link can be
used to avoid duplication of objects and also to keep branches
in sync with multiple copies of the repo's worktree, while keeping
the .git directory inside the worktree can be (ab?-)used to exploit
the sharing of the same submodule worktree across different projects
(this at least works on Windows with submodule directory being
a directory junction, but having a junction is not relevant for
reproducing the bug described below).
Unfortunately, after the addition of the new config option, when
`git status` is run in the root repo of such a setup, it gives an output
akin to this:
```sh
$ git status
fatal: unable to access '�??\1?/config': Invalid argument
fatal: 'git status --porcelain=2' failed in submodule commonlibs
```
where `�??\1?` part of '�??\1?/config' varies from run to run, and
`commonlibs` is the name of submodule's directory.
Currently, when Git discovers old-style submodule , it spawns subprocess
to get its status, like this one:
```sh
cd commonlibs; unset GIT_PREFIX; GIT_DIR=.git git status --porcelain=2
```
Unsurprisingly, the following output is also quite unexpected:
```
$ GIT_DIR=.git git -C commonlibs/ status --porcelain=2
fatal: unable to access '`??L&?/config': Invalid argument
```
The core reason for these is that global repository field for
commondir is not being cleared to `NULL` after being `free()`'d
in `repo_set_commondir()`, which is precisely what this commit fixes.
Regarding the further details of the case of investigation,
this value of struct pointed by the global `the_repository` pointer is
checked for being not-NULL down in the callstack in compatibility layer
for MinGW in a function that is called by `repo_set_commondir()` before
the `free()`'d value gets assigned in its body (i.e. the body of
`repo_set_commondir()`).
Backtrace from the check is:
```
#0 mingw_open (filename=0x<address-25> ".git/commondir", oflags=0)
at compat/mingw.c:784
git-for-windows#1 0x<address-27> in strbuf_read_file (sb=0x<address-26>,
path=0x<address-25> ".git/commondir", hint=0) at strbuf.c:758
git-for-windows#2 0x<address-24> in get_common_dir_noenv (sb=0x<address-23>,
gitdir=0x<address-22> ".git") at setup.c:313
git-for-windows#3 0x<address-21> in repo_set_commondir (repo=0x<address-19> <the_repo>,
commondir=0x0) at repository.c:57
git-for-windows#4 0x<address-20> in repo_set_gitdir (repo=0x<address-19> <the_repo>,
root=0x<address-15> ".git", o=0x<address-18>) at repository.c:76
git-for-windows#5 0x<address-17> in setup_git_env (git_dir=0x<address-15> ".git")
at environment.c:179
git-for-windows#6 0x<address-16> in set_git_dir_1 (path=0x<address-15> ".git")
at environment.c:334
git-for-windows#7 0x<address-14> in update_relative_gitdir (name=0x0,
old_cwd=0x<address-13> "C:/Users/%username%/<root-repo-name>/commonlibs",
new_cwd=0x<address-11> "C:/Users/%username%/<root-repo-name>/commonlibs", data=0x0) at environment.c:348
git-for-windows#8 0x<address-12> in chdir_notify (
new_cwd=0x<address-11> "C:/Users/%username%/<root-repo-name>/commonlibs") at chdir-notify.c:72
git-for-windows#9 0x<address-10> in setup_work_tree () at setup.c:428
git-for-windows#10 0x<address-9> in run_builtin (p=0x<address-8> <commands+2856>,
argc=2, argv=0x<address-2>) at git.c:458
git-for-windows#11 0x<address-7> in handle_builtin (argc=2, argv=0x<address-2>)
at git.c:721
git-for-windows#12 0x<address-6> in run_argv (argcp=0x<address-5>, argv=0x<address-4>)
at git.c:788
git-for-windows#13 0x<address-3> in cmd_main (argc=2, argv=0x<address-2>) at git.c:921
git-for-windows#14 0x<address-1> in main (argc=6, argv=0x<address-0>)
at common-main.c:56
```
Backtrace from the death is:
```
#0 die_errno (fmt=0x<address-42> <result_type+2002> "unable to access '%s'")
at usage.c:210
git-for-windows#1 0x<address-41> in access_or_die (
path=0x<address-40> "`\001\r��\004/config", mode=4, flag=0)
at wrapper.c:667
git-for-windows#2 0x<address-39> in do_git_config_sequence (opts=0x<address-35>,
fn=0x<address-37> <git_config_include>, data=0x<address-36>)
at config.c:2142
git-for-windows#3 0x<address-38> in config_with_options (
fn=0x<address-37> <git_config_include>, data=0x<address-36>,
config_source=0x0, opts=0x<address-35>) at config.c:2198
git-for-windows#4 0x<address-34> in repo_read_config (repo=0x<address-19> <the_repo>)
at config.c:2524
git-for-windows#5 0x<address-33> in git_config_check_init (
repo=0x<address-19> <the_repo>) at config.c:2543
git-for-windows#6 0x<address-32> in repo_config_get_bool (
repo=0x<address-19> <the_repo>,
key=0x<address-30> <pad+3116> "windows.appendatomically",
dest=0x<address-29> <append_atomically>) at config.c:2612
git-for-windows#7 0x<address-31> in git_config_get_bool (
key=0x<address-30> <pad+3116> "windows.appendatomically",
dest=0x<address-29> <append_atomically>) at config.c:2714
git-for-windows#8 0x<address-28> in mingw_open (
filename=0x<address-25> ".git/commondir", oflags=0) at compat/mingw.c:785
git-for-windows#9 0x<address-27> in strbuf_read_file (sb=0x<address-26>,
path=0x<address-25> ".git/commondir", hint=0) at strbuf.c:758
git-for-windows#10 0x<address-24> in get_common_dir_noenv (sb=0x<address-23>,
gitdir=0x<address-22> ".git") at setup.c:313
git-for-windows#11 0x<address-21> in repo_set_commondir (repo=0x<address-19> <the_repo>,
commondir=0x0) at repository.c:57
git-for-windows#12 0x<address-20> in repo_set_gitdir (repo=0x<address-19> <the_repo>,
root=0x<address-15> ".git", o=0x<address-18>) at repository.c:76
git-for-windows#13 0x<address-17> in setup_git_env (git_dir=0x<address-15> ".git")
at environment.c:179
git-for-windows#14 0x<address-16> in set_git_dir_1 (path=0x<address-15> ".git")
at environment.c:334
git-for-windows#15 0x<address-14> in update_relative_gitdir (name=0x0,
old_cwd=0x<address-13> "C:/Users/%username%/<root-repo-name>/commonlibs",
new_cwd=0x<address-11> "C:/Users/%username%/<root-repo-name>/commonlibs", data=0x0) at environment.c:348
git-for-windows#16 0x<address-12> in chdir_notify (
new_cwd=0x<address-11> "C:/Users/%username%/<root-repo-name>/commonlibs") at chdir-notify.c:72
git-for-windows#17 0x<address-10> in setup_work_tree () at setup.c:428
git-for-windows#18 0x<address-9> in run_builtin (p=0x<address-8> <commands+2856>,
argc=2, argv=0x<address-2>) at git.c:458
git-for-windows#19 0x<address-7> in handle_builtin (argc=2, argv=0x<address-2>)
at git.c:721
git-for-windows#20 0x<address-6> in run_argv (argcp=0x<address-5>, argv=0x<address-4>)
at git.c:788
git-for-windows#21 0x<address-3> in cmd_main (argc=2, argv=0x<address-2>) at git.c:921
git-for-windows#22 0x<address-1> in main (argc=6, argv=0x<address-0>)
at common-main.c:56
```
Co-Authored-By: Johannes Schindelin <johannes.schindelin@gmx.de>
Co-Authored-By: Andrey Zabavnikov <zabavnikov@gmail.com>
Signed-off-by: 孙卓识 <sunzhuoshi@gmail.com>
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Andrey Zabavnikov <zabavnikov@gmail.com>
dscho
pushed a commit
to sceptical-coder/git
that referenced
this issue
Nov 4, 2022
In some setups, old-style submodules (i.e. the ones with .git directory within theirs worktrees) with commondir can be of tremendous help. For example, commondir link can be used to avoid duplication of objects and also to keep branches in sync with multiple copies of the repo's worktree, while keeping the .git directory inside the worktree can be (ab?-)used to exploit the sharing of the same submodule worktree across different projects (this at least works on Windows with submodule directory being a directory junction, but having a junction is not relevant for reproducing the bug described below). Unfortunately, at the moment, when `git status` is run in the root repo of such a setup, it gives an output akin to this: ```sh fatal: unable to access '�??\1?/config': Invalid argument fatal: 'git status --porcelain=2' failed in submodule commonlibs ``` where `�??\1?` part of '�??\1?/config' varies from run to run, and `commonlibs` is the name of submodule's directory. Currently, when Git discovers old-style submodule , it spawns subprocess to get its status, like this one: ```sh cd commonlibs; unset GIT_PREFIX; GIT_DIR=.git git status --porcelain=2 ``` Unsurprisingly, the following output is also quite unexpected: ``` fatal: unable to access '`??L&?/config': Invalid argument ``` The core reason for these is that global repository field for commondir is not being cleared to `NULL` after being `free()`'d in `repo_set_commondir()`, which is precisely what this commit fixes. Regarding the further details of the case of investigation, this value of struct pointed by the global `the_repository` pointer is checked for being not-NULL down in the callstack in compatibility layer for MinGW in a function that is called by `repo_set_commondir()` before the `free()`'d value gets assigned in its body (i.e. the body of `repo_set_commondir()`). Backtrace from the check is: #0 mingw_open (filename=0x<address-25> ".git/commondir", oflags=0) at compat/mingw.c:784 git-for-windows#1 0x<address-27> in strbuf_read_file (sb=0x<address-26>, path=0x<address-25> ".git/commondir", hint=0) at strbuf.c:758 git-for-windows#2 0x<address-24> in get_common_dir_noenv (sb=0x<address-23>, gitdir=0x<address-22> ".git") at setup.c:313 git-for-windows#3 0x<address-21> in repo_set_commondir (repo=0x<address-19> <the_repo>, commondir=0x0) at repository.c:57 git-for-windows#4 0x<address-20> in repo_set_gitdir (repo=0x<address-19> <the_repo>, root=0x<address-15> ".git", o=0x<address-18>) at repository.c:76 git-for-windows#5 0x<address-17> in setup_git_env (git_dir=0x<address-15> ".git") at environment.c:179 git-for-windows#6 0x<address-16> in set_git_dir_1 (path=0x<address-15> ".git") at environment.c:334 git-for-windows#7 0x<address-14> in update_relative_gitdir (name=0x0, old_cwd=0x<address-13> "C:/Users/%username%/<root-repo-name>/commonlibs", new_cwd=0x<address-11> "C:/Users/%username%/<root-repo-name>/commonlibs", data=0x0) at environment.c:348 git-for-windows#8 0x<address-12> in chdir_notify ( new_cwd=0x<address-11> "C:/Users/%username%/<root-repo-name>/commonlibs") at chdir-notify.c:72 git-for-windows#9 0x<address-10> in setup_work_tree () at setup.c:428 git-for-windows#10 0x<address-9> in run_builtin (p=0x<address-8> <commands+2856>, argc=2, argv=0x<address-2>) at git.c:458 git-for-windows#11 0x<address-7> in handle_builtin (argc=2, argv=0x<address-2>) at git.c:721 git-for-windows#12 0x<address-6> in run_argv (argcp=0x<address-5>, argv=0x<address-4>) at git.c:788 git-for-windows#13 0x<address-3> in cmd_main (argc=2, argv=0x<address-2>) at git.c:921 git-for-windows#14 0x<address-1> in main (argc=6, argv=0x<address-0>) at common-main.c:56 Backtrace from the death is: #0 die_errno (fmt=0x<address-42> <result_type+2002> "unable to access '%s'") at usage.c:210 git-for-windows#1 0x<address-41> in access_or_die ( path=0x<address-40> "`\001\r��\004/config", mode=4, flag=0) at wrapper.c:667 git-for-windows#2 0x<address-39> in do_git_config_sequence (opts=0x<address-35>, fn=0x<address-37> <git_config_include>, data=0x<address-36>) at config.c:2142 git-for-windows#3 0x<address-38> in config_with_options ( fn=0x<address-37> <git_config_include>, data=0x<address-36>, config_source=0x0, opts=0x<address-35>) at config.c:2198 git-for-windows#4 0x<address-34> in repo_read_config (repo=0x<address-19> <the_repo>) at config.c:2524 git-for-windows#5 0x<address-33> in git_config_check_init ( repo=0x<address-19> <the_repo>) at config.c:2543 git-for-windows#6 0x<address-32> in repo_config_get_bool ( repo=0x<address-19> <the_repo>, key=0x<address-30> <pad+3116> "windows.appendatomically", dest=0x<address-29> <append_atomically>) at config.c:2612 git-for-windows#7 0x<address-31> in git_config_get_bool ( key=0x<address-30> <pad+3116> "windows.appendatomically", dest=0x<address-29> <append_atomically>) at config.c:2714 git-for-windows#8 0x<address-28> in mingw_open ( filename=0x<address-25> ".git/commondir", oflags=0) at compat/mingw.c:785 git-for-windows#9 0x<address-27> in strbuf_read_file (sb=0x<address-26>, path=0x<address-25> ".git/commondir", hint=0) at strbuf.c:758 git-for-windows#10 0x<address-24> in get_common_dir_noenv (sb=0x<address-23>, gitdir=0x<address-22> ".git") at setup.c:313 git-for-windows#11 0x<address-21> in repo_set_commondir (repo=0x<address-19> <the_repo>, commondir=0x0) at repository.c:57 git-for-windows#12 0x<address-20> in repo_set_gitdir (repo=0x<address-19> <the_repo>, root=0x<address-15> ".git", o=0x<address-18>) at repository.c:76 git-for-windows#13 0x<address-17> in setup_git_env (git_dir=0x<address-15> ".git") at environment.c:179 git-for-windows#14 0x<address-16> in set_git_dir_1 (path=0x<address-15> ".git") at environment.c:334 git-for-windows#15 0x<address-14> in update_relative_gitdir (name=0x0, old_cwd=0x<address-13> "C:/Users/%username%/<root-repo-name>/commonlibs", new_cwd=0x<address-11> "C:/Users/%username%/<root-repo-name>/commonlibs", data=0x0) at environment.c:348 git-for-windows#16 0x<address-12> in chdir_notify ( new_cwd=0x<address-11> "C:/Users/%username%/<root-repo-name>/commonlibs") at chdir-notify.c:72 git-for-windows#17 0x<address-10> in setup_work_tree () at setup.c:428 git-for-windows#18 0x<address-9> in run_builtin (p=0x<address-8> <commands+2856>, argc=2, argv=0x<address-2>) at git.c:458 git-for-windows#19 0x<address-7> in handle_builtin (argc=2, argv=0x<address-2>) at git.c:721 git-for-windows#20 0x<address-6> in run_argv (argcp=0x<address-5>, argv=0x<address-4>) at git.c:788 git-for-windows#21 0x<address-3> in cmd_main (argc=2, argv=0x<address-2>) at git.c:921 git-for-windows#22 0x<address-1> in main (argc=6, argv=0x<address-0>) at common-main.c:56 Signed-off-by: Andrey Zabavnikov <zabavnikov@gmail.com>
derrickstolee
pushed a commit
that referenced
this issue
Jan 17, 2023
It is possible to trigger an integer overflow when parsing attribute
names when there are more than 2^31 of them for a single pattern. This
can either lead to us dying due to trying to request too many bytes:
blob=$(perl -e 'print "f" . " a=" x 2147483649' | git hash-object -w --stdin)
git update-index --add --cacheinfo 100644,$blob,.gitattributes
git attr-check --all file
=================================================================
==1022==ERROR: AddressSanitizer: requested allocation size 0xfffffff800000032 (0xfffffff800001038 after adjustments for alignment, red zones etc.) exceeds maximum supported size of 0x10000000000 (thread T0)
#0 0x7fd3efabf411 in __interceptor_calloc /usr/src/debug/gcc/libsanitizer/asan/asan_malloc_linux.cpp:77
#1 0x5563a0a1e3d3 in xcalloc wrapper.c:150
#2 0x5563a058d005 in parse_attr_line attr.c:384
#3 0x5563a058e661 in handle_attr_line attr.c:660
#4 0x5563a058eddb in read_attr_from_index attr.c:769
#5 0x5563a058ef12 in read_attr attr.c:797
#6 0x5563a058f24c in bootstrap_attr_stack attr.c:867
#7 0x5563a058f4a3 in prepare_attr_stack attr.c:902
#8 0x5563a05905da in collect_some_attrs attr.c:1097
#9 0x5563a059093d in git_all_attrs attr.c:1128
#10 0x5563a02f636e in check_attr builtin/check-attr.c:67
#11 0x5563a02f6c12 in cmd_check_attr builtin/check-attr.c:183
#12 0x5563a02aa993 in run_builtin git.c:466
#13 0x5563a02ab397 in handle_builtin git.c:721
#14 0x5563a02abb2b in run_argv git.c:788
#15 0x5563a02ac991 in cmd_main git.c:926
#16 0x5563a05432bd in main common-main.c:57
#17 0x7fd3ef82228f (/usr/lib/libc.so.6+0x2328f)
==1022==HINT: if you don't care about these errors you may set allocator_may_return_null=1
SUMMARY: AddressSanitizer: allocation-size-too-big /usr/src/debug/gcc/libsanitizer/asan/asan_malloc_linux.cpp:77 in __interceptor_calloc
==1022==ABORTING
Or, much worse, it can lead to an out-of-bounds write because we
underallocate and then memcpy(3P) into an array:
perl -e '
print "A " . "\rh="x2000000000;
print "\rh="x2000000000;
print "\rh="x294967294 . "\n"
' >.gitattributes
git add .gitattributes
git commit -am "evil attributes"
$ git clone --quiet /path/to/repo
=================================================================
==15062==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x602000002550 at pc 0x5555559884d5 bp 0x7fffffffbc60 sp 0x7fffffffbc58
WRITE of size 8 at 0x602000002550 thread T0
#0 0x5555559884d4 in parse_attr_line attr.c:393
#1 0x5555559884d4 in handle_attr_line attr.c:660
#2 0x555555988902 in read_attr_from_index attr.c:784
#3 0x555555988902 in read_attr_from_index attr.c:747
#4 0x555555988a1d in read_attr attr.c:800
#5 0x555555989b0c in bootstrap_attr_stack attr.c:882
#6 0x555555989b0c in prepare_attr_stack attr.c:917
#7 0x555555989b0c in collect_some_attrs attr.c:1112
#8 0x55555598b141 in git_check_attr attr.c:1126
#9 0x555555a13004 in convert_attrs convert.c:1311
#10 0x555555a95e04 in checkout_entry_ca entry.c:553
#11 0x555555d58bf6 in checkout_entry entry.h:42
#12 0x555555d58bf6 in check_updates unpack-trees.c:480
#13 0x555555d5eb55 in unpack_trees unpack-trees.c:2040
#14 0x555555785ab7 in checkout builtin/clone.c:724
#15 0x555555785ab7 in cmd_clone builtin/clone.c:1384
#16 0x55555572443c in run_builtin git.c:466
#17 0x55555572443c in handle_builtin git.c:721
#18 0x555555727872 in run_argv git.c:788
#19 0x555555727872 in cmd_main git.c:926
#20 0x555555721fa0 in main common-main.c:57
#21 0x7ffff73f1d09 in __libc_start_main ../csu/libc-start.c:308
#22 0x555555723f39 in _start (git+0x1cff39)
0x602000002552 is located 0 bytes to the right of 2-byte region [0x602000002550,0x602000002552) allocated by thread T0 here:
#0 0x7ffff768c037 in __interceptor_calloc ../../../../src/libsanitizer/asan/asan_malloc_linux.cpp:154
#1 0x555555d7fff7 in xcalloc wrapper.c:150
#2 0x55555598815f in parse_attr_line attr.c:384
#3 0x55555598815f in handle_attr_line attr.c:660
#4 0x555555988902 in read_attr_from_index attr.c:784
#5 0x555555988902 in read_attr_from_index attr.c:747
#6 0x555555988a1d in read_attr attr.c:800
#7 0x555555989b0c in bootstrap_attr_stack attr.c:882
#8 0x555555989b0c in prepare_attr_stack attr.c:917
#9 0x555555989b0c in collect_some_attrs attr.c:1112
#10 0x55555598b141 in git_check_attr attr.c:1126
#11 0x555555a13004 in convert_attrs convert.c:1311
#12 0x555555a95e04 in checkout_entry_ca entry.c:553
#13 0x555555d58bf6 in checkout_entry entry.h:42
#14 0x555555d58bf6 in check_updates unpack-trees.c:480
#15 0x555555d5eb55 in unpack_trees unpack-trees.c:2040
#16 0x555555785ab7 in checkout builtin/clone.c:724
#17 0x555555785ab7 in cmd_clone builtin/clone.c:1384
#18 0x55555572443c in run_builtin git.c:466
#19 0x55555572443c in handle_builtin git.c:721
#20 0x555555727872 in run_argv git.c:788
#21 0x555555727872 in cmd_main git.c:926
#22 0x555555721fa0 in main common-main.c:57
#23 0x7ffff73f1d09 in __libc_start_main ../csu/libc-start.c:308
SUMMARY: AddressSanitizer: heap-buffer-overflow attr.c:393 in parse_attr_line
Shadow bytes around the buggy address:
0x0c047fff8450: fa fa 00 02 fa fa 00 07 fa fa fd fd fa fa 00 00
0x0c047fff8460: fa fa 02 fa fa fa fd fd fa fa 00 06 fa fa 05 fa
0x0c047fff8470: fa fa fd fd fa fa 00 02 fa fa 06 fa fa fa 05 fa
0x0c047fff8480: fa fa 07 fa fa fa fd fd fa fa 00 01 fa fa 00 02
0x0c047fff8490: fa fa 00 03 fa fa 00 fa fa fa 00 01 fa fa 00 03
=>0x0c047fff84a0: fa fa 00 01 fa fa 00 02 fa fa[02]fa fa fa fa fa
0x0c047fff84b0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
0x0c047fff84c0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
0x0c047fff84d0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
0x0c047fff84e0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
0x0c047fff84f0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
Shadow byte legend (one shadow byte represents 8 application bytes):
Addressable: 00
Partially addressable: 01 02 03 04 05 06 07
Heap left redzone: fa
Freed heap region: fd
Stack left redzone: f1
Stack mid redzone: f2
Stack right redzone: f3
Stack after return: f5
Stack use after scope: f8
Global redzone: f9
Global init order: f6
Poisoned by user: f7
Container overflow: fc
Array cookie: ac
Intra object redzone: bb
ASan internal: fe
Left alloca redzone: ca
Right alloca redzone: cb
Shadow gap: cc
==15062==ABORTING
Fix this bug by using `size_t` instead to count the number of attributes
so that this value cannot reasonably overflow without running out of
memory before already.
Reported-by: Markus Vervier <markus.vervier@x41-dsec.de>
Signed-off-by: Patrick Steinhardt <ps@pks.im>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
git-for-windows-ci
pushed a commit
that referenced
this issue
Aug 19, 2024
It was recently reported that concurrent reads and writes may cause the
reftable backend to segfault. The root cause of this is that we do not
properly keep track of reftable readers across reloads.
Suppose that you have a reftable iterator and then decide to reload the
stack while iterating through the iterator. When the stack has been
rewritten since we have created the iterator, then we would end up
discarding a subset of readers that may still be in use by the iterator.
The consequence is that we now try to reference deallocated memory,
which of course segfaults.
One way to trigger this is in t5616, where some background maintenance
jobs have been leaking from one test into another. This leads to stack
traces like the following one:
+ git -c protocol.version=0 -C pc1 fetch --filter=blob:limit=29999 --refetch origin
AddressSanitizer:DEADLYSIGNAL
=================================================================
==657994==ERROR: AddressSanitizer: SEGV on unknown address 0x7fa0f0ec6089 (pc 0x55f23e52ddf9 bp
0x7ffe7bfa1700 sp 0x7ffe7bfa1700 T0)
==657994==The signal is caused by a READ memory access.
#0 0x55f23e52ddf9 in get_var_int reftable/record.c:29
#1 0x55f23e53295e in reftable_decode_keylen reftable/record.c:170
#2 0x55f23e532cc0 in reftable_decode_key reftable/record.c:194
#3 0x55f23e54e72e in block_iter_next reftable/block.c:398
#4 0x55f23e5573dc in table_iter_next_in_block reftable/reader.c:240
#5 0x55f23e5573dc in table_iter_next reftable/reader.c:355
#6 0x55f23e5573dc in table_iter_next reftable/reader.c:339
#7 0x55f23e551283 in merged_iter_advance_subiter reftable/merged.c:69
#8 0x55f23e55169e in merged_iter_next_entry reftable/merged.c:123
#9 0x55f23e55169e in merged_iter_next_void reftable/merged.c:172
#10 0x55f23e537625 in reftable_iterator_next_ref reftable/generic.c:175
#11 0x55f23e2cf9c6 in reftable_ref_iterator_advance refs/reftable-backend.c:464
#12 0x55f23e2d996e in ref_iterator_advance refs/iterator.c:13
#13 0x55f23e2d996e in do_for_each_ref_iterator refs/iterator.c:452
#14 0x55f23dca6767 in get_ref_map builtin/fetch.c:623
#15 0x55f23dca6767 in do_fetch builtin/fetch.c:1659
#16 0x55f23dca6767 in fetch_one builtin/fetch.c:2133
#17 0x55f23dca6767 in cmd_fetch builtin/fetch.c:2432
#18 0x55f23dba7764 in run_builtin git.c:484
#19 0x55f23dba7764 in handle_builtin git.c:741
#20 0x55f23dbab61e in run_argv git.c:805
#21 0x55f23dbab61e in cmd_main git.c:1000
#22 0x55f23dba4781 in main common-main.c:64
#23 0x7fa0f063fc89 in __libc_start_call_main ../sysdeps/nptl/libc_start_call_main.h:58
#24 0x7fa0f063fd44 in __libc_start_main_impl ../csu/libc-start.c:360
#25 0x55f23dba6ad0 in _start (git+0xadfad0) (BuildId: 803b2b7f59beb03d7849fb8294a8e2145dd4aa27)
While it is somewhat awkward that the maintenance processes survive
tests in the first place, it is totally expected that reftables should
work alright with concurrent writers. Seemingly they don't.
The only underlying resource that we need to care about in this context
is the reftable reader, which is responsible for reading a single table
from disk. These readers get discarded immediately (unless reused) when
calling `reftable_stack_reload()`, which is wrong. We can only close
them once we know that there are no iterators using them anymore.
Prepare for a fix by converting the reftable readers to be refcounted.
Reported-by: Jeff King <peff@peff.net>
Signed-off-by: Patrick Steinhardt <ps@pks.im>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
git-for-windows-ci
pushed a commit
that referenced
this issue
Aug 22, 2024
It was recently reported that concurrent reads and writes may cause the
reftable backend to segfault. The root cause of this is that we do not
properly keep track of reftable readers across reloads.
Suppose that you have a reftable iterator and then decide to reload the
stack while iterating through the iterator. When the stack has been
rewritten since we have created the iterator, then we would end up
discarding a subset of readers that may still be in use by the iterator.
The consequence is that we now try to reference deallocated memory,
which of course segfaults.
One way to trigger this is in t5616, where some background maintenance
jobs have been leaking from one test into another. This leads to stack
traces like the following one:
+ git -c protocol.version=0 -C pc1 fetch --filter=blob:limit=29999 --refetch origin
AddressSanitizer:DEADLYSIGNAL
=================================================================
==657994==ERROR: AddressSanitizer: SEGV on unknown address 0x7fa0f0ec6089 (pc 0x55f23e52ddf9 bp
0x7ffe7bfa1700 sp 0x7ffe7bfa1700 T0)
==657994==The signal is caused by a READ memory access.
#0 0x55f23e52ddf9 in get_var_int reftable/record.c:29
#1 0x55f23e53295e in reftable_decode_keylen reftable/record.c:170
#2 0x55f23e532cc0 in reftable_decode_key reftable/record.c:194
#3 0x55f23e54e72e in block_iter_next reftable/block.c:398
#4 0x55f23e5573dc in table_iter_next_in_block reftable/reader.c:240
#5 0x55f23e5573dc in table_iter_next reftable/reader.c:355
#6 0x55f23e5573dc in table_iter_next reftable/reader.c:339
#7 0x55f23e551283 in merged_iter_advance_subiter reftable/merged.c:69
#8 0x55f23e55169e in merged_iter_next_entry reftable/merged.c:123
#9 0x55f23e55169e in merged_iter_next_void reftable/merged.c:172
#10 0x55f23e537625 in reftable_iterator_next_ref reftable/generic.c:175
#11 0x55f23e2cf9c6 in reftable_ref_iterator_advance refs/reftable-backend.c:464
#12 0x55f23e2d996e in ref_iterator_advance refs/iterator.c:13
#13 0x55f23e2d996e in do_for_each_ref_iterator refs/iterator.c:452
#14 0x55f23dca6767 in get_ref_map builtin/fetch.c:623
#15 0x55f23dca6767 in do_fetch builtin/fetch.c:1659
#16 0x55f23dca6767 in fetch_one builtin/fetch.c:2133
#17 0x55f23dca6767 in cmd_fetch builtin/fetch.c:2432
#18 0x55f23dba7764 in run_builtin git.c:484
#19 0x55f23dba7764 in handle_builtin git.c:741
#20 0x55f23dbab61e in run_argv git.c:805
#21 0x55f23dbab61e in cmd_main git.c:1000
#22 0x55f23dba4781 in main common-main.c:64
#23 0x7fa0f063fc89 in __libc_start_call_main ../sysdeps/nptl/libc_start_call_main.h:58
#24 0x7fa0f063fd44 in __libc_start_main_impl ../csu/libc-start.c:360
#25 0x55f23dba6ad0 in _start (git+0xadfad0) (BuildId: 803b2b7f59beb03d7849fb8294a8e2145dd4aa27)
While it is somewhat awkward that the maintenance processes survive
tests in the first place, it is totally expected that reftables should
work alright with concurrent writers. Seemingly they don't.
The only underlying resource that we need to care about in this context
is the reftable reader, which is responsible for reading a single table
from disk. These readers get discarded immediately (unless reused) when
calling `reftable_stack_reload()`, which is wrong. We can only close
them once we know that there are no iterators using them anymore.
Prepare for a fix by converting the reftable readers to be refcounted.
Reported-by: Jeff King <peff@peff.net>
Signed-off-by: Patrick Steinhardt <ps@pks.im>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
git-for-windows-ci
pushed a commit
that referenced
this issue
Aug 23, 2024
It was recently reported that concurrent reads and writes may cause the
reftable backend to segfault. The root cause of this is that we do not
properly keep track of reftable readers across reloads.
Suppose that you have a reftable iterator and then decide to reload the
stack while iterating through the iterator. When the stack has been
rewritten since we have created the iterator, then we would end up
discarding a subset of readers that may still be in use by the iterator.
The consequence is that we now try to reference deallocated memory,
which of course segfaults.
One way to trigger this is in t5616, where some background maintenance
jobs have been leaking from one test into another. This leads to stack
traces like the following one:
+ git -c protocol.version=0 -C pc1 fetch --filter=blob:limit=29999 --refetch origin
AddressSanitizer:DEADLYSIGNAL
=================================================================
==657994==ERROR: AddressSanitizer: SEGV on unknown address 0x7fa0f0ec6089 (pc 0x55f23e52ddf9 bp
0x7ffe7bfa1700 sp 0x7ffe7bfa1700 T0)
==657994==The signal is caused by a READ memory access.
#0 0x55f23e52ddf9 in get_var_int reftable/record.c:29
#1 0x55f23e53295e in reftable_decode_keylen reftable/record.c:170
#2 0x55f23e532cc0 in reftable_decode_key reftable/record.c:194
#3 0x55f23e54e72e in block_iter_next reftable/block.c:398
#4 0x55f23e5573dc in table_iter_next_in_block reftable/reader.c:240
#5 0x55f23e5573dc in table_iter_next reftable/reader.c:355
#6 0x55f23e5573dc in table_iter_next reftable/reader.c:339
#7 0x55f23e551283 in merged_iter_advance_subiter reftable/merged.c:69
#8 0x55f23e55169e in merged_iter_next_entry reftable/merged.c:123
#9 0x55f23e55169e in merged_iter_next_void reftable/merged.c:172
#10 0x55f23e537625 in reftable_iterator_next_ref reftable/generic.c:175
#11 0x55f23e2cf9c6 in reftable_ref_iterator_advance refs/reftable-backend.c:464
#12 0x55f23e2d996e in ref_iterator_advance refs/iterator.c:13
#13 0x55f23e2d996e in do_for_each_ref_iterator refs/iterator.c:452
#14 0x55f23dca6767 in get_ref_map builtin/fetch.c:623
#15 0x55f23dca6767 in do_fetch builtin/fetch.c:1659
#16 0x55f23dca6767 in fetch_one builtin/fetch.c:2133
#17 0x55f23dca6767 in cmd_fetch builtin/fetch.c:2432
#18 0x55f23dba7764 in run_builtin git.c:484
#19 0x55f23dba7764 in handle_builtin git.c:741
#20 0x55f23dbab61e in run_argv git.c:805
#21 0x55f23dbab61e in cmd_main git.c:1000
#22 0x55f23dba4781 in main common-main.c:64
#23 0x7fa0f063fc89 in __libc_start_call_main ../sysdeps/nptl/libc_start_call_main.h:58
#24 0x7fa0f063fd44 in __libc_start_main_impl ../csu/libc-start.c:360
#25 0x55f23dba6ad0 in _start (git+0xadfad0) (BuildId: 803b2b7f59beb03d7849fb8294a8e2145dd4aa27)
While it is somewhat awkward that the maintenance processes survive
tests in the first place, it is totally expected that reftables should
work alright with concurrent writers. Seemingly they don't.
The only underlying resource that we need to care about in this context
is the reftable reader, which is responsible for reading a single table
from disk. These readers get discarded immediately (unless reused) when
calling `reftable_stack_reload()`, which is wrong. We can only close
them once we know that there are no iterators using them anymore.
Prepare for a fix by converting the reftable readers to be refcounted.
Reported-by: Jeff King <peff@peff.net>
Signed-off-by: Patrick Steinhardt <ps@pks.im>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
I was just trying to figure out which components I wanted to install out of the dizzying array available, and after making some changes I wanted to start over because I wasn't sure exactly what I might have changed. Unfortunately, there was no "reset to default" button available, and the window did not want to close. I ended up having to kill the process tree to start over.
The text was updated successfully, but these errors were encountered: