Am 11.01.2013 07:09, schrieb Nick Coghlan:

On Fri, Jan 11, 2013 at 2:57 PM, wrote:

...

results for aef7db0d3893 on branch "default" --------------------------------------------

test_dbm leaked [2, 0, 0] references, sum=2 test_dbm leaked [2, 2, 1] memory blocks, sum=5

Hmm, I'm starting to wonder if there's something to this one - it seems to be popping up a bit lately.

...

test_xml_etree_c leaked [56, 56, 56] references, sum=168 test_xml_etree_c leaked [36, 38, 38] memory blocks, sum=112

I'm gonna take a wild guess and suggest there may be a problem with the recent pickling fix in the C extension :)

It has more issues. Coverity has sent me some complains, see attachment.

On Thu, Jan 10, 2013 at 10:09 PM, Nick Coghlan wrote:

On Fri, Jan 11, 2013 at 2:57 PM, wrote:

...

results for aef7db0d3893 on branch "default" --------------------------------------------

test_dbm leaked [2, 0, 0] references, sum=2 test_dbm leaked [2, 2, 1] memory blocks, sum=5

Hmm, I'm starting to wonder if there's something to this one - it seems to be popping up a bit lately.

...

test_xml_etree_c leaked [56, 56, 56] references, sum=168 test_xml_etree_c leaked [36, 38, 38] memory blocks, sum=112

I'm gonna take a wild guess and suggest there may be a problem with the recent pickling fix in the C extension :)

Yep. We're on it :-) Eli

On Fri, Jan 11, 2013 at 8:08 AM, Christian Heimes wrote:

Am 11.01.2013 07:09, schrieb Nick Coghlan:

...

On Fri, Jan 11, 2013 at 2:57 PM, wrote:

...

results for aef7db0d3893 on branch "default" --------------------------------------------

test_dbm leaked [2, 0, 0] references, sum=2 test_dbm leaked [2, 2, 1] memory blocks, sum=5

Hmm, I'm starting to wonder if there's something to this one - it seems to be popping up a bit lately.

...

test_xml_etree_c leaked [56, 56, 56] references, sum=168 test_xml_etree_c leaked [36, 38, 38] memory blocks, sum=112

I'm gonna take a wild guess and suggest there may be a problem with the recent pickling fix in the C extension :)

It has more issues. Coverity has sent me some complains, see attachment.

The second report is indeed a false positive. Coverity doesn't know that PyList_GET_SIZE returns 0 for PyList_New(0). Maybe it can be taught some project/domain-specific information? The first report is legit, however. PyTuple_New(0) was called and its return value wasn't checked for NULL. I actually think Coverity is very useful for such cases because forgetting to check NULL returns from PyObject constructors is a common mistake and it's not something that would show up in tests. Anyway, this was fixed. Thanks for reporting Eli