Re: deliberate crashes in Gnome libraries ?

[Emmanuele Bassi <ebassi gmail com>]

hi;

On Sun, 2007-01-21 at 03:07 +1100, Rod Butcher wrote:
> I have a general question about why some Gnome libraries include code 
> which deliberately crashes the app if it does something the library 
> considers iincorrect instead of letting the app blunder on.

albeit it debated between developers, most of them believe that
explicitly aborting when the application is doing something so wrong
that it shouldn't be allowed to continue is the right way to write a
library.  it is true, from my experience and perspective, that if the
application just run unchecked in this cases, then the bugs would never
be fixed.

if you application is abort()-ing after the alpha and beta cycles then
you're obviously doing something wrong - and that shouldn't have escaped
you attention until that late in the development cycle.

in any case, you can compile out all the asserts and all the checks from
GLib and GTK+ using a command line switch at configure time; why this is
not a good idea in the development cycle I'll leave it to you.

>  Examples :-
> 
> gtk+ : gtkcontainer.c line 988
>   gtk_container_remove (GtkContainer *container,
> 		      GtkWidget    *widget)
> {
>    g_return_if_fail (GTK_IS_CONTAINER (container));
>    g_return_if_fail (GTK_IS_WIDGET (widget));
> 
>    /* When using the deprecated API of the toolbar, it is possible
>     * to legitimately call this function with a widget that is not
>     * a direct child of the container.
>     */
>    g_return_if_fail (GTK_IS_TOOLBAR (container) ||
> 		    widget->parent == GTK_WIDGET (container));
> This crashes boinc client gui, app works fine if this is removed.

it's quite obvious that, if you remove the check, then the application
doesn't abort; it's also obvious that, if the application did abort, you
were doing something wrong - in this case, you were trying to remove a
widget from a container without knowing whether the widget was in fact a
child of that container.  better than leaving the "removal of a
non-child widget" an undefined behaviour, the library is explicitly
telling you that doing so is a no-no.  you should heed the warning of
the library.

> Glib : gthread-impl.c line 296
> g_thread_init (GThreadFunctions* init)
> {
>    gboolean supported;
> 
>    if (thread_system_already_initialized)
>      g_error ("GThread system may only be initialized once.");

> This crashes sweep, which works oK if test is removed.

you are trying to change the thread functions table *after* you changed
them; this is even worse a case to leave an undefined behaviour running,
as you might have a thread with a thread functions table and another
thread with another functions table entirely.  this is absolutely not
good, and I would expect all kind of hell to break loose.  I'm glad that
the library catches this kind of sloppy programming for me.

> I found a similar assert in libxcb which crashed boincclient-gui and 
> other apps until I removed it. So why are these apparently hostile lines 
> of code there ? Shouldn't apps be allowed to do whatever they like ?

if what they like is most likely to produce undefined behaviours, memory
corruptions and crashes, then absolutely not.

+++

so, if these are warnings and checks that your applications are
consciously ignoring, then I suggest you should fix your applications
ASAP, for they are bound to bite you in the ass sooner or later. :-)

ciao,
 Emmanuele.

-- 
Emmanuele Bassi,  E: ebassi gmail com
W: http://www.emmanuelebassi.net
B: http://log.emmanuelebassi.net