Web lists-archives.com

Re: 'git stash list' => Segmentation fault

Hey Jeff,

Lot of good tips for debugging for me to work on - I'll work on that.

Both to avoid spamming the list and if sending large files e.g. strace
is it ok if I continue correspondence with you directly? (And


On Tue, May 28, 2019 at 3:40 PM Jeff King <peff@xxxxxxxx> wrote:
> On Tue, May 28, 2019 at 02:56:13PM -0500, Brendan Boerner wrote:
> > Unfortunately not a lot in the stack trace.
> > [...]
> > (gdb) bt
> > #0  0x00007fd321805fdf in ?? ()
> > #1  0x0000000000000000 in ?? ()
> I'll say. :)
> I'd suspect either:
>   1. Your git isn't built with debugging symbols. Is it possible to
>      build from source? The default CFLAGS if you just run "make" should
>      be enough, then you can run it straight out of the build directory
>      as "$YOUR_BUILD_DIR/bin-wrappers/git".
>   2. It's not the main git binary that's segfaulting. Most commands are
>      built-ins of that binary these days, but a few are not. We should
>      be able to figure out which command is having a problem from the
>      trace output, but...
> > 14:52:22.633448 run-command.c:643       trace: run_command: git-stash list
> > Segmentation fault (core dumped)
> > Segmentation fault (core dumped)
> > Segmentation fault (core dumped)
> I'd have expected to see more sub-commands here. And it's weird that
> there are _three_ segfaults. Which version of Git is this? In the
> upcoming release stash is written in C, but from the trace output it
> looks like this is the old shell-script version (which is what I was
> assuming, but I just want to double check).
> Is it possible that your shell is segfaulting? Does "gdb /bin/sh core"
> reveal anything more useful (a long shot, I know; it probably doesn't
> have symbols either)?
> > Do you need the whole repo or would bits of it suffice e.g. index?
> Probably the whole thing. "stash list" wouldn't generally look at
> the index at all. It should just be doing a "git log" on the reflog
> entries found in .git/logs/refs/stash. But...
> > 14:52:25.040053 git.c:419               trace: built-in: git log
> > '--format=%gd: %gs' -g --first-parent -m refs/stash --
> > 14:52:26.436274 run-command.c:643       trace: run_command: unset
> > stash@{0}: On devel: NYFL optimization
> > stash@{1}: On GL285: gl285
> We can see that the "log" command actually works! The segfaults seem not
> to derail the command from actually performing its task. So what
> processes are actually segfaulting?
> Maybe "strace -o trace.out -f git stash list" would be instructive. You
> should be able to find the segfaulting process in that trace, and then
> can grep for that PID to see what it was doing (especially what command
> was exec'd, and possibly what it was doing right before the segfault).
> I can also help picking through the strace output if you're comfortable
> sending it off-list (it's likely to be much too large to send on-list
> anyway).
> -Peff