Re: deliberate crashes in Gnome libraries ?

Stefan Kost wrote:
hi Rod,

it does not crash the application, it displays a message and aborts. You can
disable these checks during build and this can be debated wheter distribution
should do it or not. The developer should have them definitely active. The
purpose is that the library figures out that something is wrong as soon as
possible. If in the example below you call a function that works on container
widgets and give it a GtkCellRenderer that it should stop immediately. This
gives you the change to get a menaingful backtrace in gdb. If it continues, the
user will wonder why the UI look borked and nobody fixes the bug.
To me "debug mode" means the ability to step through the standard code as it executes, nothing about changing the way errors are handled. A program should run the exact same code in debug as in normal mode, including error handling. For a module to pre-empt or second-guess potential errors is mission-creep - it is sanity checking, not debugging, and should only be performed in a testing environment, not on released apps. We get the situation where naughtily-coded released apps (in this case a Boinc gui manager) do naughty things and continue to get away with it because distros like Mandriva apparently turn debug off in their glib and gtk builds. But when we run these apps in a debug gnome environment they crash. When the purpose of the debug gnome environment is to test and debug Gnome itself, i.e. all the Gnome components I've built with debugging on, rather than the apps I'm running like Boinc, I end up with the apps themselves being crashed by the gnome modules - tail wagging dog. Seems what is needed is something like "strict mode' which is something different to "debug mode".

I found this strange section on the developer.gnome website for glib & gtk :- --enable-debug. Turns on various amounts of debugging support. Setting this to 'no' disables g_assert(), g_return_if_fail(), g_return_val_if_fail() and all cast checks between different object types. Setting it to 'minimum' disables only cast checks. Setting it to 'yes' enables runtime debugging. The default is 'minimum'. Note that 'no' is fast, but dangerous as it tends to destabilize even mostly bug-free software by changing the effect of many bugs from simple warnings into fatal crashes. Thus --enable-debug=no should not be used for stable releases of GLib.

What if lots of stuff won't run unless debug=no ? Then what's the use of debug ?

Or have I missed the point here ?


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. 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.

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.

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 ?


------------------------------------------------------------------------------------------------- - find out how to make your pc work for the community

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]