[BUG]: Crash due to invalid free during cleanup, if any enum is registerd, due to attempting to `free` a string literal

[adalisk-emikhaylov]

EDIT (2026-03-27): Related: #5991, #6010. Root cause: def_property_static calls process_attributes::init on already-initialized function records (after initialize_generic's strdup loop has run), so the "self" arg added by append_self_arg_if_needed remains a string literal. destruct() then calls free() on that literal. Introduced by #5486.

---

Required prerequisites

• Make sure you've read the documentation. Your issue may be addressed there.
• Search the issue tracker and Discussions to verify that this hasn't already been reported. +1 or comment there if it has.
• Consider asking first in the Gitter chat room or in a Discussion.

What version (or hash if on master) of pybind11 are you using?

4f81a12

Problem description

Importing this and then exiting Python causes a crash at

pybind11/include/pybind11/pybind11.h

Line 824 in 4f81a12

std::free(const_cast<char *>(arg.name));

arg.name is "self", and it appears to be a string literal instead of a malloced string.

Said literal is assigned to it at

pybind11/include/pybind11/attr.h

Line 494 in 4f81a12

r->args.emplace_back("self", nullptr, handle(), /*convert=*/true, /*none=*/false);

Editing that function to malloc the string seems to fix the crash.

I've bisected this, the offending commit is 1b7aa0b

---

I'm not sure if it matters, but I'm on CPython 3.10 on Ubuntu 22.04.

Reproducible example code

#include <pybind11/pybind11.h>

enum E {};

PYBIND11_MODULE(example, m)
{
    pybind11::enum_<E> e(m, "E");
}

Is this a regression? Put the last known working version here if it is.

15d9dae

[adalisk-emikhaylov]

@timohl Friendly ping, seems to be introduced by your commit.

[timohl]

Can you also share the python code that causes the crash?
Your reproducible code looks so minimal, that I think there must be something else going on.
My commit is a year old and this looks like a basic enum binding, so I think many others would have noticed this before.

Btw, py::enum_ is deprecated, so if you are looking for a quick replacement, try py::native_enum.

[adalisk-emikhaylov]

Just import example and then exiting Python. I just tested this on a different OS (this time Arch), and it reproduces here too.

Paste the code into 1.cpp, clone pybind into the current directory, and run

g++ 1.cpp `python3-config --libs --cflags` -shared -o example.so -fPIC -Ipybind11/include
python3 -c 'import example'

This gives me

free(): invalid pointer
Aborted                    (core dumped) python3 -c 'import example'

My commit is a year old

Oh, I didn't realize it's 2026 already. 🙂

[HMRWork42]

I have been trying to get at the cause of a pybind11 2.x to 3.x regression ( skia-python/skia-python#350 ) of CI pytest segfaulting at the end, and seems to arrive at the same line. However, my valgrind trace is 👍

==2980== Invalid free() / delete / delete[] / realloc()
==2980==    at 0x4847E43: free (vg_replace_malloc.c:990)
==2980==    by 0x5A0E488: pybind11::cpp_function::destruct(pybind11::detail::function_record*, bool) (pybind11.h:824)
==2980==    by 0x5A0E375: pybind11::detail::function_record_PyTypeObject_methods::tp_dealloc_impl(_object*) (pybind11.h:1325)
==2980==    by 0x49AD620: _Py_Dealloc (object.c:3072)
==2980==    by 0x49C82BC: Py_DECREF (refcount.h:421)
==2980==    by 0x49C82BC: Py_XDECREF (refcount.h:514)
==2980==    by 0x49C82BC: Py_XDECREF (refcount.h:511)
==2980==    by 0x49C82BC: meth_dealloc.lto_priv.0 (methodobject.c:179)
==2980==    by 0x49AD620: _Py_Dealloc (object.c:3072)
==2980==    by 0x4ACB77A: property_dealloc.lto_priv.0 (descrobject.c:1638)
==2980==    by 0x49C1631: _Py_Dealloc (object.c:3072)
==2980==    by 0x49C1631: Py_DECREF (refcount.h:421)
==2980==    by 0x49C1631: Py_XDECREF (refcount.h:514)
==2980==    by 0x49C1631: dictkeys_decref.part.0.constprop.0 (dictobject.c:463)
==2980==    by 0x4A7A739: PyDict_Clear (dictobject.c:2932)
==2980==    by 0x4A7A739: type_clear.lto_priv.0 (typeobject.c:6620)
==2980==    by 0x4A79F56: delete_garbage (gc.c:1141)
==2980==    by 0x4A79F56: gc_collect_region.lto_priv.0 (gc.c:1761)
==2980==    by 0x4AC84C1: gc_collect_full (gc.c:1681)
==2980==    by 0x4AC84C1: _PyGC_Collect (gc.c:2045)
==2980==    by 0x4AEAD2A: _Py_Finalize.constprop.0 (pylifecycle.c:2144)
==2980==  Address 0x6d55c3e is in a r-- mapped file /home/HMRWork42/.local/lib/python3.14/site-packages/skia.cpython-314-x86_64-linux-gnu.so segment

And I am suspecting e7e5d6e which touches pybind11.h:1325 in the call stack. "Make wrapped C++ functions pickleable" (#5580)

What's your next frame in the callstack?

[HMRWork42]

In skia-python we do a lot of enums in various files, and I seems to have isolated it to a particular file (which is about 1300 lines long...) , so the idea about pickleable functions seems more likely for me. Anyway, I should do my own issue....

[HMRWork42]

I am wondering about the interaction of py::enum_ with py::arithmetic() . The latter involves py::self.

[HMRWork42]

Filed my own #5991 , but I am thinking it seems related .

[HMRWork42]

There is another string literal "self" in the same file, for processing py::arg_v - and we do use those in skia-python recently (see #5994 ) , so I am looking to see which of them is causing the double free's.

[HMRWork42]

@timohl I think I'd confirm this bug, although I have filed my own (#5991). In skia-python, we have over a hundred enum's, and at least a quarter of those have py::arithematics(). But I have narrowed the #5991 crash to these two enums:

py::enum_<VkFormat>(m, "VkFormat", py::arithmetic())
    .export_values();

py::implicitly_convertible<int, VkFormat>();

py::enum_<VkImageLayout>(m, "VkImageLayout", py::arithmetic())
    .export_values();

py::implicitly_convertible<int, VkImageLayout>();

We were being a bit lazy: there are 300+ values for one, and 40+ for the other, and not all of them useful/commonly used, so we have the implicitly convertible to convert arbitrary new values for those rarely used APIs. If I fill in the 300+ and 40+ values explicitly, remove the py::arithmetic() and py::implicitly_convertible constructs, the segfault goes away.

[HMRWork42]

I think that particular code path needs most of these 3 to 4 conditions to trigger:

(a) enum (probably a bare one without a doc string etc), (b) not having any .value() defined (c) relying on py::implicitly_convertible for arbitrary value for it to be useful , (d) having py::arithmetic() (making it a minimal class with some implied methods?)