fixed refcount leakage when unboxing from cache #196
Merged
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
There is some leakage of refcounts caused in case of netref realization from cache:
Would show blowed up refcount.
On unboxing of a reply, if an oid already exists in cache, the same netref is given instead of a new one, causing that we would only one single netref object, that upon its destruction we'd only decref the remote by one, instead of by correct amount. fixed by adding an attribute of refcount on the netref and decref-ing accordingly in a loop.
Another option is to remove the caching altogether but I was unsure as to its importance.
One could also add another parameter for Connection's handle_del and to RefCountingColl.decref to decref not one by one. It could be added as default arguments, or as a different method, or change all other calls to be with a number. Not sure how it might affect others, so didn't do any of that(yet?).