[C++-sig] shared_ptr and GIL crash in boost::python (patch)

[Václav Šmilauer]

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

[Stefan Ring]

Post by Václav Šmilauer
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.

[Václav Šmilauer]

Post by Stefan Ring

Post by Václav Šmilauer
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.