Home Original page

Tracking down a memory leak

Kip Macy kip_macy at yahoo.com
Sun Jan 20 21:57:04 EST 2002 
Paul Rubin <phr-n2002a at nightsong.com> wrote in message news:<7xit9xp3yf.fsf at ruckus.brouhaha.com>...
> kip_macy at yahoo.com (Kip Macy) writes:
> > I have a long running python program that typically uses 6-7MB. It can 
> > happily run for days without any problems, but periodically it will balloon
> > and use up all available memory and swap. I'm aware that the presence of
> > circular reference can defeat garbage collection. Are there any recommended
> > utilities or methods for determining what data structures are using up all
> > available memory?
> 
> Is it a pure python program?  I'd be suspicious of any nonstandard C
> modules that you might be using.  I've seen some of them leak memory.

Python 2.1.2
It is a pure python program except for its reliance on the bsddb
module, which does not compile by default on Solaris:
gcc -shared build/temp.solaris-2.8-sun4u-2.1/bsddbmodule.o
-L/usr/local/lib -ldb -o build/lib.solaris-2.8-sun4u-2.1/bsddb.so
Text relocation remains                         referenced
    against symbol                  offset      in file
<unknown>                           0x944      
/usr/local/lib/libdb.a(db185.o)
<unknown>                           0x948      
/usr/local/lib/libdb.a(db185.o)
<unknown>                           0x94c      
/usr/local/lib/libdb.a(db185.o)
<unknown>                           0x950      
/usr/local/lib/libdb.a(db185.o)
<unknown>                           0x954      
/usr/local/lib/libdb.a(db185.o)
<unknown>                           0x958      
/usr/local/lib/libdb.a(db185.o)
etc.

I have to link it explicitly by doing:
ld -r build/temp.solaris-2.8-sun4u-2.1/bsddbmodule.o
-L/u/kmacy/src/db-3.2.9/dist -ldb -o
build/lib.solaris-2.8-sun4u-2.1/bsddb.sold -r
build/temp.solaris-2.8-sun4u-2.1/bsddbmodule.o
-L/u/kmacy/src/db-3.2.9/dist -ldb -o
build/lib.solaris-2.8-sun4u-2.1/bsddb.so

(gdbm has the same problem)
In an older version of python it would periodically die on me
somewhere in the bsddb code. Is it possible that bsddb is responsible
for this leak?

Thanks.
More information about the Python-list mailing list