Hi everyone!
In my recent effort to decimate the bug list present on mantis I
stumbled across bug #2995 and its duplicate #3007. Bottomline is:
g_error() internally calls abort() which in turn raises SIGABRT leading
to a core dump. We currently use g_error in all places where a
non-recoverable error occurs. This leads to dumping the core when
trying to kill a non-existing mpd-PID or specifying an unknown command
line argument which hardly justifies measures as drastic as a core dump.
In total, there are 68 individual calls to g_error().
I suggest fixing this by replacing
if (foo)
g_error("bar");
with
if (foo) {
g_message("bar");
exit(EXIT_FAILURE);
}
This raises the following questions:
1. Which occurrences of g_error() must be replaced?
Glib documentation states: "don't use it for errors you expect. Using
this function indicates a bug in your programm, i.e. an assertion
failure". Thus, at least all error caused by bogus user input (e.g.
illegal config file lines, command line arguemnts) should be replaced.
Are there even occurrences of g_error() where a core dump would actually
help us to debug a problem?
2. How to replace: full text in place or using a macro? I'd suggest to
not use a macro to keep it more readable, but that's just my 2 cents.
3. What debug printing measure is appropriate in your eyes? There's
bunch to choose from. I favor g_message(), but [1] lists some more.
Before I get started and look at all 68 places where g_error() is used,
I'd like to gather your opinions on this matter. In particular I'd be
interested in Avuton's opinion on how this impacts the Win32 port. Is
exit(EXIT_FAILURE) available there as well?
Thomas
[1] http://library.gnome.org/devel/glib/stable/glib-Message-Logging.html#g-error
--
Thomas Jansen, "Mithi" --- mi...@mithi.net
GPG 9D5C682B, feel free to sign or encrypt your mail
------------------------------------------------------------------------------
Start uncovering the many advantages of virtual appliances
and start using them to simplify application deployment and
accelerate your shift to cloud computing.
http://p.sf.net/sfu/novell-sfdev2dev
_______________________________________________
Musicpd-dev-team mailing list
Musicpd-dev-team@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/musicpd-dev-team
