Re: gEDA-user: Random thoughts on the future interface of PCB

[Peter Clifton <pcjc2@xxxxxxxxx>]

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
geda-user@xxxxxxxxxxxxxx
http://www.seul.org/cgi-bin/mailman/listinfo/geda-user