Hacktoberfest 2026: the issues maintainers tagged for October, open and beginner-friendly. Browse Hacktoberfest issues

Possible reference leak of the argument tuple in `FunctionCall()`

Open Beginner friendly
  • Is something wrong?
#534 0 comments 0 reactions 0 assignees View on GitHub

Maintainers usually reply within 1 day

Nobody has claimed this yet.

Assessment

Difficulty
2/5
Estimated time
1-3 hours
Newbie friendliness
76/100
Issue type
Bug
Clarity
Clearly specified
Activity status
Quiet
Tech stack
cpp, pandas, python
Domain
api

Research direction

Start in src/map.cpp at FunctionCall and review the CPython ownership rules for PyTuple_Pack and PyObject_CallObject. Verify the argument tuple is released on both successful and failed calls, while df_obj retains its existing ownership handling. Done means repeated DuckDBPyRelation.map() calls no longer leak the tuple or retain the input DataFrame.

Written by the indexing model from the issue text.

Description

needs triage
What happens?

FunctionCall() passes a newly created tuple directly to PyObject_CallObject():

File: src/map.cpp

Function: FunctionCall

auto *df_obj = PyObject_CallObject(function, PyTuple_Pack(1, in_df.ptr()));

PyTuple_Pack() returns a new reference, while PyObject_CallObject() does
not steal its args reference. Because the tuple is not stored in a local
variable, it is never passed to Py_DECREF().

As a result, every invocation leaks one tuple. The tuple also owns a reference
to in_df, so the input pandas DataFrame remains alive after FunctionCall()
returns. This occurs on both successful and failed calls.

The function is used during bind-time schema inference and query execution, so
the leak is reachable through ordinary DuckDBPyRelation.map() operations.

The handling of df_obj is unrelated and correct:

auto df = py::reinterpret_steal<py::object>(df_obj);

PyObject_CallObject() returns a new reference on success, which
reinterpret_steal() adopts.

To Reproduce

This issue can be confirmed directly from the reference ownership in
src/map.cpp.

In FunctionCall(), the argument tuple is created inline:

auto *df_obj = PyObject_CallObject(function, PyTuple_Pack(1, in_df.ptr()));

According to the CPython C API reference ownership rules:

  1. PyTuple_Pack() returns a new reference.
  2. PyObject_CallObject() does not steal the reference passed as args.
  3. The tuple pointer is not stored, so there is no subsequent
    Py_DECREF() for that new reference.
  4. The tuple therefore leaks on every call and retains its reference to
    in_df.

This issue is specific to the Python API and is not reproducible through plain
SQL in the DuckDB CLI.

OS:

x86_64

DuckDB Package Version:

latest version

Python Version:

3.12

Full Name:

Ksx

Affiliation:

SMU

What is the latest build you tested with? If possible, we recommend testing with the latest nightly build.

I have not tested with any build

Did you include all relevant data sets for reproducing the issue?

No - Other reason (please specify in the issue body)

Did you include all code required to reproduce the issue?
  • Yes, I have
Did you include all relevant configuration to reproduce the issue?
  • Yes, I have
Dominant language
Python
Stars
189
Forks
117
Avg merge
1d 58m
Merged PRs (30d)
15

Getting set up

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from duckdb/duckdb-python

All issues in duckdb/duckdb-python

Similar issues

More Python issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.