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 leaking attributes in java PyObject. #539

Merged

Conversation

bsteffensmeier
Copy link
Member

This is a fix for the problem identified in #538.

@CHanzyLazer
Copy link

CHanzyLazer commented Jun 18, 2024

Wait, it seems necessary to check that pyAttr is not NULL before proceeding with Py_DECREF(pyAttr);, that is:

    if (pyAttr) {
        Py_DECREF(pyAttr);
    }

or

    Py_XDECREF(pyAttr);

@bsteffensmeier
Copy link
Member Author

Wait, it seems necessary to check that pyAttr is not NULL before proceeding with Py_DECREF(pyAttr);, that is:

jobject_as_PyObject() only returns null when the python exception is set so the check for process_py_exception() ensures that pyAttr is not null at that point.

@CHanzyLazer
Copy link

Wait, it seems necessary to check that pyAttr is not NULL before proceeding with Py_DECREF(pyAttr);, that is:

jobject_as_PyObject() only returns null when the python exception is set so the check for process_py_exception() ensures that pyAttr is not null at that point.

Ok, so Py_XDECREF(pyAttr); should be under the EXIT: just like it is in Java_jep_python_PyObject_getAttr?

@bsteffensmeier
Copy link
Member Author

Wait, it seems necessary to check that pyAttr is not NULL before proceeding with Py_DECREF(pyAttr);, that is:

jobject_as_PyObject() only returns null when the python exception is set so the check for process_py_exception() ensures that pyAttr is not null at that point.

Ok, so Py_XDECREF(pyAttr); should be under the EXIT: just like it is in Java_jep_python_PyObject_getAttr?

Anytime the python exception is set from jobject_as_PyObject() it will return null so in the case it does not hit the new DECREF it will be null and does not need a DECREF.

@CHanzyLazer
Copy link

Okay, I'm not very familiar with Python's C interface. I was just considering whether we need to maintain consistency with the rest of the code, such as Java_jep_python_PyObject_getAttr and Java_jep_python_PyObject_equals.

@bsteffensmeier
Copy link
Member Author

Java_jep_python_PyObject_equals

Okay, I'm not very familiar with Python's C interface. I was just considering whether we need to maintain consistency with the rest of the code, such as Java_jep_python_PyObject_getAttr and Java_jep_python_PyObject_equals.

It looks to me like Java_jep_python_PyObject_equals is also leaking references. I will try to find some time to test and get a fix in as part of this patch, thanks for checking.

@ndjensen
Copy link
Member

ndjensen commented Jul 3, 2024

I agree the equals method is also leaking, it's leaking otherPyObject. Looks like I introduced both these leaks in Jep 3.8 when I reworked and improved the functionality of PyObject. I am glad this was found and reported. Today I code-reviewed the other methods in that file and they look ok with regards to memory.

@bsteffensmeier
Copy link
Member Author

I finally had some time to look at this closely. I added a test to see if equals is leaking and found it is not leaking, I just didn't notice the Py_XDECREF in the EXIT block, even though that is what @CHanzyLazer was trying to point out. I agree after reviewing the other functions in that file Py_XDECREF is the style there so I went ahead and switched the new DECREF over for consistency.

@ndjensen
Copy link
Member

Good catch. I'm good with this going in.

@bsteffensmeier bsteffensmeier merged commit 35380cf into ninia:dev_4.2 Jul 29, 2024
1 check passed
@bsteffensmeier bsteffensmeier deleted the fix-leaking-pyobject-attr branch October 22, 2024 01:02
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.

3 participants