Skip site navigation (1)Skip section navigation (2)
Date:      Sat, 9 Feb 2013 01:38:20 -0800
From:      Mehmet Erol Sanliturk <m.e.sanliturk@gmail.com>
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:  <CAOgwaMutXeb8EcCAAG7dKh%2Bci_o0Wy8xyYFbaYkigcduC=wjuA@mail.gmail.com>
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, Feb 9, 2013 at 1:08 AM, Andriy Gapon <avg@freebsd.org> 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.
>
> > 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.
>
> --
> Andriy Gapon
>


During 1980 years we were using a Burroughs 6700 main frame . Its Fortran
compiler produced code was generating a call stack trace on run time errors
. That facility was very useful during finding possible causes . That main
frame was using ONLY TWO MEGA BYTES of main memory .

Now I am using such a facility with G95 Fortran compiler by setting a
compiler switch : It is giving a call stack listing with line numbers of
calls when a run time error occurs with line number of error point .

A similar structure may be used for FreeBSD parts generated during
compilation when a compiler switch is set . Making such a setting as
default may be more useful because it is unknown when a run time error
occurs . By submitting such call stack lists to developers will make their
problem solution tasks much more easier than the currently required much
more conversations to identify the cause and call steps .

Therefore , this is mainly a compilation problem which can be achieved with
current structure of sources .

Thank you very much .

Mehmet Erol Sanliturk



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAOgwaMutXeb8EcCAAG7dKh%2Bci_o0Wy8xyYFbaYkigcduC=wjuA>