Moin folks, I recently upgraded to boost::python 1.48 and g++ 4.7 (fedora 17). This broke a project of mine as it crashes when passing an object with virtual inheritance from python back to C++ (e.g. during a method call). A minimal test case is attached. After nearly an hour of debugging in a single gdb session, I found that the value in the PyObject* itself does not change. When the value was first wrapped into a PyObject*, I noted down the address of that and did trial&error dereferencing until I was able to get the actual wrapped object: (gdb) disp (((PyUni::X11Window**)((long*)raw_result)[5])[2]) in the context of /usr/include/boost/python/object/make_instance.hpp:49 (PyUni::X11Window* being the object to be wrapped) The offset 5 was found by inspecting python's object.h, the 2 by guessing (at [5] we find an auto_ptr instance). I added a watchpoint to gdb on that location which did not trigger. Also, after the segfault, I inspected the same adress by replacing raw_result with the appropriate pointer (I noted down the address raw_result was pointing to before continuing from make_instance.hpp:49). Then I was able to reproduce the problem and pin it down to virtual inheritance and g++ -std=c++0x (c++11 does the same), so I built the attached test case. The archive contains (no tarbomb) a single cpp file and two methods to build it. For those for whom it works, there is the simple.Makefile, which relies on hardcoded paths. A CMakeLists.txt is provided for those with cmake and for whom the simple Makefile does not work. Another quick test with boost 1.49 did not fix the issue. ps: I hope this is not duped now, I accidentially used the wrong sender address first. -- Jonas