Hi, Thanx for the reply, but I fail to see what exactly you propose I do. I've used the same valgrind flags as you've used from the beginning, still there were memory leaks reported. I've also tried mtrace and it gives tons of leaks (as you also said, mtrace is not a solution). Gtk apparently does much more allocations than simple Glib. Any other ideas? Johnny On Friday 02 May 2008 12:39:40 pm Ovidiu Gheorghies wrote: > Hi, > > Please have a look at my post "Glib hashtable memory leak" and let me know > if the recipe given there works for you as well. > > Regards, > Ovidiu > > On Fri, May 2, 2008 at 11:53 AM, Ionutz Borcoman <iborco@xxxxxxxxx> wrote: > > On Friday 02 May 2008 11:34:29 am jcupitt@xxxxxxxxx wrote: > > > When I valgrind my app and check for leaks, I let it run for a while > > > before quitting, then check the output for repeated allocations. If I > > > see the same thing being allocated several times and not freed I know > > > I probably have a leak. > > > > Actually my own leak are my greatest concern. The problem is that having > > those > > leaks reported because of how glib caches data makes debugging your own > > code > > harder. > > > > Any recipe to easily spot or isolate your allocations/dealocations from > > those > > from GTK/Glib? > > > > How do you know the leak is because I haven't freed the memory or because > > I've > > freed it, but Glib hasn't? > > > > Thanx, > > > > Johnny _______________________________________________ gtk-list mailing list gtk-list@xxxxxxxxx http://mail.gnome.org/mailman/listinfo/gtk-list
