Emmanuele Bassi wrote:
> 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.
It seems like I had misunderstood the purpose of --enable-debug. It
turns on sanity-test code to facilitate debugging. The setting of the
-ggdb compiler option is a separate issue, which I can control by e.g.
export CC='gcc -ggdb ' or whatever . The implication is that I should
be able to turn off the sanity checks (asserts etc.) to allow "bad" apps
to run while still allowing debugging with gdb . Correct ? This seems to
me the only way to allow the home user to run any app including suspect
games while still being able to obtain debug info, albeit perhaps
misleading if the problem started sometime before the crash.
thanks
Rod
>
> 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.
>
--
-------------------------------------------------------------------------------------------------
http://distributedcomputing.info - find out how to make your pc work for
the community
_______________________________________________
gnome-devel-list mailing list
[email protected]
http://mail.gnome.org/mailman/listinfo/gnome-devel-list
