Skip to content

Lifecycle problem with UDF functions #530

Description

@extremeCrazyCoder

What happens?

There seems to be some sort of lifecycle problem with registered udf Functions. For now this can be easily worked around by kepping a strong reference to that function somewhere in python.

If this is not done you risk getting a sigsev when executing it.

I am not quite sure if this behavior should be allowed at all. So a possible fix for this might be to remove all udf functions that were registered on that cursor / connection when cleaning / closing that connection.

To Reproduce

This is the minimum that is needed to get a reliable segfault (at least on my machine - linux with duckdb wheel 1.5.4).

import duckdb

con = duckdb.connect()
cur = con.cursor()
cur.create_function("myf", lambda x: f"got:{x}", ["VARCHAR"], "VARCHAR")
del cur
print("calling myf via con after cursor teardown...", flush=True)
result = con.sql("SELECT myf('b')").fetchall()   # dangling raw PyObject* -> SIGSEGV

# Not reached when the bug is present.
print("result:", result)

Ouput:

calling myf via con after cursor teardown...
Speicherzugriffsfehler (Speicherabzug geschrieben)

OS:

linux

DuckDB Package Version:

1.5.4

Python Version:

3.14

Full Name:

Affiliation:

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

I have tested with a stable release

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

Yes

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

Metadata

Metadata

Assignees

No one assigned

    Type

    No type

    Fields

    No fields configured for issues without a type.

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions