[C++-sig] boost::python with virtual inheritance and g++ c++0x/11 (testcase attached)

Jonas Wielicki j.wielicki at sotecware.net
Mon May 14 09:51:01 CEST 2012


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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: bpcrash.tar.gz
Type: application/x-gzip
Size: 1247 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/cplusplus-sig/attachments/20120514/05797f9a/attachment.bin>


More information about the Cplusplus-sig mailing list