[C++-sig] boost.python coredump in debug mode..?

[Bjorn Pettersen]

> From: David Abrahams [mailto:dave at boost-consulting.com] 
> 
> "Bjorn Pettersen" <BPettersen at NAREX.com> writes:
> 
> > > From: David Abrahams [mailto:dave at boost-consulting.com]
> > > 
> > > "Bjorn Pettersen" <BPettersen at NAREX.com> writes:
> > > 
> > > > > From: David Abrahams [mailto:dave at boost-consulting.com]
> > > > > 
> > > > > "Bjorn Pettersen" <BPettersen at NAREX.com> writes:
> > > >
> > > > I must be dense because I still can't get it to work. I 
> > > > included 
> > > > <boost/python/detail/wrap_python.hpp> at the top of my file, 
> > > > defined _DEBUG, and linked with either boost_python.lib or 
> > > > boost_python_debug.lib and I'm always getting the 
> > > > coredump.  I'm 
> > > > sure I'm missing something obvious....
> > > 
> > > What was the test case again?
> > 
> > >>> import hello
> > >>> x = hello.World('hi')
> > >>> hello.World('hi')    # this call...
> > <hello.World object at 0x0089E748>
> > >>> x.greet()            # ... causes this to coredump
> > 
> > with the code at 
> > http://www.boost.org/libs/python/doc/tutorial/doc/constructors.html
> 
> I don't know what you're doing wrong, but if you drop the 
> enclosed files into $BOOST_ROOT/libs/python/user and build 
> with bjam, the it checks out fine in both vc6 and vc7 with 
> the current boost CVS state.

Thanks for taking so much time in checking this out. This made it
possible for me to track down the differences (I have to build my
project outside of the Boost hierarchy, and anything but .dsp files
would meet resistance here *sigh*). The culprit was using the default
/MTd (dbg. static rt) instead of the correct /MDd (debug dll rt) -- I
really should know to check this first by now <wink>. There are several
other interesting, and some not so interesting, differences from a
default .dll workspace:

  bjam additions:
  /Ob0 disable inlining (faulty optimizer? -- potentially important)
  /GR  enable RTTI
  /Z7  enable old style debug info (?)

  default .dll workspace switches not in the bjam invocation:
  /GZ  Enable runtime debug checking (at least it sounds potentially
useful <wink>)
  A smattering of other (theoretically) semantically unimportant
switches:
  /W3  Warning level 3, /Gm  Enable minimal rebuild, /FD PDB file, ...

Is this worth filing as a documentation issue, if you think it is I'll
write it up fully (would subscribing to and sending it to the Boost
developers list be the right place to submit it?)

While doing this, I also noticed that bjam was trying to call the wrong
vcvars32.bat file, it's trying to find it in:

  CALL "C:\Program Files\Microsoft Visual C++\VC98\bin\VCVARS32.BAT"
>nul

(and dropping the error on the floor/nul). If you have the full visual
studio, however, vcvars32.bat is in:

  c:\Program Files\Microsoft Visual Studio\VC98\bin\vcvars32.bat

(got to love MS consistency :-) For Visual Studio.NET (vc7), bjam calls
the correct file for Visual Studio (I don't have a standalone Visual
C++, so I can't try that here...)

Should I send this to the same mailing list as above?

Thanks again for spending so much time on something I really should have
been able to figure out myself. Gives me a warm and fuzzy feeling when I
can get persistent help with something like this though. 

Oh, and thanks for such a great library (used to think I was a pretty
good C++ programmer, even went to the ISO meeting in Dublin for my last
job, but I'll definitely have to take a second look before I understand
what's going on on the inside ;-)

-- bjorn

Bjorn Pettersen
Software Architect
NAREX, Inc. (http://www.narex.com)
303.526.4000 ext. 312
303.526.5130 fax