Memory leak in QPID SWIG Python Bindings

[Eric Harris <eh...@princeton.com>]

I was running QPID 10 with the patches from QPID-3333 (see
https://issues.apache.org/jira/browse/QPID-3333 ) and noticed there
appeared to be a memory leak.

>>> import cqpid
>>> import gc
>>> inContent=["a", "b"]
>>> msg=cqpid.Message(inContent)
>>> outContent=msg.content
>>> id(inContent)==id(outContent)
False
>>> len(gc.get_objects())
7938
>>> for i in xrange(10000): outContent=msg.content;
...
>>> len(gc.get_objects())
17932

Every time we point outContent to a new msg.content, the object it had been
pointing at should have a reference count of zero, and be available for
garbage collection, however it looks like our reference counting is off so
these objects end up never getting deleted.  The same is also true of
messages that contain maps.  I know of no issue if the message does not
contain a list or a map (I also believe empty lists and maps are not
affected by this).  It looks like the change to
qpid::messaging::Message:_get_content in
0013-Handle-amqp-list-and-amqp-map-content.patch that lets msg.content
return a list or map is what is letting us see the problem, although the
actual cause is a deeper issue with reference counting.  Anthony (the
original developer behind QPID-3333) put together a patch to modify the way
references are incremented which I am attaching, although it is not well
tested and it appears the memory increase still exists with it, so works
still needs to be done.  Since getting maps or lists out of messages was
not particularly important, we simply circumvented this issue by editing
qpid::messaging::Message:_get_content to not call decodeList or decodeMap,
but the general map/list reference counting issue probably warrants some
further looking into.


Eric Harris
Analyst
Princeton Consultants, Inc.
2 Research Way
Princeton, NJ 08540
609.987.8787 ext. 415
EHarris@princeton.com