Re: [Python-Dev] [Python-checkins] Daily reference leaks (aef7db0d3893): sum=287
On Fri, Jan 11, 2013 at 2:57 PM, <solipsis@pitrou.net> wrote:
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 :) Cheers, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia
On Fri, Jan 11, 2013 at 5:08 PM, Christian Heimes <christian@python.org> wrote:
It has more issues. Coverity has sent me some complains, see attachment.
The second complaint seems a false positive; if self->extra is null then children is set to 0 and following code is not executed.
Am 11.01.2013 18:19, schrieb Andrea Griffini:
Yes, Coverity's results have lots of false positives. On the other hand it's able to detect hard to find resource leaks. You get used to the false positives and learn to appreciate the good stuff. :)
On Fri, Jan 11, 2013 at 8:08 AM, Christian Heimes <christian@python.org>wrote:
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
On 01/12/2013 02:46 PM, Eli Bendersky wrote:
The first report is legit, however. PyTuple_New(0) was called and its return value wasn't checked for NULL.
The author might have been relying on Python caching the empty tuple.
On Fri, Jan 11, 2013 at 5:08 PM, Christian Heimes <christian@python.org> wrote:
It has more issues. Coverity has sent me some complains, see attachment.
The second complaint seems a false positive; if self->extra is null then children is set to 0 and following code is not executed.
Am 11.01.2013 18:19, schrieb Andrea Griffini:
Yes, Coverity's results have lots of false positives. On the other hand it's able to detect hard to find resource leaks. You get used to the false positives and learn to appreciate the good stuff. :)
On Fri, Jan 11, 2013 at 8:08 AM, Christian Heimes <christian@python.org>wrote:
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
On 01/12/2013 02:46 PM, Eli Bendersky wrote:
The first report is legit, however. PyTuple_New(0) was called and its return value wasn't checked for NULL.
The author might have been relying on Python caching the empty tuple.
participants (5)
-
Andrea Griffini -
Christian Heimes -
Eli Bendersky -
Hrvoje Niksic -
Nick Coghlan