Fix reference counting leak in nrnpy_restore_savestate_.
#3212
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Codecov ReportAll modified and coverable lines are covered by tests ✅
Additional details and impacted files@@ Coverage Diff @@
## master #3212 +/- ##
=======================================
Coverage 67.07% 67.07%
=======================================
Files 569 569
Lines 111205 111205
=======================================
Hits 74593 74593
Misses 36612 36612 ☔ View full report in Codecov by Sentry. |
This comment has been minimized.
This comment has been minimized.
|
✔️ 5b9aa6c -> Azure artifacts URL |
The facts:
1. `PyByteArray_FromStringAndSize` returns a "new reference" [1].
2. `PyObject_CallObject` returns a "new reference" [2].
3. `PyTuple_SetItem` steals `py_data` [3].
Let's analyse `py_data` first:
* After `PyByteArray_FromStringAndSize` it's at `+1` (meaning 1
unaccounted INCREF).
* After `Py_INCREF(py_data)` it's at `+2`.
* By calling `PyTuple_SetItem` we know 1 DECREF will happen, because
it steals `py_data`. The reference count of `py_data` is at `+1`.
Therefore, there's one INCREF for which we can't pair up with a DECREF.
Let's move on to `result`, since it's a "new reference" we're
responsible for calling `DECREF`.
[1]: https://docs.python.org/3/c-api/bytearray.html#c.PyByteArray_FromStringAndSize
[2]: https://docs.python.org/3/c-api/call.html#c.PyObject_CallObject
[3]: https://docs.python.org/3/c-api/tuple.html#c.PyTuple_SetItem
1uc
force-pushed
the
1uc/fix-reference-leak-restore
branch
from
5b9aa6c
to
ffeee68
Compare
|
|
✔️ ffeee68 -> Azure artifacts URL |
matz-e
approved these changes
Nov 15, 2024
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
The facts:
PyByteArray_FromStringAndSizereturns a "new reference" 1.PyObject_CallObjectreturns a "new reference" 2.PyTuple_SetItemstealspy_data3.I like thinking in terms of "relative" or "local" reference counts, by which I mean the number of INCREFs that we can't pair up with a DECREF. Therefore,
+1is one INCREF for which we don't have an associated DECREF. It doesn't mean that the reference count is1.Let's analyse
py_datafirst:PyByteArray_FromStringAndSizeit's at+1(meaning 1 unaccounted INCREF).Py_INCREF(py_data)it's at+2.PyTuple_SetItemwe know 1 DECREF will happen, because it stealspy_data. The reference count ofpy_datais at+1.Therefore, there's one INCREF which we can't pair up with a DECREF. Consequently, I believe this code leaks
py_data.The analysis of this commit is:
nb::stealthe new reference and are at+0(the dtor will DECREF).PyTuple_SetItem(..., py_data.release().ptr())we hand over our reference and are still at+0(because from now on the dtor won't DECREF anymore).Let's move on to
result, since it's a "new reference" we're responsible for callingDECREF. Wenb::stealit and are immediately at+0, because the dtor will call DECREF.