shared_ptr and GIL crash in boost::python (patch)
Hi everybody, I have been affected for years by the [1] bug: when shared_ptr for an object created in python is released in c++ in multi-threaded code, Python crashes -- because the shared_ptr_deleter does not lock the GIL before calling Python functions (as the object is destroyed). The referenced bug also contains a 2-line patch; several people report that they have to hand-patch boost::python for their production code. In my case, I can work around the bug by locking the GIL around those few places where this scenario can occur (they are fortunately relatively few in my case), without recompiling boost. I would like to ask someone to look at the patch if it is safe to be applied, and do so. It's been first identified 2 years ago. If I can do something on my part, or other reporters, I am willing to do whatever is necessary to expedite this. Opinions? Cheers, Václav [1] https://svn.boost.org/trac/boost/ticket/8290
On Wed, May 6, 2015 at 7:27 AM, Václav Šmilauer <eu@doxos.eu> wrote:
I would like to ask someone to look at the patch if it is safe to be applied, and do so. It's been first identified 2 years ago. If I can do something on my part, or other reporters, I am willing to do whatever is necessary to expedite this.
Opinions?
I guess it would be very prone to deadlocks in existing code. I, for one, would not welcome such an unexpected change of behavior in a minor version upgrade.
I would like to ask someone to look at the patch if it is safe to be applied, and do so. It's been first identified 2 years ago. If I can do something on my part, or other reporters, I am willing to do whatever is necessary to expedite this.
Opinions? I guess it would be very prone to deadlocks in existing code. I, for one, would not welcome such an unexpected change of behavior in a minor version upgrade. I'd suggest to turn this on via an optional argument to the bp::class_ template (or using a "global" variable settable at runtime for controlling this), would that be an option? While I see the possibility of deadlocks (in code which must be broken anyway), ATM what we get is segfaults and workarounds for those.
v.
participants (2)
-
Stefan Ring -
Václav Šmilauer