* Segmentation fault within git read-tree
@ 2023-01-14 22:14 Frédéric Fort
2023-01-15 11:53 ` Christian Couder
0 siblings, 1 reply; 4+ messages in thread
From: Frédéric Fort @ 2023-01-14 22:14 UTC (permalink / raw)
To: git
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.
Here should be a MWE to reproduce my error:
# 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"
git sparse-checkout set "subtree/x"
git remote add origin-subtree git@my.server:/with/the/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
Yours sincerely,
Frédéric Fort
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: Segmentation fault within git read-tree
2023-01-14 22:14 Segmentation fault within git read-tree Frédéric Fort
@ 2023-01-15 11:53 ` Christian Couder
2023-01-15 18:35 ` Jeff King
0 siblings, 1 reply; 4+ messages in thread
From: Christian Couder @ 2023-01-15 11:53 UTC (permalink / raw)
To: Frédéric Fort; +Cc: git
Hi,
On Sat, Jan 14, 2023 at 11:22 PM Frédéric Fort <fortfrederic@free.fr> wrote:
>
> 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.
> # 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.
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: Segmentation fault within git read-tree
2023-01-15 11:53 ` Christian Couder
@ 2023-01-15 18:35 ` Jeff King
2023-01-15 21:49 ` Junio C Hamano
0 siblings, 1 reply; 4+ messages in thread
From: Jeff King @ 2023-01-15 18:35 UTC (permalink / raw)
To: Christian Couder; +Cc: Junio C Hamano, Frédéric Fort, git
On Sun, Jan 15, 2023 at 12:53:25PM +0100, Christian Couder wrote:
> 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.
I'm not sure if Frédéric is seeing another segfault in practice (when
not using --debug-unpack), but yeah, it is very easy to trigger this
segfault. It does not even have to do with sparse checkouts, etc. Here's
an even more minimal example:
git init repo
cd repo
touch file
git add file
git commit -m added
git read-tree --debug-unpack --prefix=subtree HEAD
I was going to bisect, but it looks like it was broken all the way back
to Junio's ba655da537 (read-tree --debug-unpack, 2009-09-14).
-Peff
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: Segmentation fault within git read-tree
2023-01-15 18:35 ` Jeff King
@ 2023-01-15 21:49 ` Junio C Hamano
0 siblings, 0 replies; 4+ messages in thread
From: Junio C Hamano @ 2023-01-15 21:49 UTC (permalink / raw)
To: Jeff King; +Cc: Christian Couder, Frédéric Fort, git
Jeff King <peff@peff.net> writes:
> I'm not sure if Frédéric is seeing another segfault in practice (when
> not using --debug-unpack), but yeah, it is very easy to trigger this
> segfault. It does not even have to do with sparse checkouts, etc. Here's
> an even more minimal example:
>
> git init repo
> cd repo
> touch file
> git add file
> git commit -m added
> git read-tree --debug-unpack --prefix=subtree HEAD
>
> I was going to bisect, but it looks like it was broken all the way back
> to Junio's ba655da537 (read-tree --debug-unpack, 2009-09-14).
As "git read-tree --help" does not even metnion "--debug-unpack", I
have no idea what it does, or how useful the debug information it
produces is. As long as the same command without --debug-unpack
works OK, I'd throw this into "does it hurt? don't do it, then" bin.
;-)
^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2023-01-15 21:49 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2023-01-14 22:14 Segmentation fault within git read-tree Frédéric Fort
2023-01-15 11:53 ` Christian Couder
2023-01-15 18:35 ` Jeff King
2023-01-15 21:49 ` Junio C Hamano
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).