GNOME Bugzilla – Bug 362749
Desire ability to suppress developer-only warnings
Last modified: 2009-09-06 19:53:18 UTC
GTK and glib produce many very specific errors and warnings about incorrect use of these libraries. These messages are doubtless very useful to developers writing GTK+ applications. However, once the application has shipped to users, it continues to produce developer-oriented messages on stderr, relating to destroying null objects, geometry sizing errors, and other such issues. Doubtless all of these represent real problems with the program, but they are not end-user fixable, and they can damage the use of the program. Typically programs printing out such errors which reach end-user hands work correctly, despite the flaws in design. However, the copious output of these warnings can bury important information in the stdout and stderr datastreams from the program to the user. Worse, it may be that the the stderr or stdout of the program is part of the intended output of the program, and these warnings may invalidate this output. I believe there should be some way that end-user use of GTK applications can suppress or seperate out messages which have no utility for end users. Ideally it should be possible to create a configfile, environment variable, X resource, or what have you to request that GTK applications generally direct their developer-only warnings in a reasonable manner (to a file, to dev null, to stdout after all, or what have you). The current situation, is that some GTK programs have the entirety of their output directed to /dev/null, which make diagnosing some problems quite difficult, while other programs which may be launched indirectly spew to my terminals anyway. ------ I am not sure if the glib/gtk behavior which seems closely modelled in other gnome libraries is provided via a glib facility, or mimiced. In short, should a duplicate request be filed on other libraries (eg. gnomevfs, etc.)?
Just because GTK+ does (depending on how it was compiled) detect invalid input from an application does not mean that applications are allowed to call it with invalid input. If someone sold you a GTK+ program that produces many Gtk-Critical and Gtk-Warning messages, they have sold you a highly buggy program. And in many cases, GTK+ can't properly recover from the invalid input and a segfault will shortly follow. If you start seeing Gtk-Criticals being printed, save now! Your request is somewhat akin to asking for the ability to continue after a segfault, because the user can't do anything about the buggy code that produced the segfault, and maybe it will work. There are far too many application developers who think Gtk-Critical means "I should look at that some day when I'm bored", and I don't think encouraging that attitude is something we want to do. [ If other GTK+ developers disagree, they can reopen and move this to Glib ]
This is frustrating, because there is a real usability issue here, but invariably a developer is going to ignore the usability issue and focus on the coding issue. This is not a request for GTK/GLIB to handle/recover from unrecoverable errors. This is a request for GTK/GLIB to not interfere with the datastream for communication between the program and the user. I have never had a GTK-Warning or GTK-Critical message preceed a segfault. Ever, in all my many years of using Linux as my primary platform. I don't doubt that a GTK-Critical message can indicate a severe bug threatening data integrity. However in the case of programs which actually get through the various filters in place in the Linux world of development processes, packaging, testing, and package feedback, etc, I get programs that work perfectly well but yet spew lots of messages to stderr which are not in any way useful to me, the user. Moreover, I don't think messages identifying that the size of the butten was chosen incorrectly in the geometry setup indicates a crash-bug about to happen. The programs in question (firefox?, drivel, vice, epiphany, others) do work without segfaults or problems, but they do produce various bits of meaningless lint that are really debug output to the console. So, if I was a saintly user, I should report each one of these errors to the bug tracking tools of the program in question, given. But since I'm going to _go on_ useing these programs because they work completely fine, I want a --shut-it-up-you flag to make it possible to see REAL user-intended error messages from the programs like "error cannot open configuration file: permission denied" and "Cannot fork, process table full?" instead of having the screen be a mass of "invalid geometry setup" scrolling along, or not seeing either because I've redirected the output of the program to /dev/null. In fact it's gotten to the point where I get _so_ much spew from Glib and GTK programs that x console is completely uslessly full of intermingled developer-targetted junk. Some of the issues are exactly this one, while others are seperate but the same fundamental problem. Stderr is not a good place for libraries to be sending debug data in an _unchangable_ way. I am sometimes a developer, and when I am a developer, it is crucial that I be able to access this type of output from programs I am maintaining, writing, or enhancing. But when I am a user, all this information is a problem. I understand that it puts pressure on developers to fix it, but after some 5 or so years of this, it seems to me that no amount of pressure will cause all apps to resolve all warnings, while any amount of warnings to stderr damage the usability of the whole system by polluting the the terminal, or worse, the x console.
If you build with --disable-checks then gtk won't check for invalid function args and warn about them, which will result in a crash if the warning really is serious, for something about button size probably not, something will just work incorrectly, maybe a button won't redraw properly or something. Anyway, it will be as if gtk did not have this warn-developers-about-stuff feature, which most libraries don't. If you're really getting a deluge of warnings I wonder if you aren't using some theme engine that has issues or something like that though. I don't typically see tons of these. The warnings are rarely the equivalent of "lint" or super-paranoid compiler warnings, they are usually real problems comparable to a segfault or invalid memory read. Sometimes not, but of those I've ever tracked down most were real problems. I believe that the GNOME project is keeping G_DEBUG=fatal_warnings on by default for all unstable/testing releases in the latest release cycle, so that may chill things out substantially in the future.
(In reply to comment #3) > I believe that the GNOME project is keeping G_DEBUG=fatal_warnings on by > default for all unstable/testing releases in the latest release cycle, so that > may chill things out substantially in the future. I believe we are doing G_DEBUG=fatal_criticals, not fatal_warnings.
As the user (as most of us are) of a binary distribution, the option to "just build" with different than default build options is not a real option. The first time a user sees such an error, it is useful, because they can file a bug. The second time the value is less. After a few years of the same message, the user begins to want to have some means of eliminating this message. Enhancing the logging facility to enable the user to seperate the library messages from the program messages is a win for everyone.
OK, so: - What distribution? - What application? - What error message? the number of times I see Gtk-Critical messages when running GTK+ apps is tiny, and I run a lot more GTK+ applications from the command line then I think is typical.
This is a bug about the unfilterability of logged warnings, errors, and other messages which are not useful for end users, and thus are themselves a problem. This is not a bug about specific programs. I will file bugs against specific programs also, and those problems can be discussed in those bugs.
I think some particular program you are using has given you a distorted sense of the situation. That's why I asked.
So you guys still haven't figured out that stderr is a datastream for the actual application? Impressive.
Joshua: Sarcasm is not needed, see http://live.gnome.org/CodeOfConduct.