[C++-sig] Re: boost::python and exceptions, seg fault

[David Abrahams]

"Jacques A. Vidrine" <nectar at celabo.org> writes:

> On Thu, Jun 05, 2003 at 11:03:25PM -0400, David Abrahams wrote:
>> 
>> Please keep this dissussion on the C++-sig rather than emailing me
>> personally.
>
> I would be happy to.  For some reason your message to which I was
> replying (Message-ID: <uptlt36vd.fsf at boost-consulting.com>) did not
> include c++-sig in the headers. [1]
>
>> "Jacques A. Vidrine" <nectar at celabo.org> writes:
> [...]
>> > but it apparently didn't run the test :-)
>> 
>> How do you know it didn't run the test?
>
> Sorry, I made a bad assumption.  Double-checking, the test actually
> /did/ run.
>
>> > When I actually load and call the exception_translator_ext, the
>> > exception is uncaught as in my previous simple example.
>> >
>> >   % pwd
>> >   ~/boost_1_29_0/libs/python/test
>> >   % cd bin/exception_translator_ext.so/gcc/debug/runtime-link-dynamic/shared-linkable-true/
>> >   % env PYTHONPATH="$PWD" python                                                                            
>> >   Python 2.2.2 (#1, Feb 11 2003, 21:28:43)                
>> >   [GCC 3.2.2 [FreeBSD] 20030205 (release)] on freebsd5
>> >   Type "help", "copyright", "credits" or "license" for more information.
>> >   >>> import exception_translator_ext
>> >   >>> exception_translator_ext.throw_error()
>> >   zsh: 30040 abort (core dumped)  env PYTHONPATH="$PWD" python
>> 
>> This doesn't prove much.  The point of running the example under bjam
>> is that it handles setting up the environment properly.
>
> I guess it means a lot to me.  Like you said, clearly there is
> something different in the runtime environment.
>
> After some further investigating, it appears that the `release'
> build library (i.e. .../gcc/release/.../libboost_python.so) may be
> the culprit.  The `release' library was installed, but the `debug'
> library was used in the tests.  The test crashes when run against the
> `release' library, but completes successfully when run against the
> `debug' library.
>
> My own applications work with the `debug' library.  I'm afraid I don't
> know enough about the Boost build system at this time to indicate what
> exactly is the difference between the `debug' and `release' built
> bits.  

I don't know what you're asking exactly.  You can run the tests in
'release' mode by adding -sBUILD=release to the bjam invocation.  You
can see exactly what build commands will be executed by passing the -n
flag at the beginning of the bjam command line.  You can see *all*
the actions for everything, including targets that are not
out-of-date, by passing -n -a at the beginning of the command-line.

> If someone could point out where to look for these things, I
> would be happy to continue to try to track down the issue.  It seems
> likely to be some (over)optimization flag or such that tickles a gcc
> bug.
>
> It seems this issue has come up in the c++-sig archives at least two
> other times this year, but it has not seemed to be resolved (on the
> list).
>
>     http://mail.python.org/pipermail/c++-sig/2003-March/003636.html
>     http://mail.python.org/pipermail/c++-sig/2003-January/003152.html
>
> I suspect it can be readily reproduced with gcc 3.2.x, at least.
>
> I wonder if the environment used for testing is not flawed if it does
> not exercise the `release' build?

There's only so much time for testing ;-)

-- 
Dave Abrahams
Boost Consulting
www.boost-consulting.com