Re: [PATCH 1/9] Report bugs consistently
- From
Johannes Schindelin <johannes.schindelin@gmx.de>
- Date
- Jul 1, 2016, 13:51 UTC
- Message-ID
- <alpine.DEB.2.20.1607011548560.12947@virtualbox>
- In-Reply-To
- <20160630092333.GB24964@sigill.intra.peff.net>
Hi Peff,
On Thu, 30 Jun 2016, Jeff King wrote:
Show 20 quoted lines
> On Thu, Jun 30, 2016 at 10:42:37AM +0200, Johannes Schindelin wrote:
>
> > > > The vast majority of error messages in Git's source code which report a
> > > > bug use the convention to prefix the message with "BUG:".
> > >
> > > Good thing to do.
> > >
> > > But if we were to review and apply a 200+ line patch, I wonder if we
> > > want to go one step further to allow us to write
> > >
> > > BUG("killed-file %s not found", name);
> > >
> > > instead.
> >
> > If the idea is to make it easier to find, I would wager a guess that
> > 'die("BUG:' would be just as good a search term. Even better, I think,
> > because 'BUG' would also match comments.
>
> I have been tempted to switch to BUG(), because it would make it easy to
> call abort() and get a coredump (and therefore a stack trace).Please keep in mind that abort() does not produce stackdumps with MinGW. So at least Windows developers would not be better off.
Show 16 quoted lines
> On the other hand:
>
> - we could always trigger such behavior in die() by looking for "BUG:" in
> the output string. :)
>
> - it's also sometimes useful to get a stack trace from a regular
> non-bug die(). So maybe something optional like:
>
> if (git_env_bool("GIT_ABORT_ON_DIE", 0))
> abort();
>
> would be helpful (since you have to turn it on ahead of time, you
> could also just run the program under gdb, of course; however, I
> sometimes find that it's hard to get gdb where you want it because
> git spawns so many sub-programs. Or maybe I just need to get better
> at using gdb's child-following options).Heh. I still find myself using that good old trick where I set a variable, loop while it is set and print out the pid, waiting for a debugger to attach and re-set that variable.
> The other thing BUG() would get us is that we could turn it into a macro > (on systems with vararg macros) and report things like __FILE__ and > __LINE__. In practice, though our BUG messages are unique enough that > there is no problem finding the source.
That would be very nice *also* for error() messages. But I guess we cannot have it, vararg macros being a feature rather than a standard.
Ciao, Dscho