Re: Segmentation fault within git read-tree

From: Christian Couder <christian.couder@gmail.com>
Date: Jan 15, 2023, 11:53 UTC
Message-ID: <CAP8UFD0pKZT57jpUOg7gckcr4stoq24YDB2Fu0-AwbGPrEweqg@mail.gmail.com>
In-Reply-To: <d0f9520d-9ccc-a899-609e-fbbb4529e005@free.fr>

Hi,

On Sat, Jan 14, 2023 at 11:22 PM Frédéric Fort <fortfrederic@free.fr> wrote:

Show 10 quoted lines

>
> Hello,
>
> I am doing some tests trying to do a sparse checkout of a partial clone
> within a subtree.
> However, I get a segfault when trying to run git read-tree as is done by
> git subtree internally.
>
> Maybe what I am doing isn't supposed to work at all, but I suppose it
> shouldn't at least cause git read-tree to segfault.

Yeah, it shouldn't segfault. Thanks for the report!

> Here should be a MWE to reproduce my error:

I reproduced the issue using your steps with a few changes.

Show 12 quoted lines

> # Run this to create the repo that will become your subtree
> git init subtree.git
> cd subtree.git
> touch x y
> git add .
> git commit -m "first commit"
>
> # Run this to create the repo that has a sparse checkout of a partial
> clone within a subtree
> git init repo
> cd repo
> git commit --allow-empty "first commit"

I think the above command is missing '-m' before "first commit".

> git sparse-checkout set "subtree/x"
> git remote add origin-subtree git@my.server:/with/the/subtree.git

I reproduced using a local remote like:

git remote add origin-subtree /path/to/subtree.git

> git fetch --filter=blob:none origin-subtree
> git rev-parse --verify "FETCH_HEAD^{commit}"
> git read-tree --debug-unpack --prefix="subtree" FETCH_HEAD

Yeah, I get the following under gdb:

Program received signal SIGSEGV, Segmentation fault. debug_path (info=0x7fffffffc880) at unpack-trees.c:1395 1395 if (*info->prev->name) (gdb) bt #0 debug_path (info=0x7fffffffc880) at unpack-trees.c:1395 #1 0x000055555587d917 in debug_unpack_callback (n=1, mask=1, dirmask=0, names=0x7fffffffc3b0, info=0x7fffffffc880) at unpack-trees.c:1417 #2 0x000055555587dc48 in unpack_callback (n=1, mask=1, dirmask=0, names=0x7fffffffc3b0, info=0x7fffffffc880) at unpack-trees.c:1491 #3 0x00005555558779c2 in traverse_trees (istate=0x5555559f3b00 <the_index>, n=1, t=0x7fffffffcb50, info=0x7fffffffc880) at tree-walk.c:536 #4 0x000055555587ef85 in unpack_trees (len=1, t=0x7fffffffcb50, o=0x7fffffffcd90) at unpack-trees.c:1979 #5 0x000055555562ab45 in cmd_read_tree (argc=1, argv=0x7fffffffdc90, cmd_prefix=0x0) at builtin/read-tree.c:263 #6 0x0000555555575a4d in run_builtin (p=0x5555559bf8f0 <commands+2256>, argc=4, argv=0x7fffffffdc90) at git.c:445 #7 0x0000555555575ed2 in handle_builtin (argc=4, argv=0x7fffffffdc90) at git.c:700 #8 0x0000555555576179 in run_argv (argcp=0x7fffffffdaec, argv=0x7fffffffdae0) at git.c:764 #9 0x0000555555576764 in cmd_main (argc=4, argv=0x7fffffffdc90) at git.c:899 #10 0x0000555555682dfe in main (argc=5, argv=0x7fffffffdc88) at common-main.c:57

From a very quick look, it seems that in setup_traverse_info() in tree-walk.c we do:

    static struct traverse_info dummy;
...
    if (pathlen)
        info->prev = &dummy;

but then later in debug_path() in unpack-trees.c we check *info->prev->name which segfaults.

I am not very familiar with this code and don't have much time right now, so I think I will leave it to others to investigate this further.

Best, Christian.