Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

fix and test some memory leaks #196

Merged
merged 2 commits into from
Sep 28, 2015
Merged

Conversation

slingamn
Copy link
Contributor

I was working on a new implementation of #75 / #102. I found what I believe are memory leaks, mostly associated with key normalization. For example, _key_normalized_obj was not consistent (across its different conditional branches) as to whether it created a new reference or not. More generally, if a PyObject * key can be overwritten by a normalized or prefixed key, any owned (as opposed to borrowed) references to the original key must be cleaned up.

I've added tests for these issues. The tests pass in this branch, but do not pass in master: https://gist.github.com/slingamn/3b6cec10c1f12f0dbe1b

I think it's possible that there are more leaks:

  1. This testing approach can't identify leaks of intermediate values, only in arguments to public functions
  2. Most of the error recovery code is not covered

but I think this should cover the leaks that the typical user is most likely to encounter.

Thanks for your time!

@kenrobbins
Copy link

I'm just a user of pylibmc, but thanks for this. I discovered the memory leak in _key_normalized_obj as well. Hope this can get merged soon.

lericson added a commit that referenced this pull request Sep 28, 2015
fix and test some memory leaks
@lericson lericson merged commit 3839cbd into lericson:master Sep 28, 2015
@lericson
Copy link
Owner

Exciting stuff, very nice. I'm a little anxious about the amount of changes, so let's hope your approach is solid. It seems better to test ref counts than not though. But extensive testing will be needed. The way I've isolated memory leaks previously is to just run code in a loop and see if the process starts eating memory.

@aconrad
Copy link

aconrad commented Sep 29, 2015

Any ETA for a new release containing this fix?

@slingamn
Copy link
Contributor Author

Thanks!

Yeah, testing this is tricky. I think in order to see a blowup in memory consumption from the issues in this patch, it would be necessary to use distinct keys for each iteration of the loop --- otherwise, only an O(1) amount of objects will become uncollectable.

@slingamn slingamn deleted the memory_leaks.1 branch October 1, 2015 09:48
@jkchin
Copy link

jkchin commented Mar 30, 2016

ping, any update on when this fix will come out?

@lericson
Copy link
Owner

Well, the originating branch has been closed so I'm not sure how I can move forward with this.

@kenrobbins
Copy link

@lericson Not sure what you mean. It looks like it's merged into master. I believe @jkchin was asking when a build would be created with this change. It appears it is in 1.5.1 released 21 March though I didn't see anything in the changelog.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants