The algorithm-specific object constructors in the "_hashlib" module ("_hashlib.md5", "_hashlib.sha1", etc.) cause a leak by incrementing the reference count of their string argument. ("_hashlib.new" does not suffer from the issue.)
"PyBuffer_Release()" is missing in the Fedora-specific function "implement_specific_EVP_new()". Patch is attached.
This code reproduces the bug:
s = "some string"
_hashlib.md5(s) # increments ref count for s
_hashlib.sha1(s) # increments ref count for s
print sys.getrefcount(s) # prints 4, should be 2
Created attachment 595043 [details]
fix for the issue
thanks for the report. Just to clarify:
1) Do you mean functions openssl_md5, resp openssl_sha1?
2) If I understand it correctly, what happens is, that during "PyArg_ParseTupleAndKeywords" execution, the "view" buffer gets filled (somewhere down the "convertsimple" method, I think the line is 920 in getattr.c) and therefore raises the reference count to the string. Is this right?
3) Looking at your patch, it seems that the first hunk is the same as in your report at , which is not in Fedora yet; the second hunk is the actual fix of the Fedora specific function.
All in all, I see no problem with your patch and I think it's safe to apply. Could you please confirm my above observations?
1) Yes, you are right.
2) It might be line 837 in getattr.c, but yes, this is my understanding of what happens as well.
3) You are correct. (Sorry, I forgot to link to that other issue.)
(In reply to comment #3)
> 1) Yes, you are right.
> 2) It might be line 837 in getattr.c, but yes, this is my understanding of
> what happens as well.
> 3) You are correct. (Sorry, I forgot to link to that other issue.)
Thank for the clarification. As I am just a comaintainer, I would like Dave Malcolm to confirm fixing this first. If he doesn't show up here, I'll email him in few days.
Again, thanks for the report.
Good catch - thanks! The leak is in the general path within implement_specific_EVP_new() and the error handling path in EVP_new().
Patch looks correct, feel free to apply to master and to the other live branches of "python".
I don't *think* the bug is present in the equivalent python3 code, as I had to tweak things during the port, and I think I fixed it then.
python-2.7.3-7.2.fc17 has been submitted as an update for Fedora 17.
python-2.7.3-4.fc16 has been submitted as an update for Fedora 16.
* should fix your issue,
* was pushed to the Fedora 16 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing python-2.7.3-4.fc16'
as soon as you are able to.
Please go to the following url:
then log in and leave karma (feedback).
python-2.7.3-7.2.fc17 has been pushed to the Fedora 17 stable repository. If problems still persist, please make note of it in this bug report.
python-2.7.3-4.fc16 has been pushed to the Fedora 16 stable repository. If problems still persist, please make note of it in this bug report.