Re: [PATCH 1/9] Report bugs consistently

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi Peff,

On Thu, 30 Jun 2016, Jeff King wrote:

> 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.

> 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
--
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



[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]