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
Johannes?)
Thanks!
Brendan
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
> > GIT_PAGER_IN_USE; LESS=FRX LV=-c less
> > 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
