[C++-sig] Re: Problem: boost_python 1.31 (release) causes huge memory allocation

David Abrahams dave at boost-consulting.com
Thu Jul 1 18:56:59 CEST 2004

Wirawan Purwanto <wirawan at camelot.physics.wm.edu> writes:

> Hi,
> Just a compliment, first: I am very new to boost::python library. I'm
> really impressed at the ease of use of that library. I have an
> existing code that I want to "manipulate" via python, and it only took
> me a few tests to get the simple interface up and running!


> I built my shared object (HubbardGP.so) using make(1) for a stupid
> reason: I still don't understand completely bjam's quirks. I linked
> against the "release" version of libboost_python-gcc.so, in this way:
> $ g++ -L/usr/local/lib -fPIC -Wall -ftemplate-depth-100 \
>                 -g -O0 -DDEBUG \
>                 -DBOOST_PYTHON_DYNAMIC_LIB \
>                 -DTBH_NDIM=1 -DTBH_USE_FFTW3 -D__section__=1 \
>                 -Isrc -Isrc/cp.inc \
>                 -I/usr/local/boost-1.31.0/include/boost-1_31 \
>                 -I/usr/include/python2.3 \
>                 -c src/test-lattice-params.cpp -o objs/HubbardGP.o
> $ g++ -L/usr/local/lib -shared -Wall -static-libgcc \
>                 -llapack -lcblas -lf77blas -latlas -lfftw3 \
>                 -lg2c \
>                 -lboost_python-gcc \
>                 -L/usr/local/boost-1.31.0/lib \
>                 objs/HubbardGP.o -o HubbardGP.so
> Do you see the difference? My code was compiled using DEBUG switch
> (and -O0), but then linked to the RELEASE variant of the boost::python
> lib.
> QUESTION: is this an acceptable practice? I'm wondering if the DEBUG
> code must always be linked against the DEBUG boost::python lib and
> vice versa.

The preprocessor symbol "DEBUG" means nothing to Boost.Python one way
or the other.

To get the right compilation/link command lines, build the example
projects using bjam -d+2 or just trial-run the build with bjam -n -a
and copy those down.  I can't vouch for your bulid being correct otherwise.

> QUESTION: Without the .addproperty() stuff (that's commented in the
> snippet above), the code runs fine. But when I added the
> .addproperty() line, a calamity happens: when I was about to
> instantiate HubbardGP object, the computer froze. 


> Now, I'm too new to both python and boost::python. Could you help me
> with this? 

I have no clue.

> I don't believe that my code was the one doing the mess. I
> tend to think that somehow the compiled boost_python code was acting
> up here. 

Always blame the other guy ;-)

> But I can't debug the code easily, as it involves running
> python itself in the debugger. How do you debug such a problem? 

I run Python itself in the debugger.  What's so hard about that?

> Using python debugger is also not possible, since I don't think it
> allows going down to the C++-level code.
> As a workaround, I could only link my HubbardGP.so against the DEBUG
> variant (libboost_python-gcc-d.so). Then the code went fine, even with
> .add_property() there.

Sounds like you got your build commands wrong.  Never fails.  Use bjam
first, then once you get that right, you can do whatever you want.

Dave Abrahams
Boost Consulting

More information about the Cplusplus-sig mailing list