seberg opened a new issue, #39599: URL: https://github.com/apache/arrow/issues/39599
### Describe the bug, including details regarding any error messages, version, and platform. I was running valgrind on some code which uses pyarrow as a dependency. This was leaking NumPy dtypes. Now the issue could be downstream, but this line (and similar ones) to me look like they will leak the NumPy descriptors: https://github.com/apache/arrow/blob/7e703aae55c150c3556fe0dc972b575460cfb86b/python/pyarrow/src/arrow/python/python_to_arrow.cc#L390 I don't see how the NumPy descriptor would ever be decref'd. The fix would seem to first assign it to an `ownedRef`? For some dtypes that may just leak a reference, but not for all (reference leak being only a nuisance when debugging references). This like not often a problem deal in practice, although it could imagine it being a nuisance some in some very long running code. I am not planning on running such leaks checks regularly right now, so it shouldn't affect me really. <details> <summary> The reported origin of the leaked memory is: </summary> ``` ==1392== 136 (+136) (96 (+96) direct, 40 (+40) indirect) bytes in 1 (+1) blocks are definitely lost in new loss record 146,562 of 186,418 ==1392== at 0x4849724: malloc (vg_replace_malloc.c:442) ==1392== by 0x23186A: UnknownInlinedFun (obmalloc.c:685) ==1392== by 0x23186A: _PyObject_New (object.c:183) ==1392== by 0xA69EA92: PyArray_DescrNew (in .../python3.10/site-packages/numpy/core/_multiarray_umath.cpython-310-x86_64-linux-gnu.so) ==1392== by 0xA69EBEA: PyArray_DescrNewFromType (in .../python3.10/site-packages/numpy/core/_multiarray_umath.cpython-310-x86_64-linux-gnu.so) ==1392== by 0xA7461A9: PyArray_DescrFromScalar.part.0 (in .../python3.10/site-packages/numpy/core/_multiarray_umath.cpython-310-x86_64-linux-gnu.so) ==1392== by 0x1692324F: arrow::py::(anonymous namespace)::PyPrimitiveConverter<arrow::TimestampType, void>::Append(_object*) (in .../python3.10/site-packages/pyarrow/libarrow_python.so) ==1392== by 0x16901CF8: arrow::Status arrow::py::internal::VisitSequenceGeneric<arrow::py::internal::VisitSequence<arrow::py::(anonymous namespace)::PyConverter::Extend(_object*, long, long)::{lambda(_object*, bool*)#1}>(_object*, long, arrow::py::(anonymous namespace)::PyConverter::Extend(_object*, long, long)::{lambda(_object*, bool*)#1}&&)::{lambda(_object*, long, bool*)#1}>(_object*, long, arrow::py::(anonymous namespace)::PyConverter::Extend(_object*, long, long)::{lambda(_object*, bool*)#1}&&) (in .../python3.10/site-packages/pyarrow/libarrow_python.so) ==1392== by 0x16902034: arrow::py::(anonymous namespace)::PyConverter::Extend(_object*, long, long) (in .../python3.10/site-packages/pyarrow/libarrow_python.so) ==1392== by 0x16928A0B: arrow::py::ConvertPySequence(_object*, _object*, arrow::py::PyConversionOptions, arrow::MemoryPool*) (in .../python3.10/site-packages/pyarrow/libarrow_python.so) ==1392== by 0x16686BD1: __pyx_pw_7pyarrow_3lib_163scalar(_object*, _object* const*, long, _object*) (in .../python3.10/site-packages/pyarrow/lib.cpython-310-x86_64-linux-gnu.so) ==1392== by 0x16550B54: __Pyx_CyFunction_CallAsMethod(_object*, _object*, _object*) (in .../python3.10/site-packages/pyarrow/lib.cpython-310-x86_64-linux-gnu.so) ==1392== by 0x9F91098E: __Pyx_PyObject_Call(_object*, _object*, _object*) (in .../python3.10/site-packages/cudf/_lib/scalar.cpython-310-x86_64-linux-gnu.so) ``` ### Component(s) Python -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
