[BUG]: ABI incompatibility between 2.9.2 and 2.10

[whophil]

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.

Problem description

I have two pybind11 extension libraries, A and B, where B uses classes from A.

My library A was compiled with pybind11 2.9 and B was compiled with pybind11 2.10. They both declare the same PYBIND11_INTERNALS_VERSION of 4, yet they do not seem to work with each other. They do work if I compile both A and B with pybind11 2.9.

Based on discussion with @henryiii on Gitter, these should be ABI compatible.

Reproducible example code

N/A

[henryiii]

From Gitter:

pybind11 2.10 issue

ocp is a package on conda-forge consisting collection of pybind11 extensions for OpenCascade.

I have another closed source project, Project B, which contains its own pybind11 code, using classes from ocp.

In the past, this all worked fine so long as both projects were built using the same compiler version and pybind11-abiversion, using those from conda-forge-pinning.

Recently, however, the build for Project B started breaking. This seems to be related to the release of pybind11 version 2.10. If I build Project B with pybind11=2.10 the two extension libraries can't talk to each other. If I pin the build of Project B to pybind11=2.9.*, which is the version that the ocp package was built with, then everything works fine.

I thought that this is what thepybind11-abi global pin was supposed to solve. Is it possible that pybind11-abi is not sufficient for this use case? If so, should pybind11 itself be a global pin as well?

[rwgk]

We need something to work off from, ideally a reproducer, but at least a careful description of the steps and symptoms to reproduce. I think I've seen all changes between 2.9 and 2.10, but I wouldn't know how we may have accidentally broken ABI compatibility. There is also a chance that it only worked by luck before, and some small perturbation makes it fall over now. ABI compatibility is very tricky to be certain about, especially because we don't even have any directly related unit testing (I believe it's impractical).

[whophil]

Thanks @rwgk . I can put together an example using ocp, but it's a massive project so I don't know if it will be the best candidate for debugging.

[rwgk]

Thanks @rwgk . I can put together an example using ocp, but it's a massive project so I don't know if it will be the best candidate for debugging.

Sorry I sure won't have time to debug this.

I'm just hoping for some concrete clues. If that doesn't lead to easy insights, I'd lean toward bumping the internals version. We are holding back an improvement for some time already, behind an ifdef. If we now have an unintentional break, I'd say let's make that a trigger for a version bump rather than spending time on looking back.

Sooner or later ABI breaks are unavoidable.

[henryiii]

@whophil Could you check this again with current master? #4100 might be related.

[henryiii]

I can put together an example using ocp, but it's a massive project so I don't know if it will be the best candidate for debugging.

Honestly, even if you have a massive project, as long as it can compile in finite time, and can be compared with live checkouts of pybind11, I could probably fire and forget a git bisect and detect where it broke. Currently it's a handwavy "something broke in my library".

[whophil]

Thanks @henryiii - I guess you mean that I can build Project A with pybind11 2.9.2, and Project B with pybind11 on current master and see if the ABI compatibility is resolved?

[henryiii]

Yes. If it's not, if you could provide an ocp example I can test, I can run a got bisect and see where it started failing.

[rwgk]

I have a suspicion that PR #1895 could be the reason. When I merged it I was thinking we're safe, but in the meantime I did some unrelated work (#4043, #4050) and what I learned made me think maybe not.

That PR cannot easily be rolled back, even locally (git revert a05bc3d2359d12840ef2329d68f613f1a7df9c5d has merge conflicts). It's definitely impossible to roll back on the smart_holder branch, because the original error_already_set is too unsafe for Google's production environment.

I wanted to let you know this suspicion before you spend time on a reproducer.

I really want to know, too, what the root cause is, but then we will have the question:

• backtrack
• patch
• increment the ABI version

What is better overall? I think backtracking could be extremely disruptive. Patching will take effort to figure out & validate. Incrementing the ABI version, after many years, is a clean, simple move.

The fact that nobody has given us a reproducer suggests to me that ABI compatibility is important, but not actually critical.

Ultimately: We don't have any unit testing for ABI compatibility. That would be a useful contribution to make for someone with a vested interest, protecting us from accidents in the future.