Re: Memory debugging -- which tool?

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

Valgrind for most of it.  However, be warned, if you have a
multi-threaded application and you're trying to debug a
multi-threading issue, Valgrind is not going to work for you.
Valgrind does some hocus-pocus to simulate multi-threading, but you
will not get the same conditions as when your application is running
bare.

Thanks,

Michael

On 13/12/2007, jcupitt gmail com <jcupitt gmail com> wrote:
> On Dec 13, 2007 9:25 AM, Dan H <dunno stoptrick com> wrote:
> > I'm trying to use valgrind to track down this issue; however, this slows down my app to the point where 
> > it takes close to a minute for the GUI to start up, and then another minute to get to the crash. I've 
> > used ccmalloc with good success in the past, it has very little overhead, but it doesn't seem to support 
> > gcc-2.4.1 any more. I need something faster than valgrind.
>
> I used to use efence, but it's valgrind all the way for me now.
>
> efence is fast but VERY memory hungry. I have a 64-bit machine now and
> valgrind works wonderfully well. My app needs at least 70MB of RAM on
> startup and that's enough for efence to run out of space on an 8 GB
> machine :-( valgrind is bit sluggish, but you can just go for a coffee
> while waiting for it to spot something.
>
> A good tip is to make a careful suppressions file so valgrind only
> stops your program for your errors. It makes using it much more
> hands-off.
>
> John
> _______________________________________________
> gtk-app-devel-list mailing list
> gtk-app-devel-list gnome org
> http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list