Re: [PATCHv3] refs.c: enable large transactions

[Jeff King <peff@peff.net>]

On Fri, Apr 24, 2015 at 11:12:36AM -0700, Jonathan Nieder wrote:

> Actually, I wouldn't mind an environment variable that tells error()
> to include a backtrace if someone wants it.  (See backtrace(3)
> for implementation hints if interested in doing that.)

Thanks, I didn't know about backtrace(3), and figured we'd be stuck with
an ELF library or similar to get at the symbols.

That being said, the resulting backtrace is not nearly as nice as what
is produced by gdb (which includes pretty-printed variables, or even
local variables with "bt full"). Not everybody will have gdb, of course,
but nor will everybody have backtrace().

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);
 }
 

Usage would be something like:

  ulimit -c unlimited ;# optional, but many distros seem to ship with
                      ;# cores disabled these days
  GIT_DIE_ABORT=1 git some-command-that-fails
  gdb --quiet -ex 'bt full' -ex quit git core

We could even wrap that up in a git-debug script. I suspect there may be
some complications with finding the core file, though, as the git
process may chdir before dumping. I'm not sure if there's a good way
around that (obviously setting /proc/sys/kernel/core_pattern is not
exactly friendly).

I dunno. Certainly there is room for a less-full-featured system that
would run more seamlessly, or on more people's systems (i.e., so that we
can easily say "set GIT_FOO and tell us what it outputs" in response to
bug reports). Maybe that system is backtrace(), or maybe it is just
__FILE__ and __LINE__ markers for each printed error.

-Peff