> 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
