Description of problem:
I've been writing an experimental static analysis tool to detect bugs commonly occurring within C Python extension modules:
I ran the latest version of the tool (in git master; post 0.9) on
python-ZODB3-3.10.5-2.fc17.src.rpm, and it reports various errors.
You can see a list of errors here, triaged into categories (from most significant to least significant):
I've manually reviewed the issues reported by the tool.
Within the category "Unclassified errors" the 1 issue reported
src/BTrees/BucketTemplate.c:bucket_repr:returning pointer to deallocated memory
appears to be a true crasher, in that "r" gets DECREFed (and probably deallocated) in that path: it looks like the "return r" should have been a "return s".
Everything else I'm unsure about, and may well be false positives:
Within the category "Reference count too low" I can't tell if the first 3 of the 4 issues reported are true bugs or not, without more context. The 4th issue is the same one as above, but considering the case where the DECREF didn't lead to "r" being deallocated.
Within the category "Reference leaks" I can't if the 10 issues reported are true bugs or not without more context; sorry.
Within the category "Possible reference leaks": again, I can't tell whether or not the 8 issues reported are true bugs or not; sorry.
Within the category "Returning (PyObject*)NULL without setting an exception" the 33 issues reported may well be false-positives.
There may of course be other bugs in my checker tool.
Hope this is helpful; let me know if you need help reading the logs that the tool generates - I know that it could use some improvement.
Version-Release number of selected component (if applicable):
gcc-python-plugin post-0.9 git d578ee0e46d93647d0f94502784f890c38139d60 running the checker in an *f16* chroot
(In reply to comment #0)
> Within the category "Unclassified errors" the 1 issue reported
> src/BTrees/BucketTemplate.c:bucket_repr:returning pointer to deallocated
> appears to be a true crasher, in that "r" gets DECREFed (and probably
> deallocated) in that path: it looks like the "return r" should have been a
> "return s".
Reported upstream at https://bugs.launchpad.net/zodb/+bug/972533.
That code path is taken when s is NULL. It appears to me that it is the Py_DECREF(r) on line 1745 that is wrong, and that the code author really intended to return r. (I would argue that that isn't a good idea, because now callers have to be prepared to receive the expected "k(v)" form, the "v" form meaning that we couldn't allocate enough memory for the first form, and NULL meaning that we otherwise couldn't allocate enough memory. I don't see how the second form is better than the third.)
Thanks for the analysis!
This bug appears to have been reported against 'rawhide' during the Fedora 19 development cycle.
Changing version to '19'.
(As we did not run this process for some time, it could affect also pre-Fedora 19 development
cycle bugs. We are very sorry. It will help us with cleanup during Fedora 19 End Of Life. Thank you.)
More information and reason for this action is here:
python-ZODB3-3.11.0-1.fc21 has been submitted as an update for Fedora 21.
* should fix your issue,
* was pushed to the Fedora 21 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing python-ZODB3-3.11.0-1.fc21'
as soon as you are able to.
Please go to the following url:
then log in and leave karma (feedback).
python-ZODB3-3.11.0-1.fc21 has been pushed to the Fedora 21 stable repository. If problems still persist, please make note of it in this bug report.