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 <[EMAIL PROTECTED]> wrote: > > > Date: Sun, 14 Oct 2007 10:24:14 -0400 (EDT) > > From: Allin Cottrell <[EMAIL PROTECTED]> > > Subject: Re: Don't understand valgrind output > > To: Michael Lamothe <[EMAIL PROTECTED]> > > Cc: gtk-app-devel-list@gnome.org > > Message-ID: > > <[EMAIL PROTECTED]> > > 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 > _______________________________________________ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
