Proposal: Unify printing the function name in panic messages()

[Mehmet Erol Sanliturk]

On Sat, Feb 9, 2013 at 1:08 AM, Andriy Gapon <avg at 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