deliberate crashes in Gnome libraries ?

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 ?

Thanks
Rod
-- 
------------------------------------------------------------
-------------------------------------
http://distributedco
mputing.info - find out how to make your pc work for 
the community
_______________________________________________
gnome-devel-list mailing list
gnome-devel-listgnome.org
http://mail.gnome.org/mailman/listinfo/gnome-devel-list

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.

Stefan

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 ?
> 
> Thanks
> Rod

_______________________________________________
gnome-devel-list mailing list
gnome-devel-listgnome.org
http://mail.gnome.org/mailman/listinfo/gnome-devel-list

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: ebassigmail.com
W: http://www.emmanuelebas
si.net
B: http://log.emmanuelebas
si.net

_______________________________________________
gnome-devel-list mailing list
gnome-devel-listgnome.org
http://mail.gnome.org/mailman/listinfo/gnome-devel-list

Stefan Kost wrote:
> hi Rod,
> 
> it does not crash the application, it displays a
message and aborts.

If it uses the standard abort() function, there is a way to
override it 
and do something else.

Reed

_______________________________________________
gnome-devel-list mailing list
gnome-devel-listgnome.org
http://mail.gnome.org/mailman/listinfo/gnome-devel-list

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 ?
Thanks
Rod


> 
> Stefan
> 
> 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 ?
>>
>> Thanks
>> Rod
> 
> 


-- 
------------------------------------------------------------
-------------------------------------
http://distributedco
mputing.info - find out how to make your pc work for 
the community
_______________________________________________
gnome-devel-list mailing list
gnome-devel-listgnome.org
http://mail.gnome.org/mailman/listinfo/gnome-devel-list

On Sun, 2007-01-21 at 16:38 +1100, Rod Butcher wrote:
[...]
> 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 ?

I think its safe to say that it is what it is, gtk+ provides
an nice
api for multiple purposes and levels of debugging and
tracing your
app, sometimes software with critical errors seep out of the
woodworks
somehow, maybe the errors were ignored or not considered
harmfull,
then others go compiling "strict" and get crashes
from sloppy code 
segments (or code that was in need of love) you summed it up
pretty
well.

So whats the problem ? how can we improve the situation ?

Maybe its best to just address this at the distro-level,
bleeding
edge distros may have crashes, strict distros might run fast
on
hand held devices and have a slimmer variety of apps that
pass
the test.

Cheers,
                -Tristan


_______________________________________________
gnome-devel-list mailing list
gnome-devel-listgnome.org
http://mail.gnome.org/mailman/listinfo/gnome-devel-list

On Sun, 2007-01-21 at 16:38 +1100, Rod Butcher wrote:
[...]
> 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 ?

Oh sorry after re-reading you I think you might be looking
for
a more practical answer.

The reason why the checks are disabled in a
"strict" environment
is because your software has attained a level of stability,
at this
point you can safely remove the checks at compile time and
speed things
up a bit (sadly I haven't seen many projects reach this
level of
confidence and stability).

Cheers,
               -Tristan


_______________________________________________
gnome-devel-list mailing list
gnome-devel-listgnome.org
http://mail.gnome.org/mailman/listinfo/gnome-devel-list