[C++-sig] Assert's in boost.python when instanciating class

David Abrahams dave at boost-consulting.com
Thu May 8 13:06:19 CEST 2003

Sean Dunn <sean_dunn1 at yahoo.com> writes:

> I've been having troubles getting a very simple class to work in Python
> after extending C++ code using boost.python.
> system:
> Win2k
> VC6 sp5
> boost.python 1.30.0 built using bjam, using pydebug dynamic link
> library
> python 2.2.2 debug shell
> // C++ code
> #include <boost/python.hpp>
> using namespace boost::python;
> struct SimpleTest
> {
> 	int val;
> };
> class_<SimpleTest>("SimpleTest")
> 	.def_readwrite("val",  &SimpleTest::val)
> ;

And how are you building your extension module?  Did you try doing it
as described here:

> Upon loading this in python, I hit a failed assert in class.cpp:
> # Python output
> Adding parser accelerators ...
> Done.
> Python 2.2.2 (#37, Apr 29 2003, 17:46:46) [MSC 32 bit (Intel)] on win32
> Type "help", "copyright", "credits" or "license" for more information.
>>>> import payamodule
> [8162 refs]
>>>> t = payamodule.SimpleTest()
> Assertion failed: self_->ob_type->ob_type == &class_metatype_object,
> file ../src
> /object\class.cpp, line 481
> // from the debugger
> self_->ob_type->ob_type == 0x1e194858
> &class_metatype_object == 0x00895b80
> So, the problem here seems to be that this maybe should be
> assert(self_->ob_type->ob_type == class_metatype_object.ob_type);

No, the original assertion is correct.  Since class_metatype_object's
type is simply 'type', as is the type of most other types, your
version of the assertion tests almost nothing.

When an assert fails, responding with "maybe the assertion's wrong and
I should change it so that it shuts up" will usually lead you down a
false path, as it has here.

> Is this a manifestation of using the debug libraries? 

Quite possibly. If you didn't build your extension module with the
same debug options, object layout could be different.  That might
mean that the ob_type field of the `self_' object falls right where
another PyObject* is located in your object.  That's why I am
suggesting that you follow the build instructions above first.

> There is an instance of actual running code in the non-debug case
> inside class.cpp:264,find_instance_impl().

That sentence is incomprehensible to me.  Could you elaborate?

> I had previously tracked down a bug to this line in a previous test
> where I was calling a simple method that would return an integer
> constant. It gave me a TypeError: bad argument type for built-in
> operation.
> I made the above change, and although it passes the asserts, and I can
> read "val", it crashes when I try to set "val". 

Asserts are there to stop the code when something goes wrong *before*
a crash occurs.

> An expected PyObject* seems to be garbage (a value of 0x00000002
> instead of a sane pointer).
> I'll give the normal disclaimer that I've been using boost.python for
> about 24 hours now, and I really do know nothing.

Probably a bad time to start disabling its internal checks, my man!

Dave Abrahams
Boost Consulting

More information about the Cplusplus-sig mailing list