From: Jeff King <peff@peff.net>
To: Junio C Hamano <gitster@pobox.com>
Cc: Jonathan Nieder <jrnieder@gmail.com>,
Stefan Beller <sbeller@google.com>,
Michael Haggerty <mhagger@alum.mit.edu>,
"git@vger.kernel.org" <git@vger.kernel.org>
Subject: Re: [PATCHv3] refs.c: enable large transactions
Date: Sat, 25 Apr 2015 01:00:58 -0400 [thread overview]
Message-ID: <20150425050058.GA20256@peff.net> (raw)
In-Reply-To: <xmqqzj5w25vv.fsf@gitster.dls.corp.google.com>
On Fri, Apr 24, 2015 at 09:23:16PM -0700, Junio C Hamano wrote:
> The proposals so far, including this one, assume that the bug
> reporter will first fail the operation with "normal" invocation
> of Git (e.g. without GIT_DIE_ABORT exported) and then retry the
> same operation in a different way (e.g. with GIT_DIE_ABORT) to
> give us something that would help diagnosis. Such a user could
> just rerun Git under gdb with breakpoint set to die_builtin, no?
Good point. I was trying to automate the gathering of the backtrace so
that even bug-reporters who have not used gdb could easily get us more
information. But of course if a coredump only gets us halfway there and
we have to script gdb to convert the core into a backtrace anyway, it is
not buying us much over just scripting gdb in the first place.
A better solution to what I proposed earlier is perhaps:
git config alias.debug '!gdb --quiet \
-ex "break exit" \
-ex "run" \
-ex "bt full" \
-ex "continue" \
-ex "quit" \
--args git \
'
git debug rev-parse foobar
It has the minor irritation that gdb will control the process stdio
(slurping from stdin and polluting stdout, whereas we would prefer no
input and output to stderr). There might be a way to convince gdb to do
otherwise, or you could probably go pretty far with some shell fd
redirects and using "set args" inside gdb. Or maybe something with
gdbserver.
But the point is that yeah, we shouldn't try to build really good
introspection inside git. Debuggers already do a way better job of this.
If they're hard for people to use to obtain simple information like a
backtrace, we should work on wrapping that difficulty up in a script.
It might still be useful to provide a much lesser form of introspection,
if it would be available in a lot more places than gdb would. E.g.,
__FILE__ and __LINE__ markers on error messages might be useful. A
mediocre backtrace() that is only available on glibc systems is probably
not.
-Peff
next prev parent reply other threads:[~2015-04-25 5:01 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-04-22 21:30 [PATCHv3] refs.c: enable large transactions Stefan Beller
2015-04-23 17:56 ` Junio C Hamano
2015-04-24 0:21 ` Stefan Beller
2015-04-24 1:37 ` Junio C Hamano
2015-04-24 16:16 ` Stefan Beller
2015-04-24 17:19 ` Jeff King
2015-04-24 18:12 ` Jonathan Nieder
2015-04-24 18:31 ` Stefan Beller
2015-04-24 20:17 ` Jeff King
2015-04-25 4:23 ` Junio C Hamano
2015-04-25 5:00 ` Jeff King [this message]
2015-04-25 5:24 ` Jeff King
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
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20150425050058.GA20256@peff.net \
--to=peff@peff.net \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
--cc=jrnieder@gmail.com \
--cc=mhagger@alum.mit.edu \
--cc=sbeller@google.com \
/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.
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).