Jonathan Brandmeyer wrote:

On Sun, 2004-09-26 at 07:26, Aleksey Gurtovoy wrote:

...

There are a few of them, see http://tinyurl.com/5z3hy. What we are going to do about it?

Just an observation, g++ 3.4.2 (Debian 3.4.2-2) passes all of the tests.

The tests fail for gcc 3.4.2 here. Which Python version do you use? I'm using 2.2.2 which apparently has some bugs which would cause crashes. I'd consider an upgrade to 2.2.3 if that is the version you use for the tests. Regards, m

Martin Wille wrote:

I'd consider an upgrade to 2.2.3

Nothing changed after the upgrade, apparently :( Regards, m

Jonathan Wakely wrote:

On Tue, Sep 28, 2004 at 11:24:23AM +0200, Martin Wille wrote:

...

Martin Wille wrote:

...

I'd consider an upgrade to 2.2.3

Nothing changed after the upgrade, apparently :(

Martin, you're running the tests with libstdc++ debug mode enabled, is that right?

Yes, that's right.

Could this be causing some problem?

Interesting idea. The debug mode often finds problems with the use of iterators.

I'd expect to see an exception thrown, but could the Python machinery be swallowing that somehow?

Yes, we've seen similar symptoms with Boost.Python at other occasions. However, the case I've examined doesn't show symptoms of an exception being thrown (see below). I examined the builtin_conversions tests. I think there also is a problem with Boost.Test. For reasons I do not understand there's no other output than the exit status in the .output file created by Boost.Test (see http://tinyurl.com/6hom7 [1]). However, if I run the tests manually then there is other output, too. This is the output I get when I run the test manually: running... LONG_LONG supported, testing... Running __main__.__doc__ Trying: from builtin_converters import * Expecting: nothing ok Trying: if not 'rewrap_value_long_long' in dir(): def rewrap_value_long_long(x): return long(x) def rewrap_value_unsigned_long_long(x): return long(x) def rewrap_const_reference_long_long(x): return long(x) def rewrap_const_reference_unsigned_long_long(x): return long(x) Expecting: nothing ok Trying: rewrap_value_bool(None) Expecting: 0 ok Trying: rewrap_value_bool(0) Expecting: 0 ok Trying: rewrap_value_bool(33) Expecting: 1 ok Trying: rewrap_value_char('x') Expecting: 'x' ok Trying: rewrap_value_char('xy') Expecting: 'x' ok Trying: rewrap_value_signed_char(42) Expecting: 42 ok Trying: rewrap_value_unsigned_char(42) Expecting: 42 ok Trying: rewrap_value_int(42) Expecting: 42 ok Trying: rewrap_value_unsigned_int(42) Expecting: 42 ok Trying: rewrap_value_short(42) Expecting: 42 ok Trying: rewrap_value_unsigned_short(42) Expecting: 42 ok Trying: rewrap_value_long(42) Expecting: 42 ok Trying: rewrap_value_unsigned_long(42) Expecting: 42 ok Trying: hex(rewrap_value_unsigned_long(0x80000001L)).replace('L','') Expecting: '0x80000001' ok Trying: rewrap_value_long_long(42) Expecting: 42L ok Trying: rewrap_value_unsigned_long_long(42) Expecting: 42L ok Trying: try: rewrap_value_unsigned_short(-42) except OverflowError: pass else: print 'expected an OverflowError!' Expecting: nothing ok Trying: try: rewrap_value_int(sys.maxint * 2) except OverflowError: pass else: print 'expected an OverflowError!' Expecting: nothing ok Trying: assert abs(rewrap_value_float(4.2) - 4.2) < .000001 Expecting: nothing ok Trying: rewrap_value_double(4.2) - 4.2 Expecting: 0.0 ok Trying: rewrap_value_long_double(4.2) - 4.2 Expecting: 0.0 ok Trying: assert abs(rewrap_value_complex_float(4+.2j) - (4+.2j)) < .000001 Expecting: nothing Segmentation fault The script printed by Boost.Test, however, seems to be correct wrt the output redirections it does: LD_LIBRARY_PATH=/usr/lib/python2.2/config:../../../bin/boost/libs/python/build/libboost_python.so/gcc-3.4.2-linux/debug/shared-linkable-true:/usr/local/gcc-3.4.2/lib export LD_LIBRARY_PATH PATH=/usr/lib/python2.2/config:/usr/local/gcc-3.4.2/lib:$PATH export PATH PYTHONPATH=../../../bin/boost/libs/python/test/builtin_converters.so/gcc-3.4.2-linux/debug/shared-linkable-true export PYTHONPATH /usr/bin/python2.2 "../../../libs/python/test/test_builtin_converters.py" -v > ../../../bin/boost/libs/python/test/builtin_converters.test/gcc-3.4.2-linux/debug/builtin_converters.output 2>&1 status=$? echo >> ../../../bin/boost/libs/python/test/builtin_converters.test/gcc-3.4.2-linux/debug/builtin_converters.output echo EXIT STATUS: $status >> ../../../bin/boost/libs/python/test/builtin_converters.test/gcc-3.4.2-linux/debug/builtin_converters.output I do not understand why the output from the test program gets swallowed. The backtrace command in gdb shows this stack: #0 0x2d6bc851 in boost::python::to_python_value<std::complex<float> const&>::operator()(std::complex<float> const&) const (this=0x74473b27, x=@0x74473ae8) at builtin_converters.hpp:126 126 BOOST_PYTHON_TO_PYTHON_BY_VALUE(std::complex<float>, ::PyComplex_FromDoubles(x.real(), x.imag())) (gdb) bt #0 0x2d6bc851 in boost::python::to_python_value<std::complex<float> const&>::operator()(std::complex<float> const&) const (this=0x74473b27, x=@0x74473ae8) at builtin_converters.hpp:126 #1 0x2d6bf115 in _object* boost::python::detail::invoke<boost::python::to_python_value<std::complex<float> const&>, std::complex<float> (*)(std::complex<float>), boost::python::arg_from_python<std::complex<float> >

(boost::python::detail::invoke_tag_<false, false>, boost::python::to_python_value<std::complex<float> const&> const&, std::complex<float> (*)(std::complex<float>)&, boost::python::arg_from_python<std::complex<float> >&) (rc=@0x74473b27, f=@0x81aa404, ac0=@0x74473b30) at invoke.hpp:75 #2 0x2d6b9d72 in boost::python::detail::caller_arity<1>::impl<std::complex<float> (*)(std::complex<float>), boost::python::default_call_policies, boost::mpl::vector2<std::complex<float>, std::complex<float> > ::operator()(_object*, _object*) (this=0x81aa404, args_=0x81d796c) at caller.hpp:194 #3 0x2d6b644a in boost::python::objects::caller_py_function_impl<boost::python::detail::caller<std::complex<float> (*)(std::complex<float>), boost::python::default_call_policies, boost::mpl::vector2<std::complex<float>, std::complex<float> > > ::operator()(_object*, _object*) (this=0x81aa400, args=0x81d796c, kw=0x0) at py_function.hpp:38 #4 0x2d7b78af in boost::python::objects::py_function::operator()(_object*, _object*) const (this=0x81c8068, args=0x81d796c, kw=0x0) at py_function.hpp:139 #5 0x2d7b611b in boost::python::objects::function::call(_object*, _object*) const (this=0x81c8060, args=0x81d796c, keywords=0x0) at /boost/head-regression/boost/libs/python/build/../src/object/function.cpp:209 #6 0x2d7b9e92 in boost::python::objects::(anonymous namespace)::bind_return::operator()() const (this=0x74473d40) at /boost/head-regression/boost/libs/python/build/../src/object/function.cpp:502 #7 0x2d7b9e45 in boost::detail::function::void_function_obj_invoker0<boost::python::objects::(anonymous namespace)::bind_return, void>::invoke(boost::detail::function::any_pointer) (function_obj_ptr={obj_ptr = 0x74473d40, const_obj_ptr = 0x74473d40, func_ptr = 0x74473d40, data = "@"}) at function_template.hpp:128 #8 0x2d7e6cbc in boost::function0<void, std::allocator<boost::function_base> >::operator()() const (this=0x74473d20) at function_template.hpp:581 #9 0x2d7e66a1 in boost::python::handle_exception_impl(boost::function0<void, std::allocator<boost::function_base> >) (f= {<function_base> = {manager = 0x2d7b9ea2 <boost::detail::function::trivial_manager<boost::python::objects::(anonymous namespace)::bind_return>::get(boost::detail::function::any_pointer, boost::detail::function::functor_manager_operation_type)>, functor = {obj_ptr = 0x74473d40, const_obj_ptr = 0x74473d40, func_ptr = 0x74473d40, data = "@"}}, static args = <optimized out>, static arity = <optimized out>, invoker = 0x2d7b9e1e <boost::detail::function::void_function_obj_invoker0<boost::python::objects::(anonymous namespace)::bind_return, void>::invoke(boost::detail::function::any_pointer)>}) at /boost/head-regression/boost/libs/python/build/../src/errors.cpp:25 #10 0x2d7b8c71 in bool boost::python::handle_exception<boost::python::objects::(anonymous namespace)::bind_return>(boost::python::objects::(anonymous namespace)::bind_return) (f={m_result = @0x74473d7c, m_f = 0x81c8060, m_args = 0x81d796c, m_keywords = 0x0}) at errors.hpp:29 #11 0x2d7b72e0 in function_call (func=0x81c8060, args=0x81d796c, kw=0x0) at /boost/head-regression/boost/libs/python/build/../src/object/function.cpp:534 #12 0x080c51e7 in PyObject_Call () #13 0x0807b300 in PyEval_GetFuncDesc () #14 0x0807926e in PyEval_EvalCode () #15 0x08079e66 in PyEval_EvalCodeEx () #16 0x08076e95 in PyEval_EvalCode () #17 0x0807c1d5 in _PyEval_SliceIndex () #18 0x0807844e in PyEval_EvalCode () #19 0x08079e66 in PyEval_EvalCodeEx () #20 0x0807b22b in PyEval_GetFuncDesc () #21 0x080792ea in PyEval_EvalCode () #22 0x08079e66 in PyEval_EvalCodeEx () #23 0x0807b22b in PyEval_GetFuncDesc () #24 0x080792ea in PyEval_EvalCode () #25 0x08079e66 in PyEval_EvalCodeEx () #26 0x0807b22b in PyEval_GetFuncDesc () #27 0x080792ea in PyEval_EvalCode () #28 0x08079e66 in PyEval_EvalCodeEx () #29 0x0807b22b in PyEval_GetFuncDesc () #30 0x080792ea in PyEval_EvalCode () #31 0x08079e66 in PyEval_EvalCodeEx () #32 0x0807b22b in PyEval_GetFuncDesc () #33 0x080792ea in PyEval_EvalCode () #34 0x08079e66 in PyEval_EvalCodeEx () #35 0x0807b22b in PyEval_GetFuncDesc () #36 0x080792ea in PyEval_EvalCode () #37 0x08079e66 in PyEval_EvalCodeEx () #38 0x08076e95 in PyEval_EvalCode () #39 0x080a8579 in PyRun_FileExFlags () #40 0x080a7a58 in PyRun_SimpleFileExFlags () #41 0x080a749a in PyRun_AnyFileExFlags () #42 0x080539a8 in Py_Main () #43 0x08053479 in main ()

I hope this information enables someone to analyse the problem further. Regards, m

David Abrahams wrote:

Martin Wille writes:

...

Trying: assert abs(rewrap_value_complex_float(4+.2j) - (4+.2j)) < .000001 Expecting: nothing Segmentation fault

Wild guess: This is an ODR violation. The Boost.Python library and the test shared library were compiled with a different definition of std::complex.

How could that have happened? Note, this is not the intel compiler, so flags like "-cxxlib-gcc" shouldn't be a problem here. Could the build system use so different flags that the resulting libraries wouldn't be interoperable? (I know this can happen rather easily on other systems. However, I haven't seen that with gcc on Linux as long as you stick to the same compiler version). Python was compiled using gcc 3.3.4. Could this cause the problem? (I don't think so.) Regards, m

On Thu, Sep 30, 2004 at 08:26:21AM -0400, David Abrahams wrote:

...

Python was compiled using gcc 3.3.4. Could this cause the problem? (I don't think so.)

I don't think they changed the ABI for 3.4.1 did they?

Between 3.3.x and 3.4.y, yes, the ABI definitely changed. Not between 3.4.x and 3.4.y though (as you'd expect). jon -- "An alcoholic is someone you don't like who drinks as much as you do." - Dylan Thomas

Martin Wille <mw8329@yahoo.com.au> writes:

Jonathan Wakely wrote:

...

On Thu, Sep 30, 2004 at 08:26:21AM -0400, David Abrahams wrote:

...

...

Python was compiled using gcc 3.3.4. Could this cause the problem? (I don't think so.)

I don't think they changed the ABI for 3.4.1 did they? Between 3.3.x and 3.4.y, yes, the ABI definitely changed. Not between 3.4.x and 3.4.y though (as you'd expect).

Python is a C program, AFAIK. I don't think the C ABI changed.

Have you tried a clean rebuild? -- Dave Abrahams Boost Consulting http://www.boost-consulting.com