Date: Sat, 09 Feb 2013 10:15:33 -0700 From: Ian Lepore <ian@FreeBSD.org> To: Andriy Gapon <avg@FreeBSD.org> Cc: Kirk McKusick <mckusick@mckusick.com>, Christoph Mallon <christoph.mallon@gmx.de>, freebsd-arch@FreeBSD.org Subject: Re: Proposal: Unify printing the function name in panic messages() Message-ID: <1360430133.4545.68.camel@revolution.hippie.lan> In-Reply-To: <5116121E.1010601@FreeBSD.org> References: <51141E33.4080103@gmx.de> <511426B8.2070800@FreeBSD.org> <51160E06.1070404@gmx.de> <5116121E.1010601@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sat, 2013-02-09 at 11:08 +0200, Andriy Gapon wrote:
> on 09/02/2013 10:51 Christoph Mallon said the following:
> > On 07.02.2013 23:12, Andriy Gapon wrote:
> >> on 07/02/2013 23:35 Christoph Mallon said the following:
> >>> panic("just a message");
> >>
> >> This seems perfect.
> >> Panic without at least a stack trace or preferably a crash dump is practically
> >> useless in most cases. A stack trace already has all the function names.
> >> So a function name in a message seems to be redundant.
> >
> > This is nice in theory, but infeasible in practice.
> > More than half of the panic() calls include the correct function name in a way or another.
> > I estimate, that another quarter show a wrong name.
>
> In any case, you just search the code for the message and that's it.
> I don't suppose that there are many duplicates there.
>
Exactly. The use of sufficiently descriptive messages is all that's
necessary for finding the source of a panic or other error. It has
taken me over 30 years to come around to this way of thinking, but
during the past 5 years of working in a shop with a large source base
and no file/line numbers in the logging, I've seen the light.
What I've found to be the far bigger modern problem is not finding the
source of a given message in the code, but rather finding out WHO said
it, given the growing ubiquity of multi-threaded code.
-- Ian
> > It is hard to get this number mechanically, because, well, the names are wrong.
> > So most calls include the name (or try to).
> > Having no function name is a minority.
> > I plan to correct and unify this hotchpotch.
> > Also, if stack traces are disabled, you at least can reliably determine, where the panic came from.
>
> Even if you can determine that, without more debugging data that would be
> useless in most cases. (We paniced because something went wrong, but why did it
> happen?)
>
> > Finally, you can turn the names on and off with one central switch.
>
> Well, have you experienced any problems with debugging due to those
> (absent/misleading) function names? Or do you see many reports about such problems?
>
> If this is a solution in search of a problem, then I don't like it, because it
> requires massive, if mostly mechanical, changes throughout the code.
>
> If panic message like ("invalid value of bar") were to be changed to something
> like ("invalid value of bar (%foo)", bar) I would find that to be a far more
> useful project.
>
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1360430133.4545.68.camel>