Jeff King <peff@xxxxxxxx> writes:
> So if anything, I think my inclination would be to make it easier to
> help people (and ourselves) get a backtrace from gdb.
>
> One can get a core for a running process with gcore, or trigger a
> coredump by killing with SIGABRT. But catching it at the exact moment of
> a die() is a bit hard without support from the program. What about
> something like this:
>
> diff --git a/usage.c b/usage.c
> index ed14645..fa92190 100644
> --- a/usage.c
> +++ b/usage.c
> @@ -34,6 +34,8 @@ static NORETURN void usage_builtin(const char *err, va_list params)
> static NORETURN void die_builtin(const char *err, va_list params)
> {
> vreportf("fatal: ", err, params);
> + if (git_env_bool("GIT_DIE_ABORT", 0))
> + abort();
> exit(128);
> }
Two comments.
There probably are more than a few places that calls exit(128)
without using die(), upon seeing that some helper function returned
an error code, because the helper already gave an error message.
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?
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html