@henryiii b/o release

@b-pass b/o internals expertise — The main objective of this PR is to undo the production code change under #5700, because it undermines the internals protections. PR #5700 introduced the only export of that kind (in struct_smart_holder.h).

This PR kind-of works: test_cross_module_rtti passes without that one-of-a-kind export of struct guarded_delete in struct_smart_holder.h ...

... but, I don't think this is a complete solution. I believe (but I'm not sure!) it's possible to construct other tests that still don't work, depending on

• which DSO created the shared_ptr member of struct smart_holder, and
• which DSO calls std::get_deleter<guarded_delete>.

Assuming that's true, we need something a little more involved. I have this super long ChatGPT conversation. Don't read, but JIC you want to poke in there:

• https://chatgpt.com/share/684f3583-15e4-8008-b89d-9aedc0787ccb

Near the (current) end of it, I asked it to write up the latest idea:

🧩 Proposal: Cross-DSO-safe retrieval of guarded_delete via function registry
In the pybind11 smart_holder machinery, we rely on:

std::get_deleter<guarded_delete>(vptr) to access the deleter inside a std::shared_ptr<void>.

This is fragile across DSOs, because:

RTTI (typeid(guarded_delete)) is DSO-local under -fvisibility=hidden + RTLD_LOCAL (pybind11’s default guidance)

So std::get_deleter<guarded_delete>() may fail even when the deleter is present

We already mitigate this (in this PR) by defining:

inline guarded_delete *get_guarded_delete(const std::shared_ptr<void> &);

and calling it from the same DSO that created the shared_ptr (when possible). But this still doesn’t fully solve the problem if a shared_ptr outlives the originating smart_holder or crosses ABI boundaries.

🧠 New idea: Keep a list of known get_guarded_delete() functions

At internals initialization:

internals.guarded_delete_fns.push_back(&get_guarded_delete);

Then, at call site:

guarded_delete *gd = nullptr;
for (auto fn : get_internals().guarded_delete_fns) {
    gd = fn(vptr);
    if (gd) break;
}

Because each DSO gets its own instantiation of get_guarded_delete() — with local RTTI — this allows us to scan all known RTTI domains for a match.

✅ Advantages

• Solves the RTTI identity problem without relying on ABI hacks

• No need to store deleter pointers in smart_holder (no 8-byte overhead)

• Preserves header-only and inline-only model of pybind11

• Only used in rare logic paths (e.g. disown / reclaim), so linear scan is acceptable

WDYT? I believe it's not difficult to implement, based on what you see here already.

@b-pass b/o internals expertise
WDYT? I believe it's not difficult to implement, based on what you see here already.

Seems reasonable to me. Whenever internals is fetched from the interpreter state dict it is potentially the first time internals is touched by a new module, so you need to check the list for the local guarded_deleter and possibly add it. This seems similar to check_internals_local_exception_translator() which also exists for libc++ (w/PyPy) RTTI reasons.

@b-pass Thanks a lot for the feedback. It was reassuring!

@henryiii I think the guarded_delete issue is resolved completely now. It's still a pretty simple PR.

This PR is changing PYBIND11_INTERNALS_VERSION. I want to take the opportunity to add in a few more cleanup things suggested by ChatGPT. I hope it'll be quick. I tagged the current state with find_memory_guarded_delete_complete, so we can easily backtrack.

@henryiii FYI, there is one more thing I hope to fix in this PR:

This needs to be replaced, so that the trampoline_self_life_support works reliably on macOS:

auto *self_life_support = dynamic_raw_ptr_cast_if_possible<trampoline_self_life_support>(src.get());

I have an idea I want to try, which involves adding a new member to struct type_info in internals.h.

I'll continue to work on this today.

@henryiii This is ready for review now. Developed and polished with the help of ChatGPT, fully reviewed by claude.ai (see links in PR description).

@b-pass It'd be great if you could take a look, too, although I'm no longer changing the internals struct directly.

Seems OK to me, though I'm not that familiar with the smart holder.

Seems OK to me, though I'm not that familiar with the smart holder.

Thank you @b-pass!