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, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > On Dec 13, 2007 9:25 AM, Dan H <[EMAIL PROTECTED]> 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 > _______________________________________________ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
