Don't decref PyBytesObject before formatting an error with it #1299
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.
Some C functions call Py_XDECREF on a PyBytesObject (representing a string), and then they pass a pointer within that object to
Error_set_str
. This causes the error message to appear corrupted if garbage collection occurs at just the right time.For example,
init_file_backend
does something like this:The issue is that PyBytes_AsString returns a pointer within
py_path
– it doesn't copy the string. So, Py_XDECREF may causepy_path
to be collected at any time, possibly garbling the value ofpath
.When my application invokes Repository.__init__ with a path that does not exist, such as "/tmp/submoroot/submosub", then pygit2 may ultimately raise this:
Note that the path in the error message (
dtmp/subdtmp/subdtmp/subdtmp/su
) is garbled.This PR fixes this by calling Py_XDECREF(py_path) after the error message is built. I'm not sure how to distill this into a unit test because the GC needs to kick in at just the right time to exhibit the faulty behavior.