Re: Outstanding patches, #58330



On Mon, 13 Aug 2001, Matthias Clasen wrote:

> Is the version appended below better ? Note that I removed information about
> unused debug flags now.

unused debug flags should be removed from the code as well, we should
do this in one go with updating debugging.txt, i'd apprechiate if you
incorporated that into your patch.

> 
> Matthias
> 

> The GLIB, GDK, and GTK libraries have extensive support for
> debugging the library and your programs.
> 
> The amount of debugging being done can be determined both
> at run time and compile time.
> 
> COMPILE TIME OPTIONS
> --------------------
> 
> At compile time, the amount of debugging support included is
> determined by four macros:
> 
> G_ENABLE_DEBUG
>   If set, enable support for runtime checking.
> 
> G_DISABLE_ASSERT
>   If set, disable g_assert macros
> 
> G_DISABLE_CHECKS
>   If set, disable the g_return_if_fail and g_return_val_if_fail macros

this is potentially harmfull, se below.

> GTK_NO_CHECK_CASTS
>   If set, don't check casts between different object types
> 
> 
> Whether these macros are defined is controlled at configuration
> time by the --enable-debug option.
> 
> --enable-debug=minimum [default]
>   Enable only inexpensive sanity checking
>     sets GTK_NO_CHECK_CASTS
> 
> --enable-debug=yes
>   Enable all debugging support
>     sets G_ENABLE_DEBUG
> 
> --enable-debug=no (or --disable-debug)
>   Disable all debugging support (fastest)
>     sets G_DISABLE_ASSERT, G_DISABLE_CHECKS, and GTK_NO_CHECK_CASTS

this needs special flagging, because --enable-debug=no implies
GTK_NO_CHECK_CASTS and that gets rid of g_return_if_fail() statements.
g_return_if_fail() aren't only in place just to provide developer friendly
warnings of code misbehaviour, they also protect a couple of constraints
that have to be maintained for program integrity. yes, ideally no code
would ever spew a warning, but in practice that's not the case because:
a) people write errernerous code and are too lazy to fix their warnings
   (this is pretty pathological and we can't really help it)
b) some errors hide in code paths that weren't thoroughly tested before
   a program went into production stage (i.e. burned onto a distributors
   CD). this actually happens fairly frequently, because most developers
   can't imagine _all_ ways their programs/libraries are used in, or this
   may also happen due to time constraints. (if this wouldn't happen so
   frequently, we'd have close to 0 crash/segfault bugreports)
c) with the increasing code complexity of todays programs and libraries,
   some bugs are really rarely triggered. e.g. depending on system load,
   timeouts, interprocess communication such as xlib, etc...
   these are usually hard to track because of limited reproduction ability

certainly all of the above can lead to your favourite word processor,
gnutella, pager, session manager, linux-installer, whatever, app to crash.
but often enough they just trigger some g_return_if_fail statement that
keeps the program in a state sane enough where you can still save your
word document, your download doesn't abort or your desktop session
doesn't crash.
in those cases, g_return_if_fail statements, while errernously triggered,
at least managed to maintain program integrity.
a simple example of g_return_if_fail maintaining an important constraint
(that of finalizing an object only once):

some_object_finalize (GObject *o)
{
  foo (o);
  parent_class->finalize (o);
}

foo (GObject *o)
{
  g_object_ref (o);
  /* ... */
  g_object_unref (o);
}

with !G_DISABLE_CHECKS you'll probably get just:

**: g_object_ref(): assertion failed `obj->ref_count > 0´
**: g_object_unref(): assertion failed `obj->ref_count > 0´

with G_DISABLE_CHECKS you'll definitely get a segfault, or
an infinite loop, since
g_object_ref(o) will do o->ref_count++; and therefore
g_object_unref(o) will finalize the object _again_.
either you get caught in a loop that way, or if foo() is
conditionalized you'll segfault as parent_class->finalize (o);
will operate on an already free()-ed memory portion.

thus !G_DISABLE_CHECKS and --enable-debug=no are to be considered
dangerous and not just "fast", as they tend to destabelize even
mostly bug-free software by making most cases triggering (b) and
(c) fatal cases.

this is also why i don't at all consider --enable-debug=no an
option for stable releases of glib/gtk.


> RUN TIME OPTIONS

i think runtime is a common enough term to be written in one word.

>  GTK_DEBUG
>  ---------
> 
>  Options only interesting to library maintainers:
> 
>  'text'          - Information about text widget internals
>  'tree'          - Information about tree widget internals
>  'updates'       - Visual feedback about window updates
> 
> 
>                                     - Owen Taylor <owt1 cornell edu>
>                                       98/02/19

you should amend this according to your changes, e.g.:

	- Mon, 13 Aug 2001 Matthias Clasen
	- 98/02/19 Owen Taylor

or use ChangeLog style mode, stating that you reworked the file and
that owen provided the initial version.

> 
> 

---
ciaoTJ





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