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

Re: Debug output etc, cluttering the terminal

On Sun, 15 Aug 2010 08:08:57 -0700
Wouter Verhelst <wouter@debian.org> wrote:

> On Sun, Aug 15, 2010 at 10:05:17AM +0100, Neil Williams wrote:
> > Users may but developers will be looking for that debug output and
> > starting the program from the command line explicitly to be able to
> > collect it. (Filing a bug will usually result in the user being
> > asked to start the program from the command line too.)
> Sure. And there is no reason why such a request could not include
> something along the lines of 'please run the application with the -d
> option so that it produces debug output'.

Unreproducible bugs will, by their nature, not be fixable if that is
applied rigorously or as a change in Policy, which some were
suggesting here. 

> Neil, nobody is disclaiming that debug output can be useful for a
> developer. But an application that has nothing useful to say should
> not say anything. The default for _any_ application should be to _not_
> produce any output until there is a problem. 

The amount of debug output has to be controlled, yes - it should only
relate to areas where bugs are likely to be hard to reproduce without
such output - and there are applications (I'm looking at you
epiphany-browser and you, iceweasel) which seem to pay little attention
to the notices produced by g_return_if_fail statements which result
from errors in their own code. I won't defend that because if a library
or function call fails an assertion, then whatever you're doing to call
that function is *wrong*, so fix the code. ;-)

(Even if only to do whatever error checking the function does before
actually calling the function. The process of identifying WHY an
assertion fails is itself bug fixing. Passing NULLs to functions which
cannot accept NULLs without failing an assertion is a BAD habit. Stop
it, check your pointers BEFORE making the call.)

Most of this is upstream stuff - that's why I care about Debian not
mandating that all this stuff should disappear, it isn't about just us,
it's about helping upstream fix bugs.

Most of the stuff in ~/.xsession-errors which has been mentioned here,
are exactly these kind of assertion failure errors:

(gnome-power-manager:2346): GLib-GObject-WARNING **: value "-nan" of
type `gdouble' is invalid or out of range for property `percentage' of
type `gdouble'

(polkit-gnome-authentication-agent-1:2468): GLib-CRITICAL **:
g_once_init_leave: assertion `initialization_value != 0' failed

Those are BUGS. It might not cause symptoms now but it is still
relevant to how other bugs in that application are triaged. The
upstream code needs to be fixed to check these values before passing
them to the relevant function.

I spend a lot of time tracking down just these kind of assertion
failures in my own upstream code. It is an irksome task at times but
that is no excuse for not fixing these things. Indeed, it is a prime
motivation for working out exactly where more of such assertion tests
need to be implemented.

Debug output needs to be retained but it also needs to be managed and
not ignored.

> This debugging output does cause problems: it slows down the
> application (doing 'cout' or 'printf' when they are not needed *does*
> take up some amount of CPU time, which becomes significant when the
> amount of output gets rather large),

... when abused, yes. There are ways to avoid this problem (e.g. when
debugging thread-locking issues which are always time-sensitive) IF
the debug calls themselves are carefully managed.

> it generates
> huge .xsession-errors files that can cause problems for people with
> low quotas or for people who actually need the *useful* information
> in those files, and (in the case of KDE applications) it pollutes
> random unrelated terminals with output long after the application
> that was started on that terminal has exited, just because KDE
> applications like to start background daemons.
> There is no good reason why doing debugging output should be the
> *default*.

Not a default across all packages and all debug output but there are
situations where *some* debug output needs to be part of the default
output of the application in order to actually capture the data
necessary to fix the bugs.

Some applications, even some mature applications, need to be able to
output debug information to the controlling terminal as a matter of
course in order to fix unreproducible and/or intermittent bugs.

Debian should not prevent this behaviour but encourage upstreams to
*moderate* their use of default debug output by getting them to fix
their own code where it causes assertion failures in other code and by
prompting upstream to consider downgrading certain debug output to
the non-default output level.

Manage the debug output and everyone wins because the output itself
becomes easier to understand. Remove the debug output completely and
everybody loses, especially users.

It is not clutter but it does need to be managed to contain only useful
and relevant debug data. It is simply not helpful to mandate that
all of this stuff has to be hidden behind an environment variable or
configuration switch or command line option. There are valid reasons
why applications must be allowed to output debug information to the
controlling terminal as part of their default operations. Manage it,
don't abolish it.


Neil Williams

Attachment: pgpw8acnTQmkc.pgp
Description: PGP signature

Reply to: