On Sat, 2010-12-04 at 11:15 +1100, Stephen Ecob wrote: > hid/common/actions.c:269' <- Can't see this one myself.. there is no exit > path out of that function which fails to free that allocation! > hid/common/actions.c:46' <- Array of actions persistent over PCB's entire > execution. Not a leak > hid/common/flags.c:41' <- Array of flags persistent over PCB's entire > execution. Not a leak > hid/common/flags.c:71' <- Array of flags persistent over PCB's entire > execution. Not a leak > hid/common/hidinit.c:171' <- Array of hids persistent over PCB's entire > execution. Not a leak > hid/common/hidinit.c:250' <- Array of hid attributes persistent over PCB's > entire execution. Not a leak > hid/common/hidinit.c:659' <- Not a leak as far as I can tell.. returned > value should be cached / free'd elsewhere. Seems ok. > hid/common/hidinit.c:688' <- "Think" this is ok
> hid/gtk/gtkhid-gdk.c:352' <- ??? (Doesn't line up with code in my checkout > out branch.. sorry). > hid/gtk/gui-log-window.c:150' <- Cached memory allocated for log messages. > Not really a leak. > hid/gtk/gui-top-window.c:266' <- Cached memory allocated for accelerators. > Not really a leak. > hid/gtk/gui-top-window.c:2997' <- ??? (Doesn't line up with code in my > checkout out branch.. sorry). > hid/gtk/gui-top-window.c:3005' <- ??? (Doesn't line up with code in my > checkout out branch.. sorry). > hid/gtk/gui-top-window.c:3034' <- ??? (Doesn't line up with code in my > checkout out branch.. sorry). > hid/gtk/gui-top-window.c:3042' <- ??? (Doesn't line up with code in my > checkout out branch.. sorry). > hid/gtk/gui-top-window.c:3306' <- ??? (Doesn't line up with code in my > checkout out branch.. sorry). > hid/gtk/gui-top-window.c:3695' <- ??? (Doesn't line up with code in my > checkout out branch.. sorry). > main.c:780' <-- Global variable. Not a leak. > main.c:790' <-- Global variable. Not a leak. > main.c:800' <-- Global variable. Not a leak. > main.c:810' <-- Global variable. Not a leak. > main.c:820' <-- Global variable. Not a leak. > misc.c:1704' <-- Just a returned value - some caller might be leaking > though > mymem.c:663' <-- Just a returned value - some caller might be leaking > though > mymem.c:707' <-- Just a returned value - some caller might be leaking > though > parse_l.c:2232' <-- Leak in the parser? (Source file: parse_l.l) > res_lex.c:1857' <-- Leak in the parser? (Source file: res_lex.l) > rtree.c:453' <-- MIGHT be something leaking r-trees, but could also just be > rtree.c:455' some allocated rtrees which are not free'd. Would need to > see > rtree.c:762' _increasing_ memory usage from these points to be worried. > rtree.c:835' > rtree.c:992' Would need a back-trace of which code caused the > allocation. > strflags.c:169' <-- Just a returned value - some caller might be leaking > though > strflags.c:169' <-- Just a returned value - some caller might be leaking > though > strflags.c:171' <-- Just a returned value - some caller might be leaking > though So, a mix of NOT LEAKS, and "might be leaks". We need back-traces of the cases where callers are allocating things repeatedly and not freeing them. Because these are showing up in your DMalloc output as being where memory is allocated (pretty generic routines), we would need a back-trace to see which code caused the allocation before any could be fixed. I believe valgrind is good at detecting leaks! -- Peter Clifton Electrical Engineering Division, Engineering Department, University of Cambridge, 9, JJ Thomson Avenue, Cambridge CB3 0FA Tel: +44 (0)7729 980173 - (No signal in the lab!) Tel: +44 (0)1223 748328 - (Shared lab phone, ask for me) _______________________________________________ geda-user mailing list [email protected] http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
