I have been using boost python for some time now and recently upgraded
to boost_1_28_0 and gcc 3.0.4. I started getting a segmentation fault
when using a library with an overloaded constructor. In trying to
track down the source of the problem, I wrote a simple class with an
overloaded constructor and still get the seg fault.
Perhaps there is something wrong with code or the compile statement,
but I have been unable to find. it. So I've also included some
additional info below that may give someone a clue as to what is going
wrong.
Here is the python script which calls the simple class. The
second constructor crashes with a seg fault:
from TestSimple import Simple
# Default constructor OK
d1 = Simple()
print d1.get()
i = 1
d2 = Simple(i) # this line causes the seg fault
print d2.get()
----
Here is the code I use to make the module TestSimple:
#include
class SimpleClass {
public:
SimpleClass() : i(-1) {};
SimpleClass(int i) : i(i) {};
int get() const { return i; }
private:
const int i;
};
namespace python = boost::python;
BOOST_PYTHON_MODULE_INIT(TestSimple)
{
python::module_builder m( "TestSimple" );
python::class_builder<SimpleClass> simple(m, "Simple");
simple.def(python::constructor<>());
simple.def(python::constructor<int>());
simple.def(&SimpleClass::get, "get");
}
----
Here are the compile commands:
/usr/local/bin/g++ -I/usr/local/include/python2.1 -I/usr/local/include -ggdb -Wall -fPIC -ftemplate-depth-21 -c TestSimplePy.cpp
/usr/local/bin/g++ -shared -L/usr/local/lib -ggdb -Wall -fPIC -ftemplate-depth-21 TestSimplePy.o -o TestSimple.so -lboost_python
----
I run the script in a controlled environment with:
#!/bin/sh
export LD_LIBRARY_PATH=/usr/local/lib
/usr/local/bin/python2.1 ./testSimple.py
----
Here is the ldd for the TestSimple module:
mother:~/c/trade/test> ldd TestSimple.so
libboost_python.so.1.28.0 => /usr/local/lib/libboost_python.so.1.28.0 (0x40011000)
libstdc++.so.3 => /usr/local/lib/libstdc++.so.3 (0x40078000)
libm.so.6 => /lib/i686/libm.so.6 (0x40112000)
libgcc_s.so.1 => /usr/local/lib/libgcc_s.so.1 (0x40136000)
libc.so.6 => /lib/i686/libc.so.6 (0x4013e000)
libutil.so.1 => /lib/libutil.so.1 (0x4026e000)
/lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x80000000)
----
All the version info looks right -- python2.1 was compiled with the
same gcc (3.0.4) that the module was.
Thanks for any suggestions,
John Hunter
