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 ============= http://www.data-freedom.org/ http://www.linux.codehelp.co.uk/ http://e-mail.is-not-s.ms/
Attachment:
pgpw8acnTQmkc.pgp
Description: PGP signature