Latest CVS: Boost.Python -> Illegal instruction
I am working with the very latest boost CVS. Most Boost.Python tests fail with a segmentation fault with these compilers: gcc version 3.3 20030304 (Apple Computer, Inc. build 1493) gcc version 3.3 20030304 (Apple Computer, Inc. build 1671) gcc version 3.2.2 20030222 (Red Hat Linux 3.2.2-5) gcc version 3.2.3 20030502 (Red Hat Linux 3.2.3-20) gcc version 3.4.3 # compiled from sources, running under RH WS 3 gcc version 3.4.3 # compiled from sources, running under RH 8.0 In contrast, these gcc's do *not* have any problems: gcc version 2.96 20000731 (Red Hat Linux 7.3 2.96-113) gcc version 3.2 20020903 (Red Hat Linux 8.0 3.2-7) valgrind reports no errors for gcc version 3.2 under RH 8.0, but complains about the gcc 3.4.3 compiled code on the same machine (see below). The problem appears to be independent of the Python version (problem observed with 2.2, 2.3, 2.4) and the optimizer (problem observed with -O3 and -O0). The Boost CVS from 2005-Jan-26 11:43 PDT didn't have this problem. I attach the valgrind output for one of the Boost.Python tests. Does this ring any bells? # gcc version 3.2.3 20030502 (Red Hat Linux 3.2.3-20) % valgrind --tool=memcheck /usr/bin/python $BOOST_DIST/libs/python/test/object.py running... ==19174== Memcheck, a memory error detector for x86-linux. ==19174== Copyright (C) 2002-2004, and GNU GPL'd, by Julian Seward et al. ==19174== Using valgrind-2.2.0, a program supervision framework for x86-linux. ==19174== Copyright (C) 2000-2004, and GNU GPL'd, by Julian Seward et al. ==19174== For more details, rerun with: -v ==19174== disInstr: unhandled instruction bytes: 0xCD 0x5 0x90 0x55 at 0x1BE8A57D: _object* boost::python::api::object_base_initializer<boost::python::handle<_typeobject>
(boost::python::handle<_typeobject> const&) (object_core.hpp:285) ==19174== ==19174== Process terminating with default action of signal 4 (SIGILL) ==19174== Illegal operand at address 0xB0021520 ==19174== at 0x1BE8A57D: _object* boost::python::api::object_base_initializer<boost::python::handle<_typeobject> (boost::python::handle<_typeobject> const&) (object_core.hpp:285) ==19174== by 0x1BE89B32: boost::python::api::object::object<boost::python::handle<_typeobject> (boost::python::handle<_typeobject> const&) (object_core.hpp:310) ==19174== by 0x1BE8D921: boost::python::objects::(anonymous namespace)::new_class(char const*, unsigned, boost::python::type_info const*, char const*) (class.cpp:501) ==19174== by 0x1BE8BFCD: boost::python::objects::class_base::class_base(char const*, unsigned, boost::python::type_info const*, char const*) (class.cpp:514) ==19174== ==19174== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 47 from 1) ==19174== malloc/free: in use at exit: 714158 bytes in 8967 blocks. ==19174== malloc/free: 34052 allocs, 25085 frees, 6930352 bytes allocated. ==19174== For a detailed leak analysis, rerun with: --leak-check=yes ==19174== For counts of detected errors, rerun with: -v Illegal instruction
__________________________________ Do you Yahoo!? Yahoo! Mail - Easier than ever with enhanced search. Learn more. http://info.mail.yahoo.com/mail_250
On Wed, 2005-02-02 at 00:43 -0800, Ralf W. Grosse-Kunstleve wrote:
I am working with the very latest boost CVS. Most Boost.Python tests fail with a segmentation fault with these compilers:
gcc version 3.3 20030304 (Apple Computer, Inc. build 1493) gcc version 3.3 20030304 (Apple Computer, Inc. build 1671) gcc version 3.2.2 20030222 (Red Hat Linux 3.2.2-5) gcc version 3.2.3 20030502 (Red Hat Linux 3.2.3-20) gcc version 3.4.3 # compiled from sources, running under RH WS 3 gcc version 3.4.3 # compiled from sources, running under RH 8.0
In contrast, these gcc's do *not* have any problems:
gcc version 2.96 20000731 (Red Hat Linux 7.3 2.96-113) gcc version 3.2 20020903 (Red Hat Linux 8.0 3.2-7)
valgrind reports no errors for gcc version 3.2 under RH 8.0, but complains about the gcc 3.4.3 compiled code on the same machine (see below).
The problem appears to be independent of the Python version (problem observed with 2.2, 2.3, 2.4) and the optimizer (problem observed with -O3 and -O0).
The Boost CVS from 2005-Jan-26 11:43 PDT didn't have this problem.
I attach the valgrind output for one of the Boost.Python tests. Does this ring any bells?
I started to do a test run with GCC 3.3.5, and noticed this warning in the output (should be an error, IMO...): gcc-C ++-action ../../../bin/boost/libs/python/build/libboost_python.so/gcc/debug/shared-linkable-true/numeric.o /home/jonathan/src/boost-CVS-HEAD/boost/boost/python/object_core.hpp: In function `PyObject* boost::python::api::object_base_initializer(const T&) [with T = boost::python::tuple]': /home/jonathan/src/boost-CVS-HEAD/boost/boost/python/object_core.hpp:310: instantiated from `boost::python::api::object::object(const T&) [with T = boost::python::tuple]' /home/jonathan/src/boost-CVS-HEAD/boost/boost/python/numeric.hpp:117: instantiated from `void boost::python::numeric::array::resize(const Sequence&) [with Sequence = boost::python::tuple]' /home/jonathan/src/boost-CVS-HEAD/boost/boost/preprocessor/iteration/detail/local.hpp:37: instantiated from here /home/jonathan/src/boost-CVS-HEAD/boost/boost/python/object_core.hpp:285: warning: cannot pass objects of non-POD type `struct boost::integral_constant<bool, true>' through `...'; call will abort at runtime HTH, -Jonathan
Jonathan Brandmeyer <jbrandmeyer@earthlink.net> writes:
I started to do a test run with GCC 3.3.5, and noticed this warning in the output (should be an error, IMO...):
gcc-C ++-action ../../../bin/boost/libs/python/build/libboost_python.so/gcc/debug/shared-linkable-true/numeric.o /home/jonathan/src/boost-CVS-HEAD/boost/boost/python/object_core.hpp: In function `PyObject* boost::python::api::object_base_initializer(const T&) [with T = boost::python::tuple]': /home/jonathan/src/boost-CVS-HEAD/boost/boost/python/object_core.hpp:310: instantiated from `boost::python::api::object::object(const T&) [with T = boost::python::tuple]' /home/jonathan/src/boost-CVS-HEAD/boost/boost/python/numeric.hpp:117: instantiated from `void boost::python::numeric::array::resize(const Sequence&) [with Sequence = boost::python::tuple]' /home/jonathan/src/boost-CVS-HEAD/boost/boost/preprocessor/iteration/detail/local.hpp:37: instantiated from here /home/jonathan/src/boost-CVS-HEAD/boost/boost/python/object_core.hpp:285: warning: cannot pass objects of non-POD type `struct boost::integral_constant<bool, true>' through `...'; call will abort at runtime
The function is never called; it shouldn't be a problem. -- Dave Abrahams Boost Consulting www.boost-consulting.com
On Thu, 2005-02-03 at 10:24 -0500, David Abrahams wrote:
Jonathan Brandmeyer <jbrandmeyer@earthlink.net> writes:
I started to do a test run with GCC 3.3.5, and noticed this warning in the output (should be an error, IMO...):
gcc-C ++-action ../../../bin/boost/libs/python/build/libboost_python.so/gcc/debug/shared-linkable-true/numeric.o /home/jonathan/src/boost-CVS-HEAD/boost/boost/python/object_core.hpp: In function `PyObject* boost::python::api::object_base_initializer(const T&) [with T = boost::python::tuple]': /home/jonathan/src/boost-CVS-HEAD/boost/boost/python/object_core.hpp:310: instantiated from `boost::python::api::object::object(const T&) [with T = boost::python::tuple]' /home/jonathan/src/boost-CVS-HEAD/boost/boost/python/numeric.hpp:117: instantiated from `void boost::python::numeric::array::resize(const Sequence&) [with Sequence = boost::python::tuple]' /home/jonathan/src/boost-CVS-HEAD/boost/boost/preprocessor/iteration/detail/local.hpp:37: instantiated from here /home/jonathan/src/boost-CVS-HEAD/boost/boost/python/object_core.hpp:285: warning: cannot pass objects of non-POD type `struct boost::integral_constant<bool, true>' through `...'; call will abort at runtime
The function is never called; it shouldn't be a problem.
Clearly it is being called - this is the function at the top of the stacktrace. -Jonathan
I attach the valgrind output for one of the Boost.Python tests. Does this ring any bells?
I started to do a test run with GCC 3.3.5, and noticed this warning in the output (should be an error, IMO...): /home/jonathan/src/boost-CVS-HEAD/boost/boost/preprocessor/iteration/detail/local.hpp:37: instantiated from here /home/jonathan/src/boost-CVS-HEAD/boost/boost/python/object_core.hpp:285: warning: cannot pass objects of non-POD type `struct boost::integral_constant<bool, true>' through `...'; call will abort at runtime
Initially, I thought this might be related to the recent type traits changes, but if it is, I can't see how (integral_constant<bool,v> inherits from mpl::true_ / mpl::false_ so the usual conversions should apply and do the right thing here. Anyone else? John.
"John Maddock" <john@johnmaddock.co.uk> writes:
I attach the valgrind output for one of the Boost.Python tests. Does this ring any bells?
I started to do a test run with GCC 3.3.5, and noticed this warning in the output (should be an error, IMO...): /home/jonathan/src/boost-CVS-HEAD/boost/boost/preprocessor/iteration/detail/local.hpp:37: instantiated from here /home/jonathan/src/boost-CVS-HEAD/boost/boost/python/object_core.hpp:285: warning: cannot pass objects of non-POD type `struct boost::integral_constant<bool, true>' through `...'; call will abort at runtime
Initially, I thought this might be related to the recent type traits changes, but if it is, I can't see how (integral_constant<bool,v> inherits from mpl::true_ / mpl::false_ so the usual conversions should apply and do the right thing here.
I can't imagine how conversions would come into play. -- Dave Abrahams Boost Consulting www.boost-consulting.com
On Thu, 2005-02-03 at 15:48 +0000, John Maddock wrote:
I attach the valgrind output for one of the Boost.Python tests. Does this ring any bells?
I started to do a test run with GCC 3.3.5, and noticed this warning in the output (should be an error, IMO...): /home/jonathan/src/boost-CVS-HEAD/boost/boost/preprocessor/iteration/detail/local.hpp:37: instantiated from here /home/jonathan/src/boost-CVS-HEAD/boost/boost/python/object_core.hpp:285: warning: cannot pass objects of non-POD type `struct boost::integral_constant<bool, true>' through `...'; call will abort at runtime
Initially, I thought this might be related to the recent type traits changes, but if it is, I can't see how (integral_constant<bool,v> inherits from mpl::true_ / mpl::false_ so the usual conversions should apply and do the right thing here.
Anyone else?
John.
GCC at least doesn't think that the conversion applies, as this test indicates. The compiler's output: /home/jonathan/Desktop/mpl_crash.cpp: In function `int main()': /home/jonathan/Desktop/mpl_crash.cpp:19: warning: cannot pass objects of non-POD type `struct derived' through `...'; call will abort at runtime /home/jonathan/Desktop/mpl_crash.cpp:21: warning: cannot pass objects of non-POD type `struct boost::integral_constant<bool, true>' through `...';
On Thu, 2005-02-03 at 22:23 -0500, Jonathan Brandmeyer wrote:
On Thu, 2005-02-03 at 15:48 +0000, John Maddock wrote:
I attach the valgrind output for one of the Boost.Python tests. Does this ring any bells?
I started to do a test run with GCC 3.3.5, and noticed this warning in the output (should be an error, IMO...): /home/jonathan/src/boost-CVS-HEAD/boost/boost/preprocessor/iteration/detail/local.hpp:37: instantiated from here /home/jonathan/src/boost-CVS-HEAD/boost/boost/python/object_core.hpp:285: warning: cannot pass objects of non-POD type `struct boost::integral_constant<bool, true>' through `...'; call will abort at runtime
Initially, I thought this might be related to the recent type traits changes, but if it is, I can't see how (integral_constant<bool,v> inherits from mpl::true_ / mpl::false_ so the usual conversions should apply and do the right thing here.
Anyone else?
John.
GCC at least doesn't think that the conversion applies, as this test indicates.
The compiler's output: /home/jonathan/Desktop/mpl_crash.cpp: In function `int main()': /home/jonathan/Desktop/mpl_crash.cpp:19: warning: cannot pass objects of non-POD type `struct derived' through `...'; call will abort at runtime /home/jonathan/Desktop/mpl_crash.cpp:21: warning: cannot pass objects of non-POD type `struct boost::integral_constant<bool, true>' through `...';
The attached patch solves the problem for GCC. The attached test program was used to test this change. -Jonathan
The attached patch solves the problem for GCC. The attached test program was used to test this change.
Unfortunately that's the last patch I'd like to make, because it breaks type-traits compatibility with the TR1. Can someone familiar with python testing please test the patch below: =================================================================== RCS file: /cvsroot/boost/boost/boost/python/object_core.hpp,v retrieving revision 1.45 diff -r1.45 object_core.hpp 386c386 < template <class T> ---
template <class T, class U>
388c388 < get(T const& x, ...) ---
get(T const& x, U)
I've attempted to test this with cygwin, but the python tests fail even if I revert the type-traits changes (but this could be a setup issue on my part). The patch does fix the compiler warning though (and your test case). I've also done a manual scan of the python sources for any simpilar problems, but can't find anywhere else where this sort of construct is used. Thanks, John.
--- John Maddock <john@johnmaddock.co.uk> wrote:
The attached patch solves the problem for GCC.
It also solves all Boost.Python + newer gcc woes and doesn't cause any hickups on any other platform.
Unfortunately that's the last patch I'd like to make, because it breaks type-traits compatibility with the TR1.
Can someone familiar with python testing please test the patch below:
=================================================================== RCS file: /cvsroot/boost/boost/boost/python/object_core.hpp,v retrieving revision 1.45 diff -r1.45 object_core.hpp 386c386 < template <class T> ---
template <class T, class U>
388c388 < get(T const& x, ...) ---
get(T const& x, U)
Looks like a job for me. I'll try it! Ralf __________________________________ Do you Yahoo!? Take Yahoo! Mail with you! Get it on your mobile phone. http://mobile.yahoo.com/maildemo
--- John Maddock <john@johnmaddock.co.uk> wrote:
Can someone familiar with python testing please test the patch below:
=================================================================== RCS file: /cvsroot/boost/boost/boost/python/object_core.hpp,v retrieving revision 1.45 diff -r1.45 object_core.hpp 386c386 < template <class T> ---
template <class T, class U>
388c388 < get(T const& x, ...) ---
get(T const& x, U)
A preliminary quick test with g++ (GCC) 3.2.3 20030502 (Red Hat Linux 3.2.3-20) suggests that this patch works. I'll now try this on a whole bunch of platforms, which will take a while. Jonathan, could you test if the gcc 3.3.5 warning disappears? (I have no quick and easy way to try it myself.) Ralf __________________________________ Do you Yahoo!? Yahoo! Mail - You care about security. So do we. http://promotions.yahoo.com/new_mail
On Fri, 2005-02-04 at 09:09 -0800, Ralf W. Grosse-Kunstleve wrote:
--- John Maddock <john@johnmaddock.co.uk> wrote:
Can someone familiar with python testing please test the patch below:
=================================================================== RCS file: /cvsroot/boost/boost/boost/python/object_core.hpp,v retrieving revision 1.45 diff -r1.45 object_core.hpp 386c386 < template <class T> ---
template <class T, class U>
388c388 < get(T const& x, ...) ---
get(T const& x, U)
A preliminary quick test with g++ (GCC) 3.2.3 20030502 (Red Hat Linux 3.2.3-20) suggests that this patch works. I'll now try this on a whole bunch of platforms, which will take a while.
Jonathan, could you test if the gcc 3.3.5 warning disappears? (I have no quick and easy way to try it myself.)
Yes. The warning is gone and the tests pass. -Jonathan
--- Jonathan Brandmeyer <jbrandmeyer@earthlink.net> wrote:
On Fri, 2005-02-04 at 09:09 -0800, Ralf W. Grosse-Kunstleve wrote:
--- John Maddock <john@johnmaddock.co.uk> wrote:
Can someone familiar with python testing please test the patch below:
=================================================================== RCS file: /cvsroot/boost/boost/boost/python/object_core.hpp,v retrieving revision 1.45 diff -r1.45 object_core.hpp 386c386 < template <class T> ---
template <class T, class U>
388c388 < get(T const& x, ...) ---
get(T const& x, U)
A preliminary quick test with g++ (GCC) 3.2.3 20030502 (Red Hat Linux 3.2.3-20) suggests that this patch works. I'll now try this on a whole bunch of platforms, which will take a while.
Jonathan, could you test if the gcc 3.3.5 warning disappears? (I have no quick and easy way to try it myself.)
Yes. The warning is gone and the tests pass.
-Jonathan
My tests on 14 different platforms (incl. all the gcc's that failed before) also finished successfully. Therefore I just went ahead and checked in John's patch for boost/python/object_core.hpp (revision 1.46). Thanks John! Cheers, Ralf __________________________________ Do you Yahoo!? Yahoo! Mail - 250MB free storage. Do more. Manage less. http://info.mail.yahoo.com/mail_250
My tests on 14 different platforms (incl. all the gcc's that failed before) also finished successfully. Therefore I just went ahead and checked in John's patch for boost/python/object_core.hpp (revision 1.46). Thanks John!
Good news! Thanks for taking the time to test it - I know when I was messing about with this under cygwin, that those tests take ages to run. John.
participants (5)
-
Caleb Epstein -
David Abrahams -
John Maddock -
Jonathan Brandmeyer -
Ralf W. Grosse-Kunstleve