On Fri, Jul 01, 2016 at 03:51:33PM +0200, Johannes Schindelin wrote:
> > > 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.
It doesn't in Linux either. But you can use the core file to get a
backtrace. Do you not get cores at all in Windows? Yuck. :)
> 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.
That's a new one to me. Gross. :)
Usually I can coax git into running "gdbserver ... git foo" instead of
git foo" via config. But sometimes the values are hard-coded (for
instance, the way we call pack-objects, which I recently made a bit more
flexible).
> > 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.
It is a standard, it's just C99, which we've been rather slow to
embrace.
However we have prior art in the trace code. If your system supports
variadic macros, then we define the macros to pass the file/line info.
Otherwise, we skip the macros, and those names point directly to
functions.
So it would not be too hard to implement. I've never bothered, though,
because in my experience the interesting thing is almost never "on what
line was error() called", but rather "what line called the function that
called error()". I.e., the stack trace.
I looked a while ago at trying to auto-generate stack traces in git
using something like GNU's backtrace (obviously not portable, but it's a
start). My conclusion was that the simplest thing is to just generate a
core and run "gdb -ex bt" on it.
-Peff
--
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