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
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
