Re: Bug in GLib, libglade, libc??

[David Nečas (Yeti) <yeti physics muni cz>]

On Fri, Aug 11, 2006 at 12:53:50PM -0300, Fabricio Rocha wrote:
>       QUESTION: This is quite mysterious for me. If the program runs fine a 
> lot of times, it does not look a bug in the code itself.

Most likely it is either a race condition or a use of an
undefined value in the code itself.  Also, since the second
occurs on exit, it may be plain double-freed memory that
just usually doesn't get a chance to crash the program till
the exit, or something similar.

>       So... any tips?

Learn to debug.  Don't take this personally (especially when
you actually demonstrated a mild attempt to debug it) but
the number of people posting questions `why my code crashes'
without any serious attempt to debug it is startling.  So
first of all:

1. Compile with debugging.  I don't know if debug info is
available in/for Debian packages, some other distros provide
standalone -debuginfo or -debug packages with debug info.
Otherwise one has to roll his own version of the affected
library to look at what's going on.

In the case of Gtk+ or GLib it's good to use --with-debug=yes
while you are at it, it gives them the ability to flood the
console with messages in response to G_DEBUG, GDK_DEBUG and
GTK_DEBUG contents (see the reference) which is occasionally
useful.

--enable-gc-friendly helps to get reliable outputs from
tools like valgrind, although it can affect what the program
actually does -- especially when it is buggy and accesses
freed memory (but this typically means it crashes sooner
which is good).

2. Use valgrind.  It can tell you what the pointer passed to
free is/was.  If an undefined value is used it will most
likely tell you too.  It helps a lot when used in
conjunction with the previous point.

3. Use gdb.  I mean really use it, instead of just printing
a backtrace (although many prople don't even bother with
that).  It can tell you what's the object involved, what's
its data members, what's the object data involved, etc.  It
can do much more, but even dead coredump examination can
tell a lot.  Again, it works best with point 1.

What happens inside the libs is usually much less
interesting than what happens in your app (the stack
traces you posted lack that and don't tell much).

4. If you suspect X-related race conditions, use --sync.

5. Try to find a simple, selfcontained way to reproduce it,
although this may be hard sometimes.

And if after all this you are still unable to find the
cause, it will at least give you enough information for
a much more meaningful post.  After all, the libraries do
contain bugs -- even if far less than app programmers think.

Yeti


--
Anonyms eat their boogers.