Re: Don't understand valgrind output

["Michael Lamothe" <michael lamothe gmail com>]

Thanks for the excellent responses.  I think that you're right, I've
been doing a bit of reading about how valgrind works and it appears
that it's especially poor when it comes to multi-threaded
applications.

The CPU time goes to zero when the application freezes.  This
indicates that it's maybe some kind of locking issue.  The UI locks up
when I resize the main window.  My application uses
gdk_threads_enter()/leave() around the gtk_main() call.  I'm also
using libxine to write directly onto a GtkDrawingArea.

I know this is a long shot but has anyone got any experience with this
kind of UI freezing issue or does anyone have any suggestions/ideas
about what I can do?

Thanks in advance,

Michael

On 16/10/2007, Thomas Stover <thomas wsinnovations com> wrote:
> > Date: Sun, 14 Oct 2007 10:24:14 -0400 (EDT)
> > From: Allin Cottrell <cottrell wfu edu>
> > Subject: Re: Don't understand valgrind output
> > To: Michael Lamothe <michael lamothe gmail com>
> > Cc: gtk-app-devel-list gnome org
> > Message-ID:
> >       <alpine LRH 0 9999 0710141020570 30351 ricardo ecn wfu edu>
> > Content-Type: TEXT/PLAIN; charset=US-ASCII
> >
> > On Sat, 13 Oct 2007, Michael Lamothe wrote:
> >
> >
> > > I have been struggling with application freezes in my application for
> > > about 2 months and I was hoping that I could get some help.  I've been
> > > cleaning the application up with errors reported by valgrind but can't
> > > seem to work out what this means.  Can anyone shed some light on this?
> > >  Should I just ignore this memory error?
> > >
> > > ==13801== Syscall param write(buf) points to uninitialised byte(s)
> > > ==13801==    at 0x40007F2: (within /lib/ld-2.5.so)
> > > ==13801==    by 0x4B6D64E: _X11TransWrite (in /usr/lib/libX11.so.6.2.0)
> >
> > I don't think this has anything to do with your application as
> > such.  Valgrind is complaining about apparently uninitialized data
> > in regard to XOpenDisplay.
> >
> > Allin Cottrell
> Yes this happens to me also. It is almost certainly not your
> application. Valgrind normally finds all sorts of errors that are
> effectively not really errors for one reason or another. Example: the C
> library not 100% free()ing something before exit. There is some sort of
> internal valgrind database that is used to suppress this stuff. This
> internal suppression does not always work due to subtleties like
> valgrind build time / application run time gcc/libc mismatches. For
> instance, on the latest 64bit ubuntu, there are dozens of such errors
> that I am not suppose to see, and so I just "know" that certain libc
> based errors can be ignored. Every time I valgrind a gtk app, I get all
> sorts of things like you are seeing with xlib and gtk libs. Whether or
> not these are real problems or ignorable, I don't know. They don't seem
> to cause any runtime issues though. I'm getting the impression that not
> many gtk people use valgrind, since perhapses these errors also could be
> added to the suppression database.
>
> Btw: if your application truly is "freezing" and not crashing with a
> core dump, then you most likely are caught in an infinite loop, or have
> some blocking IO that is being incorrectly handled. Just look at the cpu
> usage of the app next time it freezes. That will be a dead give away
> about the loop.
>
>
>
>
>
> _______________________________________________
> gtk-app-devel-list mailing list
> gtk-app-devel-list gnome org
> http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list