<div dir="ltr">On Fri, Jan 11, 2013 at 8:08 AM, Christian Heimes <span dir="ltr"><<a href="mailto:christian@python.org" target="_blank">christian@python.org</a>></span> wrote:<br><div class="gmail_extra"><div class="gmail_quote">

<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Am 11.01.2013 07:09, schrieb Nick Coghlan:<br>
<div class="im">> On Fri, Jan 11, 2013 at 2:57 PM,  <<a href="mailto:solipsis@pitrou.net">solipsis@pitrou.net</a>> wrote:<br>
>> results for aef7db0d3893 on branch "default"<br>
>> --------------------------------------------<br>
>><br>
>> test_dbm leaked [2, 0, 0] references, sum=2<br>
>> test_dbm leaked [2, 2, 1] memory blocks, sum=5<br>
><br>
> Hmm, I'm starting to wonder if there's something to this one - it<br>
> seems to be popping up a bit lately.<br>
><br>
>> test_xml_etree_c leaked [56, 56, 56] references, sum=168<br>
>> test_xml_etree_c leaked [36, 38, 38] memory blocks, sum=112<br>
><br>
> I'm gonna take a wild guess and suggest there may be a problem with<br>
> the recent pickling fix in the C extension :)<br>
<br>
</div>It has more issues. Coverity has sent me some complains, see attachment.<br></blockquote></div><br></div><div class="gmail_extra">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?<br>

<br></div><div class="gmail_extra">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.<br>

<br>Thanks for reporting<br><br>Eli<br></div><div class="gmail_extra"><br><br></div></div>