git@vger.kernel.org mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: Brendan Boerner <bboerner.biz@gmail.com>
To: Jeff King <peff@peff.net>
Cc: Johannes Schindelin <Johannes.Schindelin@gmx.de>, git@vger.kernel.org
Subject: Re: 'git stash list' => Segmentation fault
Date: Tue, 28 May 2019 15:53:51 -0500	[thread overview]
Message-ID: <CAKkfZL3ZNgNFzxrYbjbhCF5BR12vQPy2sNuYdxmQgmuG+mo9Gw@mail.gmail.com> (raw)
In-Reply-To: <20190528204051.GA24650@sigill.intra.peff.net>

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@peff.net> 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

  reply	other threads:[~2019-05-28 20:54 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-05-24 17:27 'git stash list' => Segmentation fault Brendan Boerner
2019-05-27 18:47 ` Johannes Schindelin
2019-05-28  6:34   ` Jeff King
2019-05-28 19:56     ` Brendan Boerner
2019-05-28 20:40       ` Jeff King
2019-05-28 20:53         ` Brendan Boerner [this message]
2019-05-28 20:56           ` Jeff King
2019-05-28 21:29             ` Brendan Boerner
2019-05-28 21:39               ` Jeff King
2019-05-29 20:10                 ` Brendan Boerner

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: http://vger.kernel.org/majordomo-info.html

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CAKkfZL3ZNgNFzxrYbjbhCF5BR12vQPy2sNuYdxmQgmuG+mo9Gw@mail.gmail.com \
    --to=bboerner.biz@gmail.com \
    --cc=Johannes.Schindelin@gmx.de \
    --cc=git@vger.kernel.org \
    --cc=peff@peff.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://80x24.org/mirrors/git.git

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 read-only IMAP folder(s) and NNTP newsgroup(s).