From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 9642 invoked by alias); 22 May 2012 17:38:42 -0000 Received: (qmail 9420 invoked by uid 22791); 22 May 2012 17:38:38 -0000 X-SWARE-Spam-Status: No, hits=-3.5 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00,TW_CX,TW_GC,TW_IB X-Spam-Check-By: sourceware.org Received: from localhost (HELO gcc.gnu.org) (127.0.0.1) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Tue, 22 May 2012 17:38:25 +0000 From: "j.wielicki at sotecware dot net" To: gcc-bugs@gcc.gnu.org Subject: [Bug c++/53455] New: g++ builds segfault in boost::python Date: Tue, 22 May 2012 17:41:00 -0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: new X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: c++ X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: j.wielicki at sotecware dot net X-Bugzilla-Status: UNCONFIRMED X-Bugzilla-Priority: P3 X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Changed-Fields: Message-ID: X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/ Auto-Submitted: auto-generated Content-Type: text/plain; charset="UTF-8" MIME-Version: 1.0 Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-bugs-owner@gcc.gnu.org X-SW-Source: 2012-05/txt/msg02215.txt.bz2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53455 Bug #: 53455 Summary: g++ builds segfault in boost::python Classification: Unclassified Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassigned@gcc.gnu.org ReportedBy: j.wielicki@sotecware.net Host: linux x86_64 (fedora 17) Target: linux x86_64 (fedora 17) With the upgrade to fedora 17, I upgraded to g++ 4.7, which builds a segfault in my current project. I did a lot of research before submitting this bug, while discussing the problem with Niall Douglas on the c++sig mailing list of python. So here is what I found. First the problem itself. In inheritance.cpp:405 (the .ii file of the compilation is attached), compiled with: g++ -ftemplate-depth-128 -O0 -finline-functions -Wno-inline -Wall -std=c++11 -pthread -DBOOST_ALL_NO_LIB=1 -DBOOST_THREAD_USE_LIB=1 -DNDEBUG -I. -I/usr/include/python2.7 -c libs/python/src/object/inheritance.cpp -save-temps the value of p gets somehow lost. This is what gdb has to say to this: #0 0x0000000000405af7 in boost::python::objects::polymorphic_id_generator::execute (p_=0x40a268) at /usr/include/boost/python/object/inheritance.hpp:43 #1 0x00007ffff7dcb684 in boost::(anonymous namespace)::convert_type (p= 0x666db0, src_t=..., dst_t=..., polymorphic=true) at /usr/src/debug/boost_1_48_0/libs/python/src/object/inheritance.cpp:405 Inspecting the code we find that p_ in execute should actually be the same as p, as it is passed literally in convert_type. However, its value magically changes. Here are the characteristics of the problem. It reoccurs with inlining force-disabled. It reoccurs with optimization and without (tried for both, the testing program and for compiling libboost_python). It does _not_ reoccur without -std=c++11 in the testing program. I am not using precompiled headers. I tried boost as delivered with fedora 17, a home-compiled version with -std=c++11 and a home-compiled version without c++11. The c++11 flag on the _library_ does not seem to influence the problem, although the value change is inside the library. However, when turning off c++11 for the testing program (going to attach the .ii too), it works fine. This behaviour did not occur with g++ 4.6.3 and -std=c++0x. Please do not hesitate to ask back if you need any more information, I'm glad if I can help. I also hope that I read the guidelines for bug reporting correctly. If you nevertheless want my testing program source attached, I will also attach that. The crashtest.ii was compiled with: g++ -Wall -g -std=c++0x -I/usr/include/python2.7 -fno-inline -save-temps /home/tester/libboost_python.so.1.48.0 -lpython2.7 crashtest.cpp -o crashtest g++ -v: Using built-in specs. COLLECT_GCC=g++ COLLECT_LTO_WRAPPER=/usr/libexec/gcc/x86_64-redhat-linux/4.7.0/lto-wrapper Target: x86_64-redhat-linux Configured with: ../configure --prefix=/usr --mandir=/usr/share/man --infodir=/usr/share/info --with-bugurl=http://bugzilla.redhat.com/bugzilla --enable-bootstrap --enable-shared --enable-threads=posix --enable-checking=release --disable-build-with-cxx --disable-build-poststage1-with-cxx --with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions --enable-gnu-unique-object --enable-linker-build-id --with-linker-hash-style=gnu --enable-languages=c,c++,objc,obj-c++,java,fortran,ada,go,lto --enable-plugin --enable-initfini-array --enable-java-awt=gtk --disable-dssi --with-java-home=/usr/lib/jvm/java-1.5.0-gcj-1.5.0.0/jre --enable-libgcj-multifile --enable-java-maintainer-mode --with-ecj-jar=/usr/share/java/eclipse-ecj.jar --disable-libjava-multilib --with-ppl --with-cloog --with-tune=generic --with-arch_32=i686 --build=x86_64-redhat-linux Thread model: posix gcc version 4.7.0 20120507 (Red Hat 4.7.0-5) (GCC)