[C++-sig] GIL problems during destruction of a boost::python::wrapper

Jim Bosch talljimbo at gmail.com
Mon May 7 20:38:31 CEST 2012

On 05/07/2012 11:30 AM, Adam Preble wrote:
> I want to make sure I understand the repercussions.
> I understand if I were introducing C++ objects into the Python runtime as
> internal references that I would be inviting disaster if I delete them on
> the C++ side, but continue to use them on the Python side.  I don't think
> either of us were talking about that but I wanted to make sure I understood
> the boundaries here.
> Now on to shared pointer references.  I am utilizing shared pointers for
> this particular circumstance.  The object was created in Python and went
> out of scope.  If it weren't for the shared pointer, that would be the end
> of it, but the pointer was passed to my C++ runtime and retained in a data
> structure for future work.  This kept it alive--as I had desired.  When the
> object eventually leaves that structure and the refcount drops to zero, it
> moves on to destruction.
> It does look to me like Python is trying to take care of it since I
> immediately pile up through a bunch of Python runtime functions before I
> eventually hit my favorite "no such thread" GIL error in the runtime.

You may want to inspect the shared_ptr's deleter object, if you can 
figure out a way to do that (i.e. see if it is a 
boost::python::converter::shared_ptr_deleter).  It seems possible that 
you aren't (for some reason) getting a "native" C++ shared_ptr, but 
rather one that holds a Python object in its custom deleter, and 
invoking that Python thing's destructor is what's causing your problem.


More information about the Cplusplus-sig mailing list