Re: Feature request regarding --g-fatals-warnings

[Martin Baulig <martin home-of-linux org>]

Tim Janik <timj@gtk.org> writes:

> On 28 Jul 2000, Martin Baulig wrote:
> 
> > Hi,
> > 
> > I'd like to submit a little feature request to add
> > the following:
> > 
> > 1.) A way to specify which log levels should be considered
> >     fatal on the command line (so that you can exclude
> >     G_LOG_WARNING from being fatal, for instance and only
> >     bail out on G_LOG_CRITICAL).
> 
> well, we currently feature --g-fatal-warnings which makes
> G_LOG_LEVEL_CRITICAL and G_LOG_LEVEL_WARNING fatal.
> note that that flag is really only usefull for debugging
> purposes, i.e. you fire up your application in gdb and
> start it with --g-fatal-warnings to get backtraces from
> the points where warnings are triggered.
> what you ask for is probably --g-fatal-criticals (not sure
> that wording works actually), that's only make G_LOG_LEVEL_CRITICAL
> fatal, but that's not really required, see my answer on 2)

Well, I was thinking about the situation where you're running
the program from the command line (for instance, since it takes
way too long to start in gdb) and you want to get a core dump
when something goes wrong.

> > 2.) A way to ignore the first N fatal warnings on the command
> >     line.
> > 
> >     This becomes useful when a program always displays N fatal
> >     warnings on startup which you know about and which you want
> >     to ignore (for instance, warnings about things being
> >     deprecated).
> 
> 1.2.x is a bit dump here in calling abort() on fatal log levels,
> you can really only escape that with catching abort() and
> skipping over that function (gdb's "return" command).
> for 2.0 however, we do raise (SIGTRAP); there if debugging
> is enabled (this will simply produce a core dump if not ran
> in gdb), which allowes you to simply quit over any number
> of fatal levels with "continue", provided you know what you are
> doing.

Yes, that's very nice in 2.0.

> note, that in many cases, successive warnings/criticals are
> produced due to the first one failing, so often, if you don't
> fix the first one, you get tons of bogus successors.

Well, I'm currently debugging gnome-libs 2.0 and every time I
start a program I get this "you are using the devel branch of GTK+"
warning and a couple more "foo() is deprecated" ones.

I just want to be able to run `./selector_demo --g-fatal-crititals'
or something like this and get a core dump when something goes
really wrong.

Even when I run the thing in gdb, I'm a bit too lazy to hit 'c'
several times when the program starts just to get over the deprecated
warnings.

> because of that, and because users really shouldn't have
> the ability to simply skip over fatal situations, i.e.
> where you'd call g_error() since that's often used to
> catch invariant breakage and prevent further mess-ups,
> i'll not introduce something like
> --g-ignore-n-universe-screwups=13
> and of course strongly discourage developers to do so
> for gnome-libs or applications.

Also with stable versions of the libraries, you sometimes get warnings
about the use deprecated functions.

This is extermely annoying if you want to debug something totally
different than that deprecated function.

As soon as you get one such warning, --g-fatal-warnings is totally
useless for you.

> if you get far more than one warning, _fix_ them, and if you
> use --g-fatal-warnings, you're already using gdb, and there
> you can handle the situation gracefully.

Not always.

Some programs work in 80% of all cases and you just want to run
them in gdb if something goes wrong, so there should be a way to
get a core dump.

-- 
Martin Baulig
martin@gnome.org (private)
baulig@suse.de (work)