Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > Python > A memory leak involving builtin/pure-python inheritance.

Reply
Thread Tools

A memory leak involving builtin/pure-python inheritance.

 
 
nejucomo@gmail.com
Guest
Posts: n/a
 
      11-14-2006
Hi folks,


Quick Synopsis:

A test script demonstrates a memory leak when I use pythonic extensions
of my builtin types, but if I use the builtin types themselves there is
no memory leak.

If you are interested in how builtin/pure-python inheritance interacts
with the gc, maybe you can help me fix my memory leak.


Background:

I'm creating an extension module (see [1]) which implements the LADSPA
host interface (see [2]). A similar project appears to do the same
using pyrex (see [3]), but I have not investigated it yet.

I've discovered a memory leak and I'm fairly certain of the where
the culprit reference cycle is. The problem is I am not sure how
to instruct the gc to handle it, even after reading about supporting
builtin containers (see [4]).


My question:

How do I correctly implement a builtin type and its pythonic extension
type such that reference cycles are detected and collected?


Details:

There are three relevant LADSPA types:

A "handle" is an audio processing module which operates on input and
output streams.

A "descriptor" describes the interface to a handle such as the types
in the I/O streams, and their names and descriptions. A handle is the
instantiation of a particular descriptor.

A "plugin" is a container providing zero or more descriptors which can
be dynamically loaded. (Typically a shared object library that the
LADSPA host loads at runtime.)


The python-ladspa package is designed as follows:

There is a low-level builtin extension module, called "_ladspa", and a
high-level interface module, called "ladspa".

For each of the three LADSPA types, there is an extension type in the
"_ladpsa" module, for example: "_ladspa.Descriptor".

For each extension type there is a high-level subtype in the "ladspa"
module. So "ladspa.Handle" inherits from "_ladspa.Handle".


The reference structure of the "_ladspa" module is tree-like with
no cycles. This is because a handle has a single reference to its
descriptor, and a descriptor has a single reference to its plugin.

However, the high-level interface introduces a reference cycle because
this makes the interface more natural, IMO.


I've created a diagram which attempts to represent the inheritance
relationships as well as the reference structure of this wrapper (see
[5]). Let me know if you find it clarifies things or needs
improvement.


There is a test script, "memleak.py", which tests either module by
repeatedly instantiating and discarding references to handles (see
[6]).
When configured to use the "_ladspa" module, there appears to be no
memory usage growth, but if using the "ladspa" module, memory grows
linearly with the number of iterations.

If I comment out the "Descriptors" list in the "ladspa.Plugin" class
(which removes the reference cycle) then "memleak.py" runs with no
apparent memory leak.

The leak persists even if I implement traverse and clear methods for
all three builtin types, unless I've done this incorrectly.


Of course one solution is to do away with the reference cycle. After
all
the _ladspa extension does not have the cycle and is usable. However I
care more about a user-friendly interface (which I believe the
reference
cycle provides) and also I'm just curious.


Thanks for any help,
Nejucomo


References:
[1] http://sourceforge.net/projects/python-ladspa/
[2] http://www.ladspa.org/
[3] http://sourceforge.net/projects/dsptools/
[4] http://www.python.org/doc/2.3.5/ext/node24.html
[5]
http://python-ladspa.svn.sourceforge...41&view=markup
[6]
http://python-ladspa.svn.sourceforge...37&view=markup

 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Memory leak even after deleting memory pointers from vector cham C++ 5 09-25-2008 10:30 AM
Leak or no leak ?? Richard Heathfield C Programming 4 07-10-2006 11:37 AM
Dynamic memory allocation and memory leak... s.subbarayan C Programming 10 03-22-2005 02:48 PM
Memory leak??? (top reporting high memory usage under Solaris) Mark Probert Ruby 4 02-09-2005 06:13 PM
problem involving NAT and PAT Ionut Cisco 1 07-31-2004 12:29 AM



Advertisments