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

[David Abrahams]

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!

Thanks!

> 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 \
>                 -DTBHQMC_MAKE_BOOST_PYTHON_MODULE \
>                 -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. 

<snip>

> 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
http://www.boost-consulting.com