Re: [boost] Python/GCC 3.4.1/Linux failures

From: Martin Wille (mw8329_at_[hidden])
Date: 2004-09-28 07:26:20

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