original) (raw)
(On Fri, Jan 11, 2013 at 8:08 AM, Christian Heimes <christian@python.org> wrote:
Am 11.01.2013 07:09, schrieb Nick Coghlan:
> On Fri, Jan 11, 2013 at 2:57 PM, �<solipsis@pitrou.net> wrote:It has more issues. Coverity has sent me some complains, see attachment.
\>> 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 :)
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