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);

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.

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?

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.

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.

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.

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.

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.

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