Bug#554574: libstdc++6: apt segfaults on hppa
On Mon, Nov 23, 2009 at 8:48 AM, Aurelien Jarno aurel...@aurel32.net wrote: Next steps: (1) Wait for testsuite results to finish completely. Verify nothing has regressed. No regressions. (2) Remove changes to gcc package debian/rules2 and re-run validation. Some regressions caused by enabling cloog/ppl, however these regressions do not break the libstdc++6 package in any critical way. Re-running the test case by hand now works, and the C++ class has the correct offsets. (3) In parallel provide new patch to debian-glibc to fix alignment issues with pthread types. Done. (4) Ask debian-glibc team to run a build and look for testsuite regressions. Done. If the test results for (2) and (4) are clean, then I will give the green light for a new glibc to be uploaded. This will fix the libstdc++6 issues. The test results for (2) and (4) are clean enough for a release given my QA. I guess there is a fifth step need: (5) rebuild gcc-4.4 against the fixed glibc. Aurelian has uploaded a new glibc with the fix and informs me that gcc is currently rebuilding. Once I conform that the newly built gcc is OK, we can close this issue and start building packages again. Cheers, Carlos. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#554574: libstdc++6: apt segfaults on hppa
Carlos O'Donell a écrit : On Sun, Nov 22, 2009 at 5:05 PM, John David Anglin d...@hiauly1.hia.nrc.ca wrote: While I set out the glibc types exactly as before (binary compatible), the alignment restrictions were changed subtly. Excellent debugging! I have adjusted the glibc lock structure alignments to try and match more accurately the original alignment restrictions. I have built a glibc with the new headers, and installed that into my test system. I'm now rebuilding libstdc++6 against the new headers to determine if this fixes the problem. I will have results by tomorrow. Thanks a lot for the investigation, I really hope this will work. -- Aurelien Jarno GPG: 1024D/F1BCDB73 aurel...@aurel32.net http://www.aurel32.net -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#554574: libstdc++6: apt segfaults on hppa
On Mon, Nov 23, 2009 at 5:22 AM, Aurelien Jarno aurel...@aurel32.net wrote: Carlos O'Donell a écrit : On Sun, Nov 22, 2009 at 5:05 PM, John David Anglin d...@hiauly1.hia.nrc.ca wrote: While I set out the glibc types exactly as before (binary compatible), the alignment restrictions were changed subtly. Excellent debugging! I have adjusted the glibc lock structure alignments to try and match more accurately the original alignment restrictions. I have built a glibc with the new headers, and installed that into my test system. I'm now rebuilding libstdc++6 against the new headers to determine if this fixes the problem. I will have results by tomorrow. Thanks a lot for the investigation, I really hope this will work. It worked. I now see 0xb0 as the object offset, which gives a compatible object layout for the libstdc++ iostream classes. (gdb) x/16x $ret0 - 0xc 0x409a6f38 _ZTCSt14basic_ifstreamIcSt11char_traitsIcEE0_Si: 0x00b0 0x 0x409a72f0 0x401b2b96 0x409a6f48 _ZTCSt14basic_ifstreamIcSt11char_traitsIcEE0_Si+16: 0x401b2b9e 0xff50 0xff50 0x409a72f0 0x409a6f58 _ZTCSt14basic_ifstreamIcSt11char_traitsIcEE0_Si+32: 0x401b2ba6 0x401b2bae 0x 0x409a6ff4 0x409a6f68 _ZTVSt13basic_filebufIcSt11char_traitsIcEE+8: 0x401b2e6e 0x401b2e76 0x401b2e7e 0x401b2e86 I can successfully run apt-get with the new libstdc++6 that I just built. The testsuite result is cleaner: ~~~ FAIL: 29_atomics/atomic_flag/clear/1.c execution test FAIL: 29_atomics/atomic_flag/test_and_set/explicit.c execution test === libstdc++ Summary === # of expected passes5880 # of unexpected failures2 # of expected failures 80 # of unsupported tests 331 ~~~ I am still building with ~~~ # Disable cloog/ppl and pch on hppa. ifneq (,$(findstring $(DEB_TARGET_ARCH), hppa)) CONFARGS += --without-ppl --without-cloog --disable-libstdcxx-pch endif ~~~ However, I don't think this made any difference. Next steps: (1) Wait for testsuite results to finish completely. Verify nothing has regressed. (2) Remove changes to gcc package debian/rules2 and re-run validation. (3) In parallel provide new patch to debian-glibc to fix alignment issues with pthread types. (4) Ask debian-glibc team to run a build and look for testsuite regressions. If the test results for (2) and (4) are clean, then I will give the green light for a new glibc to be uploaded. This will fix the libstdc++6 issues. Cheers, Carlos. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#554574: libstdc++6: apt segfaults on hppa
On Mon, Nov 23, 2009 at 08:17:03AM -0500, Carlos O'Donell wrote: On Mon, Nov 23, 2009 at 5:22 AM, Aurelien Jarno aurel...@aurel32.net wrote: Carlos O'Donell a écrit : On Sun, Nov 22, 2009 at 5:05 PM, John David Anglin d...@hiauly1.hia.nrc.ca wrote: While I set out the glibc types exactly as before (binary compatible), the alignment restrictions were changed subtly. Excellent debugging! I have adjusted the glibc lock structure alignments to try and match more accurately the original alignment restrictions. I have built a glibc with the new headers, and installed that into my test system. I'm now rebuilding libstdc++6 against the new headers to determine if this fixes the problem. I will have results by tomorrow. Thanks a lot for the investigation, I really hope this will work. It worked. I now see 0xb0 as the object offset, which gives a compatible object layout for the libstdc++ iostream classes. (gdb) x/16x $ret0 - 0xc 0x409a6f38 _ZTCSt14basic_ifstreamIcSt11char_traitsIcEE0_Si: 0x00b0 0x 0x409a72f0 0x401b2b96 0x409a6f48 _ZTCSt14basic_ifstreamIcSt11char_traitsIcEE0_Si+16: 0x401b2b9e 0xff50 0xff50 0x409a72f0 0x409a6f58 _ZTCSt14basic_ifstreamIcSt11char_traitsIcEE0_Si+32: 0x401b2ba6 0x401b2bae 0x 0x409a6ff4 0x409a6f68 _ZTVSt13basic_filebufIcSt11char_traitsIcEE+8: 0x401b2e6e 0x401b2e76 0x401b2e7e 0x401b2e86 I can successfully run apt-get with the new libstdc++6 that I just built. Nice work :) The testsuite result is cleaner: ~~~ FAIL: 29_atomics/atomic_flag/clear/1.c execution test FAIL: 29_atomics/atomic_flag/test_and_set/explicit.c execution test === libstdc++ Summary === # of expected passes5880 # of unexpected failures2 # of expected failures 80 # of unsupported tests 331 ~~~ I am still building with ~~~ # Disable cloog/ppl and pch on hppa. ifneq (,$(findstring $(DEB_TARGET_ARCH), hppa)) CONFARGS += --without-ppl --without-cloog --disable-libstdcxx-pch endif ~~~ However, I don't think this made any difference. Next steps: (1) Wait for testsuite results to finish completely. Verify nothing has regressed. (2) Remove changes to gcc package debian/rules2 and re-run validation. (3) In parallel provide new patch to debian-glibc to fix alignment issues with pthread types. (4) Ask debian-glibc team to run a build and look for testsuite regressions. If the test results for (2) and (4) are clean, then I will give the green light for a new glibc to be uploaded. This will fix the libstdc++6 issues. I guess there is a fifth step need: (5) rebuild gcc-4.4 against the fixed glibc. -- Aurelien Jarno GPG: 1024D/F1BCDB73 aurel...@aurel32.net http://www.aurel32.net -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#554574: libstdc++6: apt segfaults on hppa
On Mon, 23 Nov 2009, Carlos O'Donell wrote: I can successfully run apt-get with the new libstdc++6 that I just built. The testsuite result is cleaner: ~~~ FAIL: 29_atomics/atomic_flag/clear/1.c execution test FAIL: 29_atomics/atomic_flag/test_and_set/explicit.c execution test === libstdc++ Summary === # of expected passes5880 # of unexpected failures2 # of expected failures 80 # of unsupported tests 331 There are a couple of issues wrt running the libstdc++6 testsuite: 1) The locale tests require a certain minimal set of foreign locales to run. Simplest may be to install all locales. 2) In order to use the generic code using the the atomic builtins, a patch is needed. I have recently tested the attached two changes provided by Matthias. In addition, the undef and define for LIB_SPEC in pa-linux.h should be removed. Dave -- J. David Anglin dave.ang...@nrc-cnrc.gc.ca National Research Council of Canada (613) 990-0752 (FAX: 952-6602) # DP: Do link tests to check for the atomic builtins 2009-05-03 Paolo Carlini paolo.carl...@oracle.com * acinclude.m4 ([GLIBCXX_ENABLE_ATOMIC_BUILTINS]): Do link tests when possible. * configure: Regenerate. Index: acinclude.m4 === --- a/src/libstdc++-v3/acinclude.m4 (revision 147071) +++ b/src/libstdc++-v3/acinclude.m4 (working copy) @@ -2429,8 +2429,7 @@ dnl that are used should be checked. dnl dnl Note: -dnl libgomp and libgfortran do this with a link test, instead of an asm test. -dnl see: CHECK_SYNC_FETCH_AND_ADD +dnl libgomp and libgfortran use a link test, see CHECK_SYNC_FETCH_AND_ADD. dnl dnl Defines: dnl _GLIBCXX_ATOMIC_BUILTINS_1 @@ -2442,12 +2441,110 @@ AC_LANG_SAVE AC_LANG_CPLUSPLUS old_CXXFLAGS=$CXXFLAGS - + + # Do link tests if possible, instead asm tests. + if test x$gcc_no_link != xyes; then + + # Can do link tests. + + CXXFLAGS=$CXXFLAGS -fno-exceptions + + AC_MSG_CHECKING([for atomic builtins for bool]) + AC_CACHE_VAL(glibcxx_cv_atomic_bool, [ +AC_TRY_LINK( + [ ], + [typedef bool atomic_type; + atomic_type c1; + atomic_type c2; + const atomic_type c3(0); + __sync_fetch_and_add(c1, c2); + __sync_val_compare_and_swap(c1, c3, c2); + __sync_lock_test_and_set(c1, c3); + __sync_lock_release(c1); + __sync_synchronize();], + [glibcxx_cv_atomic_bool=yes], + [glibcxx_cv_atomic_bool=no]) + ]) + if test $glibcxx_cv_atomic_bool = yes; then +AC_DEFINE(_GLIBCXX_ATOMIC_BUILTINS_1, 1, + [Define if builtin atomic operations for bool are supported on this host.]) + fi + AC_MSG_RESULT($glibcxx_cv_atomic_bool) + + AC_MSG_CHECKING([for atomic builtins for short]) + AC_CACHE_VAL(glibcxx_cv_atomic_short, [ +AC_TRY_LINK( + [ ], + [typedef short atomic_type; + atomic_type c1; + atomic_type c2; + const atomic_type c3(0); + __sync_fetch_and_add(c1, c2); + __sync_val_compare_and_swap(c1, c3, c2); + __sync_lock_test_and_set(c1, c3); + __sync_lock_release(c1); + __sync_synchronize();], + [glibcxx_cv_atomic_short=yes], + [glibcxx_cv_atomic_short=no]) + ]) + if test $glibcxx_cv_atomic_short = yes; then +AC_DEFINE(_GLIBCXX_ATOMIC_BUILTINS_2, 1, + [Define if builtin atomic operations for short are supported on this host.]) + fi + AC_MSG_RESULT($glibcxx_cv_atomic_short) + + AC_MSG_CHECKING([for atomic builtins for int]) + AC_CACHE_VAL(glibcxx_cv_atomic_int, [ +AC_TRY_LINK( + [ ], + [typedef int atomic_type; + atomic_type c1; + atomic_type c2; + const atomic_type c3(0); + __sync_fetch_and_add(c1, c2); + __sync_val_compare_and_swap(c1, c3, c2); + __sync_lock_test_and_set(c1, c3); + __sync_lock_release(c1); + __sync_synchronize();], + [glibcxx_cv_atomic_int=yes], + [glibcxx_cv_atomic_int=no]) + ]) + if test $glibcxx_cv_atomic_int = yes; then +AC_DEFINE(_GLIBCXX_ATOMIC_BUILTINS_4, 1, + [Define if builtin atomic operations for int are supported on this host.]) + fi + AC_MSG_RESULT($glibcxx_cv_atomic_int) + + AC_MSG_CHECKING([for atomic builtins for long long]) + AC_CACHE_VAL(glibcxx_cv_atomic_long_long, [ +AC_TRY_LINK( + [ ], + [typedef long long atomic_type; + atomic_type c1; + atomic_type c2; + const atomic_type c3(0); + __sync_fetch_and_add(c1, c2); + __sync_val_compare_and_swap(c1, c3, c2); + __sync_lock_test_and_set(c1, c3); + __sync_lock_release(c1); + __sync_synchronize();], + [glibcxx_cv_atomic_long_long=yes], + [glibcxx_cv_atomic_long_long=no]) + ]) + if test $glibcxx_cv_atomic_long_long = yes; then +AC_DEFINE(_GLIBCXX_ATOMIC_BUILTINS_8, 1, + [Define if builtin atomic operations for long
Bug#554574: libstdc++6: apt segfaults on hppa
On Sat, Nov 21, 2009 at 10:00:59PM -0500, John David Anglin wrote: On Sat, Nov 21, 2009 at 5:37 AM, Aurelien Jarno aurel...@aurel32.net wrote: I confirm, it's what I see in the testsuite log: | 77 | __signbitl | version status: incompatible | GLIBCXX_3.4 | type: function | status: added If __signbitl is the only failure in the abi_check, then that's easy to fix, the testsuite needs to be updated. The fail is somewhat puzzling because the problem is supposed fixed in the 4.4 branch. With cloog/ppl disabled I still get 7 testsuite failures, so I'll have to dig into each failure tommorow and see what's wrong. ~~~ Running target unix FAIL: abi_check FAIL: 26_numerics/complex/13450.cc (test for excess errors) UNRESOLVED: 26_numerics/complex/13450.cc compilation failed to produce executable FAIL: 26_numerics/complex/pow.cc (test for excess errors) UNRESOLVED: 26_numerics/complex/pow.cc compilation failed to produce executable XPASS: 26_numerics/headers/cmath/c99_classification_macros_c.cc (test for excess errors) FAIL: 29_atomics/atomic_flag/clear/1.c execution test FAIL: 29_atomics/atomic_flag/test_and_set/explicit.c execution test FAIL: tr1/8_c_compatibility/complex/overloads_float.cc (test for excess errors) FAIL: tr1/8_c_compatibility/complex/overloads_int.cc (test for excess errors) UNRESOLVED: tr1/8_c_compatibility/complex/overloads_int.cc compilation failed to produce executable Try adding --disable-libstdcxx-pch as mentioned earlier in this thread. This is PR 39355: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39355 Good luck in debugging this bug! I was not able to determine the actual cause. It appears GCC's internal data are somewhat corrupt when the pch header files are generated. This causes various tests to ICE when compiled with the pch headers. The problem appears to have gone away with head. I don't see it with hpux. Note that latest version of gcc 4.4 in Debian is built with --disable-libstdcxx-pch, but the segfault is this present :( -- Aurelien Jarno GPG: 1024D/F1BCDB73 aurel...@aurel32.net http://www.aurel32.net -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#554574: libstdc++6: apt segfaults on hppa
On Sat, Nov 21, 2009 at 08:55:12PM -0500, Carlos O'Donell wrote: On Sat, Nov 21, 2009 at 5:37 AM, Aurelien Jarno aurel...@aurel32.net wrote: I confirm, it's what I see in the testsuite log: | 77 | __signbitl | version status: incompatible | GLIBCXX_3.4 | type: function | status: added If __signbitl is the only failure in the abi_check, then that's easy to fix, the testsuite needs to be updated. For the testsuite part yes, but not the segfault :( With cloog/ppl disabled I still get 7 testsuite failures, so I'll have to dig into each failure tommorow and see what's wrong. ~~~ Running target unix FAIL: abi_check FAIL: 26_numerics/complex/13450.cc (test for excess errors) UNRESOLVED: 26_numerics/complex/13450.cc compilation failed to produce executable FAIL: 26_numerics/complex/pow.cc (test for excess errors) UNRESOLVED: 26_numerics/complex/pow.cc compilation failed to produce executable XPASS: 26_numerics/headers/cmath/c99_classification_macros_c.cc (test for excess errors) FAIL: 29_atomics/atomic_flag/clear/1.c execution test FAIL: 29_atomics/atomic_flag/test_and_set/explicit.c execution test FAIL: tr1/8_c_compatibility/complex/overloads_float.cc (test for excess errors) FAIL: tr1/8_c_compatibility/complex/overloads_int.cc (test for excess errors) UNRESOLVED: tr1/8_c_compatibility/complex/overloads_int.cc compilation failed to produce executable Does the resulting binary works correctly with apt-get? -- Aurelien Jarno GPG: 1024D/F1BCDB73 aurel...@aurel32.net http://www.aurel32.net -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#554574: libstdc++6: apt segfaults on hppa
The problem appears to have gone away with head. I don't see it with hpux. Note that latest version of gcc 4.4 in Debian is built with --disable-libstdcxx-pch, but the segfault is this present :( Personally, I don't believe the segfault is related to the FAILs seen in the libstdc++ testsuite. As you showed, there is an ABI change in the library depending on libc version. Someone needs to generate a backtrace so that we can get some idea what's happening. Dave -- J. David Anglin dave.ang...@nrc-cnrc.gc.ca National Research Council of Canada (613) 990-0752 (FAX: 952-6602) -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#554574: libstdc++6: apt segfaults on hppa
On Sun, Nov 22, 2009 at 10:30:16AM -0500, John David Anglin wrote: The problem appears to have gone away with head. I don't see it with hpux. Note that latest version of gcc 4.4 in Debian is built with --disable-libstdcxx-pch, but the segfault is this present :( Personally, I don't believe the segfault is related to the FAILs seen in the libstdc++ testsuite. As you showed, there is an ABI change in the library depending on libc version. Someone needs to generate a backtrace so that we can get some idea what's happening. This is what I get using apt-get with the broken libstdc++. Note that simple hello world programs still works. | #0 0x4040d8cc in std::locale::operator=(std::locale const) () from 4.4.2-2/usr/lib/libstdc++.so.6 | #1 0x4040bc10 in std::ios_base::_M_init() () from 4.4.2-2/usr/lib/libstdc++.so.6 | #2 0x40424858 in std::basic_ioschar, std::char_traitschar ::init(std::basic_streambufchar, std::char_traitschar *) () |from 4.4.2-2/usr/lib/libstdc++.so.6 | #3 0x406ffeec in ReadConfigFile(Configuration, std::string const, bool, unsigned int) () from /usr/lib/libapt-pkg-libc6.9-6.so.4.8 | #4 0x406ff9e8 in ReadConfigDir(Configuration, std::string const, bool, unsigned int) () from /usr/lib/libapt-pkg-libc6.9-6.so.4.8 | #5 0x4073eeac in pkgInitConfig(Configuration) () from /usr/lib/libapt-pkg-libc6.9-6.so.4.8 | #6 0x0001d8b8 in main () The crash happens at the end of the function: [...] | 0x4040d8b8 _ZNSt6localeaSERKS_+168: ldw 0(r5),ret0 | 0x4040d8bc _ZNSt6localeaSERKS_+172: ldw 0(r26),ret0 | 0x4040d8c0 _ZNSt6localeaSERKS_+176: ldo 1(ret0),ret0 | 0x4040d8c4 _ZNSt6localeaSERKS_+180: stw ret0,0(r26) | 0x4040d8c8 _ZNSt6localeaSERKS_+184: ldw 0(r3),r6 | 0x4040d8cc _ZNSt6localeaSERKS_+188: ldw 0(r6),ret0 | 0x4040d8d0 _ZNSt6localeaSERKS_+192: ldo -1(ret0),r20 | 0x4040d8d4 _ZNSt6localeaSERKS_+196: b,l 0x4040d86c _ZNSt6localeaSERKS_+92,r0 | 0x4040d8d8 _ZNSt6localeaSERKS_+200: stw r20,0(r6) | End of assembler dump. -- Aurelien Jarno GPG: 1024D/F1BCDB73 aurel...@aurel32.net http://www.aurel32.net -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#554574: libstdc++6: apt segfaults on hppa
On Sun, Nov 22, 2009 at 10:30 AM, John David Anglin d...@hiauly1.hia.nrc.ca wrote: The problem appears to have gone away with head. I don't see it with hpux. Note that latest version of gcc 4.4 in Debian is built with --disable-libstdcxx-pch, but the segfault is this present :( Personally, I don't believe the segfault is related to the FAILs seen in the libstdc++ testsuite. As you showed, there is an ABI change in the library depending on libc version. Someone needs to generate a backtrace so that we can get some idea what's happening. Running apt-get with the newly compiled libstdc++6 with --without-cloog/--without-ppl still cause the segfault. The glibc locale() function is causing this failure. The segfault happens when basic_ios is being initialized. The ios_base::_M_init() calls locale() to create a locale object and stores this into _M_ios_locale. The assignment is done through an operator= for the locale type, and this crashes. Starting program: /usr/bin/apt-get Program received signal SIGSEGV, Segmentation fault. std::locale::operator= (this=0xbff01c84, __other=...) at ../../../../src/libstdc++-v3/src/locale.cc:116 116 _M_impl-_M_remove_reference(); Current language: auto; currently c++ (gdb) bt #0 std::locale::operator= (this=0xbff01c84, __other=...) at ../../../../src/libstdc++-v3/src/locale.cc:116 #1 0x40390c10 in std::ios_base::_M_init (this=0xbff01fc8) at ../../../../src/libstdc++-v3/src/ios_locale.cc:43 #2 0x403a9858 in std::basic_ioschar, std::char_traitschar ::init (this=0x4043e890, __sb=0xbff01fc8) at /home/carlos/fsrc/debian/gcc-4.4-4.4.2/build/hppa-linux-gnu/libstdc++-v3/include/bits/basic_ios.tcc:128 #3 0x405c7eec in ReadConfigFile(Configuration, std::string const, bool, unsigned int) () from /usr/lib/libapt-pkg-libc6.9-6.so.4.8 #4 0x405c79e8 in ReadConfigDir(Configuration, std::string const, bool, unsigned int) () from /usr/lib/libapt-pkg-libc6.9-6.so.4.8 #5 0x40606eac in pkgInitConfig(Configuration) () from /usr/lib/libapt-pkg-libc6.9-6.so.4.8 #6 0x0001d8b8 in main () (gdb) This is the 14th call to std::locale::operator=, but the first call with an object that was created on the stack. The object *this a std::locale object, has an invalid _M_impl member, whose value should be a pointer to an implementation but instead it's a value of 0x8. This happens because the original locale object was created at address 0xbff01c20. However, when apt-get calls std::basic_ioschar, std::char_traitschar ::init it passes in the address 0xbff01c18. So we went from a constructor using this as 0xbff01c20, to eventually passing this as 0xbff01c18 to a template. The pointer to the std::ios_base object is now off by 8 bytes and this causes the crash. What happened here? Why does ReadConfigFile() think that the object is in a different location? Any hints on how to track this down? Cheers, Carlos. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#554574: libstdc++6: apt segfaults on hppa
On Sun, Nov 22, 2009 at 2:51 PM, Carlos O'Donell car...@systemhalted.org wrote: This happens because the original locale object was created at address 0xbff01c20. However, when apt-get calls std::basic_ioschar, std::char_traitschar ::init it passes in the address 0xbff01c18. So we went from a constructor using this as 0xbff01c20, to eventually passing this as 0xbff01c18 to a template. The pointer to the std::ios_base object is now off by 8 bytes and this causes the crash. What happened here? Why does ReadConfigFile() think that the object is in a different location? Any hints on how to track this down? The problem is here, we read 0xa8 here from libstdc++6: (gdb) x/16x $ret0 - 0xc 0x40437778 _ZTCSt14basic_ifstreamIcSt11char_traitsIcEE0_Si: 0x00a8 0x 0x40437b30 0x401b2b96 0x40437788 _ZTCSt14basic_ifstreamIcSt11char_traitsIcEE0_Si+16: 0x401b2b9e 0xff58 0xff58 0x40437b30 0x40437798 _ZTCSt14basic_ifstreamIcSt11char_traitsIcEE0_Si+32: 0x401b2ba6 0x401b2bae 0x 0x40437834 Then we add this offset to the base location of the object on the stack and we compute 0xbff01c18, instead of computing 0xbff01c20 as we would expect. It looks like the layout of the object in libstdc++.so.6 has changed, my guess is that the changes I made to the locking types in glibc have caused the layout to be perturbed. While I set out the glibc types exactly as before (binary compatible), the alignment restrictions were changed subtly. I will go back immediately and review this. Cheers, Carlos. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#554574: libstdc++6: apt segfaults on hppa
On Sun, Nov 22, 2009 at 2:51 PM, Carlos O'Donell car...@systemhalted.org wrote: This happens because the original locale object was created at address 0xbff01c20. However, when apt-get calls std::basic_ioschar, std::char_traitschar ::init it passes in the address 0xbff01c18. So we went from a constructor using this as 0xbff01c20, to eventually passing this as 0xbff01c18 to a template. The pointer to the std::ios_base object is now off by 8 bytes and this causes the crash. What happened here? Why does ReadConfigFile() think that the object is in a different location? Any hints on how to track this down? The ptype command might help to display the object and to see what's changed. The problem is here, we read 0xa8 here from libstdc++6: (gdb) x/16x $ret0 - 0xc 0x40437778 _ZTCSt14basic_ifstreamIcSt11char_traitsIcEE0_Si: 0x00a8 0x 0x40437b30 0x401b2b96 0x40437788 _ZTCSt14basic_ifstreamIcSt11char_traitsIcEE0_Si+16: 0x401b2b9e 0xff58 0xff58 0x40437b30 0x40437798 _ZTCSt14basic_ifstreamIcSt11char_traitsIcEE0_Si+32: 0x401b2ba6 0x401b2bae 0x 0x40437834 Then we add this offset to the base location of the object on the stack and we compute 0xbff01c18, instead of computing 0xbff01c20 as we would expect. It looks like the layout of the object in libstdc++.so.6 has changed, my guess is that the changes I made to the locking types in glibc have caused the layout to be perturbed. While I set out the glibc types exactly as before (binary compatible), the alignment restrictions were changed subtly. Excellent debugging! Dave -- J. David Anglin dave.ang...@nrc-cnrc.gc.ca National Research Council of Canada (613) 990-0752 (FAX: 952-6602) -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#554574: libstdc++6: apt segfaults on hppa
On Sun, Nov 22, 2009 at 5:05 PM, John David Anglin d...@hiauly1.hia.nrc.ca wrote: While I set out the glibc types exactly as before (binary compatible), the alignment restrictions were changed subtly. Excellent debugging! I have adjusted the glibc lock structure alignments to try and match more accurately the original alignment restrictions. I have built a glibc with the new headers, and installed that into my test system. I'm now rebuilding libstdc++6 against the new headers to determine if this fixes the problem. I will have results by tomorrow. Cheers, Carlos. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#554574: libstdc++6: apt segfaults on hppa
On Fri, Nov 20, 2009 at 07:00:26PM -0600, Matthias Klose wrote: On 20.11.2009 16:44, Carlos O'Donell wrote: On Fri, Nov 20, 2009 at 10:31 AM, Aurelien Jarnoaurel...@aurel32.net wrote: Domenico Andreoli a écrit : On Thu, Nov 05, 2009 at 06:47:11PM +0100, Domenico Andreoli wrote: On Thu, Nov 5, 2009 at 5:43 PM, Matthias Klosed...@debian.org wrote: On 05.11.2009 14:30, Domenico Andreoli wrote: frankly i do not know what to do next, besides trying to rebuild gcc-4.4 4.4.2-1 with latest eglibc to see if it is the culprit or rebuild against eglibc-2.9. could you do this as a test? yes, build started the gcc 4.4.2-2 built with eglibc 2.9-25 has not the problem and current gcc 4.4.2-1 is built with eglibc 2.9-26 [0]. should i try building 4.4.2-1 with eglibc 2.10.1-5 or are we convinced it is NPTL? At least we are convinced it's eglibc 2.10.1, not 100% sure it is due to NPTL. I have done some more tests, showing it's a bit more complicated than that. apt-get from stable/testing/unstable: - works with libstdc++6 built against eglibc 2.9 - segfaults with libstdc++6 built against eglibc 2.10.1 Then I tried to rebuild apt against the broken libstdc++6. Surprisingly this new apt-get: - works with libstdc++6 built against eglibc 2.10.1 - segfaults with libstdc++6 built against eglibc 2.9 So in short, it seems that using eglibc 2.10.1 to build libstdc++6 triggers an ABI change on this library. I haven't investigated more for now, I am not sure when I'll have time to do it. This is not surprising, Dave has already pointed out that the debian libstdc++6 testsuite run clearly has an ABI failure e.g. ~~~ FAIL: abi_check ~~~ I don't have a build around, but isn't this due to the one symbol accidentally exported in an earlier libstdc++ version? * Address PR libstdc++/39491, removing __signbitl from the libstdc++6 symbols file on hppa. I confirm, it's what I see in the testsuite log: | 77 | __signbitl | version status: incompatible | GLIBCXX_3.4 | type: function | status: added -- Aurelien Jarno GPG: 1024D/F1BCDB73 aurel...@aurel32.net http://www.aurel32.net -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#554574: libstdc++6: apt segfaults on hppa
On Sat, Nov 21, 2009 at 5:37 AM, Aurelien Jarno aurel...@aurel32.net wrote: I confirm, it's what I see in the testsuite log: | 77 | __signbitl | version status: incompatible | GLIBCXX_3.4 | type: function | status: added If __signbitl is the only failure in the abi_check, then that's easy to fix, the testsuite needs to be updated. With cloog/ppl disabled I still get 7 testsuite failures, so I'll have to dig into each failure tommorow and see what's wrong. ~~~ Running target unix FAIL: abi_check FAIL: 26_numerics/complex/13450.cc (test for excess errors) UNRESOLVED: 26_numerics/complex/13450.cc compilation failed to produce executable FAIL: 26_numerics/complex/pow.cc (test for excess errors) UNRESOLVED: 26_numerics/complex/pow.cc compilation failed to produce executable XPASS: 26_numerics/headers/cmath/c99_classification_macros_c.cc (test for excess errors) FAIL: 29_atomics/atomic_flag/clear/1.c execution test FAIL: 29_atomics/atomic_flag/test_and_set/explicit.c execution test FAIL: tr1/8_c_compatibility/complex/overloads_float.cc (test for excess errors) FAIL: tr1/8_c_compatibility/complex/overloads_int.cc (test for excess errors) UNRESOLVED: tr1/8_c_compatibility/complex/overloads_int.cc compilation failed to produce executable === libstdc++ Summary === # of expected passes5873 # of unexpected failures7 # of unexpected successes 1 # of expected failures 79 # of unresolved testcases 3 # of unsupported tests 331 ~~~ Cheers, Carlos. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#554574: libstdc++6: apt segfaults on hppa
On Sat, Nov 21, 2009 at 5:37 AM, Aurelien Jarno aurel...@aurel32.net wrote: I confirm, it's what I see in the testsuite log: | 77 | __signbitl | version status: incompatible | GLIBCXX_3.4 | type: function | status: added If __signbitl is the only failure in the abi_check, then that's easy to fix, the testsuite needs to be updated. The fail is somewhat puzzling because the problem is supposed fixed in the 4.4 branch. With cloog/ppl disabled I still get 7 testsuite failures, so I'll have to dig into each failure tommorow and see what's wrong. ~~~ Running target unix FAIL: abi_check FAIL: 26_numerics/complex/13450.cc (test for excess errors) UNRESOLVED: 26_numerics/complex/13450.cc compilation failed to produce executable FAIL: 26_numerics/complex/pow.cc (test for excess errors) UNRESOLVED: 26_numerics/complex/pow.cc compilation failed to produce executable XPASS: 26_numerics/headers/cmath/c99_classification_macros_c.cc (test for excess errors) FAIL: 29_atomics/atomic_flag/clear/1.c execution test FAIL: 29_atomics/atomic_flag/test_and_set/explicit.c execution test FAIL: tr1/8_c_compatibility/complex/overloads_float.cc (test for excess errors) FAIL: tr1/8_c_compatibility/complex/overloads_int.cc (test for excess errors) UNRESOLVED: tr1/8_c_compatibility/complex/overloads_int.cc compilation failed to produce executable Try adding --disable-libstdcxx-pch as mentioned earlier in this thread. This is PR 39355: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39355 Good luck in debugging this bug! I was not able to determine the actual cause. It appears GCC's internal data are somewhat corrupt when the pch header files are generated. This causes various tests to ICE when compiled with the pch headers. The problem appears to have gone away with head. I don't see it with hpux. Dave -- J. David Anglin dave.ang...@nrc-cnrc.gc.ca National Research Council of Canada (613) 990-0752 (FAX: 952-6602) -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#554574: libstdc++6: apt segfaults on hppa
Domenico Andreoli a écrit : On Thu, Nov 05, 2009 at 06:47:11PM +0100, Domenico Andreoli wrote: On Thu, Nov 5, 2009 at 5:43 PM, Matthias Klose d...@debian.org wrote: On 05.11.2009 14:30, Domenico Andreoli wrote: frankly i do not know what to do next, besides trying to rebuild gcc-4.4 4.4.2-1 with latest eglibc to see if it is the culprit or rebuild against eglibc-2.9. could you do this as a test? yes, build started the gcc 4.4.2-2 built with eglibc 2.9-25 has not the problem and current gcc 4.4.2-1 is built with eglibc 2.9-26 [0]. should i try building 4.4.2-1 with eglibc 2.10.1-5 or are we convinced it is NPTL? At least we are convinced it's eglibc 2.10.1, not 100% sure it is due to NPTL. I have done some more tests, showing it's a bit more complicated than that. apt-get from stable/testing/unstable: - works with libstdc++6 built against eglibc 2.9 - segfaults with libstdc++6 built against eglibc 2.10.1 Then I tried to rebuild apt against the broken libstdc++6. Surprisingly this new apt-get: - works with libstdc++6 built against eglibc 2.10.1 - segfaults with libstdc++6 built against eglibc 2.9 So in short, it seems that using eglibc 2.10.1 to build libstdc++6 triggers an ABI change on this library. I haven't investigated more for now, I am not sure when I'll have time to do it. -- Aurelien Jarno GPG: 1024D/F1BCDB73 aurel...@aurel32.net http://www.aurel32.net -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#554574: libstdc++6: apt segfaults on hppa
On Fri, Nov 20, 2009 at 10:31 AM, Aurelien Jarno aurel...@aurel32.net wrote: Domenico Andreoli a écrit : On Thu, Nov 05, 2009 at 06:47:11PM +0100, Domenico Andreoli wrote: On Thu, Nov 5, 2009 at 5:43 PM, Matthias Klose d...@debian.org wrote: On 05.11.2009 14:30, Domenico Andreoli wrote: frankly i do not know what to do next, besides trying to rebuild gcc-4.4 4.4.2-1 with latest eglibc to see if it is the culprit or rebuild against eglibc-2.9. could you do this as a test? yes, build started the gcc 4.4.2-2 built with eglibc 2.9-25 has not the problem and current gcc 4.4.2-1 is built with eglibc 2.9-26 [0]. should i try building 4.4.2-1 with eglibc 2.10.1-5 or are we convinced it is NPTL? At least we are convinced it's eglibc 2.10.1, not 100% sure it is due to NPTL. I have done some more tests, showing it's a bit more complicated than that. apt-get from stable/testing/unstable: - works with libstdc++6 built against eglibc 2.9 - segfaults with libstdc++6 built against eglibc 2.10.1 Then I tried to rebuild apt against the broken libstdc++6. Surprisingly this new apt-get: - works with libstdc++6 built against eglibc 2.10.1 - segfaults with libstdc++6 built against eglibc 2.9 So in short, it seems that using eglibc 2.10.1 to build libstdc++6 triggers an ABI change on this library. I haven't investigated more for now, I am not sure when I'll have time to do it. This is not surprising, Dave has already pointed out that the debian libstdc++6 testsuite run clearly has an ABI failure e.g. ~~~ FAIL: abi_check ~~~ I'm running a build with --without-cloog/--without-ppl to see if that corrects the testsuite failures. We need to stop allowing packages to build if the testsuite runs aren't clean. Cheers, Carlos. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#554574: libstdc++6: apt segfaults on hppa
On Fri, Nov 20, 2009 at 05:44:25PM -0500, Carlos O'Donell wrote: On Fri, Nov 20, 2009 at 10:31 AM, Aurelien Jarno aurel...@aurel32.net wrote: Domenico Andreoli a écrit : On Thu, Nov 05, 2009 at 06:47:11PM +0100, Domenico Andreoli wrote: On Thu, Nov 5, 2009 at 5:43 PM, Matthias Klose d...@debian.org wrote: On 05.11.2009 14:30, Domenico Andreoli wrote: frankly i do not know what to do next, besides trying to rebuild gcc-4.4 4.4.2-1 with latest eglibc to see if it is the culprit or rebuild against eglibc-2.9. could you do this as a test? yes, build started the gcc 4.4.2-2 built with eglibc 2.9-25 has not the problem and current gcc 4.4.2-1 is built with eglibc 2.9-26 [0]. should i try building 4.4.2-1 with eglibc 2.10.1-5 or are we convinced it is NPTL? At least we are convinced it's eglibc 2.10.1, not 100% sure it is due to NPTL. I have done some more tests, showing it's a bit more complicated than that. apt-get from stable/testing/unstable: - works with libstdc++6 built against eglibc 2.9 - segfaults with libstdc++6 built against eglibc 2.10.1 Then I tried to rebuild apt against the broken libstdc++6. Surprisingly this new apt-get: - works with libstdc++6 built against eglibc 2.10.1 - segfaults with libstdc++6 built against eglibc 2.9 So in short, it seems that using eglibc 2.10.1 to build libstdc++6 triggers an ABI change on this library. I haven't investigated more for now, I am not sure when I'll have time to do it. This is not surprising, Dave has already pointed out that the debian libstdc++6 testsuite run clearly has an ABI failure e.g. ~~~ FAIL: abi_check ~~~ This test actually fails for both old and new version, I actually don't know for how long it fails. Also comparing the two versions with the extract_symvers scripts from gcc sources doesn't show any difference. Looks like the problem is a bit more complex than it seems. -- Aurelien Jarno GPG: 1024D/F1BCDB73 aurel...@aurel32.net http://www.aurel32.net -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#554574: libstdc++6: apt segfaults on hppa
On Fri, Nov 20, 2009 at 11:52:36PM +0100, Aurelien Jarno wrote: On Fri, Nov 20, 2009 at 05:44:25PM -0500, Carlos O'Donell wrote: On Fri, Nov 20, 2009 at 10:31 AM, Aurelien Jarno aurel...@aurel32.net wrote: Domenico Andreoli a écrit : On Thu, Nov 05, 2009 at 06:47:11PM +0100, Domenico Andreoli wrote: On Thu, Nov 5, 2009 at 5:43 PM, Matthias Klose d...@debian.org wrote: On 05.11.2009 14:30, Domenico Andreoli wrote: frankly i do not know what to do next, besides trying to rebuild gcc-4.4 4.4.2-1 with latest eglibc to see if it is the culprit or rebuild against eglibc-2.9. could you do this as a test? yes, build started the gcc 4.4.2-2 built with eglibc 2.9-25 has not the problem and current gcc 4.4.2-1 is built with eglibc 2.9-26 [0]. should i try building 4.4.2-1 with eglibc 2.10.1-5 or are we convinced it is NPTL? At least we are convinced it's eglibc 2.10.1, not 100% sure it is due to NPTL. I have done some more tests, showing it's a bit more complicated than that. apt-get from stable/testing/unstable: - works with libstdc++6 built against eglibc 2.9 - segfaults with libstdc++6 built against eglibc 2.10.1 Then I tried to rebuild apt against the broken libstdc++6. Surprisingly this new apt-get: - works with libstdc++6 built against eglibc 2.10.1 - segfaults with libstdc++6 built against eglibc 2.9 So in short, it seems that using eglibc 2.10.1 to build libstdc++6 triggers an ABI change on this library. I haven't investigated more for now, I am not sure when I'll have time to do it. This is not surprising, Dave has already pointed out that the debian libstdc++6 testsuite run clearly has an ABI failure e.g. ~~~ FAIL: abi_check ~~~ This test actually fails for both old and new version, I actually don't know for how long it fails. I am wrong on that, I compared squeeze and sid versions, which both fails. Here are the results for the last few versions: 4.4.1-4: fail (glibc 2.9) (squeeze) 4.4.1-5: fail (glibc 2.9) 4.4.1-6: fail (glibc 2.9) 4.4.2-1: pass (glibc 2.9) 4.4.2-2: fail (glibc 2.10) (sid) -- Aurelien Jarno GPG: 1024D/F1BCDB73 aurel...@aurel32.net http://www.aurel32.net -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#554574: libstdc++6: apt segfaults on hppa
On 20.11.2009 16:44, Carlos O'Donell wrote: On Fri, Nov 20, 2009 at 10:31 AM, Aurelien Jarnoaurel...@aurel32.net wrote: Domenico Andreoli a écrit : On Thu, Nov 05, 2009 at 06:47:11PM +0100, Domenico Andreoli wrote: On Thu, Nov 5, 2009 at 5:43 PM, Matthias Klosed...@debian.org wrote: On 05.11.2009 14:30, Domenico Andreoli wrote: frankly i do not know what to do next, besides trying to rebuild gcc-4.4 4.4.2-1 with latest eglibc to see if it is the culprit or rebuild against eglibc-2.9. could you do this as a test? yes, build started the gcc 4.4.2-2 built with eglibc 2.9-25 has not the problem and current gcc 4.4.2-1 is built with eglibc 2.9-26 [0]. should i try building 4.4.2-1 with eglibc 2.10.1-5 or are we convinced it is NPTL? At least we are convinced it's eglibc 2.10.1, not 100% sure it is due to NPTL. I have done some more tests, showing it's a bit more complicated than that. apt-get from stable/testing/unstable: - works with libstdc++6 built against eglibc 2.9 - segfaults with libstdc++6 built against eglibc 2.10.1 Then I tried to rebuild apt against the broken libstdc++6. Surprisingly this new apt-get: - works with libstdc++6 built against eglibc 2.10.1 - segfaults with libstdc++6 built against eglibc 2.9 So in short, it seems that using eglibc 2.10.1 to build libstdc++6 triggers an ABI change on this library. I haven't investigated more for now, I am not sure when I'll have time to do it. This is not surprising, Dave has already pointed out that the debian libstdc++6 testsuite run clearly has an ABI failure e.g. ~~~ FAIL: abi_check ~~~ I don't have a build around, but isn't this due to the one symbol accidentally exported in an earlier libstdc++ version? * Address PR libstdc++/39491, removing __signbitl from the libstdc++6 symbols file on hppa. I'm running a build with --without-cloog/--without-ppl to see if that corrects the testsuite failures. I doubt it; this only enables optimization options which are not turned on by default and not used to build g++/libstdc++. The Debian packages for ppl and cloog and ppl pass the testsuites on all archs. if you know of further tests which could be run in Debian, please let me know. We need to stop allowing packages to build if the testsuite runs aren't clean. yes, or run the testsuite at all (for hppa64-linux-gnu). I'll look into re-enabling checks, but in the past the existing comparision checks are either not working or unreliable for bi/triarch builds. Matthias PS: offline for the next week -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#554574: libstdc++6: apt segfaults on hppa
On 08.11.2009 21:38, John David Anglin wrote: test results for 4.4.2-1: http://gcc.gnu.org/ml/gcc-testresults/2009-10/msg01919.html for 4.4.2-2: http://gcc.gnu.org/ml/gcc-testresults/2009-11/msg00351.html there are some differences, which are not seen in Dave's build: http://gcc.gnu.org/ml/gcc-testresults/2009-11/msg00047.html For a release, I wouldn't use cloog/ppl. It seems to cause some loop optimization bugs. does this really hurt, unless the loop opts are used? Compare above with http://gcc.gnu.org/ml/gcc-testresults/2009-11/msg00812.html Dave -- J. David Anglin dave.ang...@nrc-cnrc.gc.ca National Research Council of Canada (613) 990-0752 (FAX: 952-6602) -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#554574: libstdc++6: apt segfaults on hppa
test results for 4.4.2-1: http://gcc.gnu.org/ml/gcc-testresults/2009-10/msg01919.html for 4.4.2-2: http://gcc.gnu.org/ml/gcc-testresults/2009-11/msg00351.html there are some differences, which are not seen in Dave's build: http://gcc.gnu.org/ml/gcc-testresults/2009-11/msg00047.html For a release, I wouldn't use cloog/ppl. It seems to cause some loop optimization bugs. There's also an unresolved issue with pch on the 4.4 branch. I usually configure with --disable-libstdcxx-pch on the 4.4 branch. The problem seems to be fixed on head. there are some parisc scpecific changes: 2009-10-23 John David Anglin dave.ang...@nrc-cnrc.gc.ca Backport from mainline: 2009-08-19 John David Anglin dave.ang...@nrc-cnrc.gc.ca * pa.md (reload_inhi, reload_outhi, reload_inqi, reload_outqi): New patterns. * pa.c (emit_move_sequence): Check if address of operand1 is valid for mode mode of operand0 when doing secondary reload for SAR. 2009-10-20 John David Anglin dave.ang...@nrc-cnrc.gc.ca Backport from mainline: 2009-10-15 John David Anglin dave.ang...@nrc-cnrc.gc.ca PR target/41702 * pa.md (casesi): Use sign extended index in call to gen_casesi64p. (casesi64p): Update pattern to reflect above. I doubt either of these is the problem. The latter is specific to hppa64. The former is to fix an ICE compiling recent linux kernels. Dave -- J. David Anglin dave.ang...@nrc-cnrc.gc.ca National Research Council of Canada (613) 990-0752 (FAX: 952-6602) -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#554574: libstdc++6: apt segfaults on hppa
On 08.11.2009 21:38, John David Anglin wrote: test results for 4.4.2-1: http://gcc.gnu.org/ml/gcc-testresults/2009-10/msg01919.html for 4.4.2-2: http://gcc.gnu.org/ml/gcc-testresults/2009-11/msg00351.html there are some differences, which are not seen in Dave's build: http://gcc.gnu.org/ml/gcc-testresults/2009-11/msg00047.html For a release, I wouldn't use cloog/ppl. It seems to cause some loop optimization bugs. does this really hurt, unless the loop opts are used? There's also an unresolved issue with pch on the 4.4 branch. I usually configure with --disable-libstdcxx-pch on the 4.4 branch. The problem seems to be fixed on head. ok, I'll add this for hppa. Matthias -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#554574: libstdc++6: apt segfaults on hppa
On 08.11.2009 21:38, John David Anglin wrote: test results for 4.4.2-1: http://gcc.gnu.org/ml/gcc-testresults/2009-10/msg01919.html for 4.4.2-2: http://gcc.gnu.org/ml/gcc-testresults/2009-11/msg00351.html there are some differences, which are not seen in Dave's build: http://gcc.gnu.org/ml/gcc-testresults/2009-11/msg00047.html For a release, I wouldn't use cloog/ppl. It seems to cause some loop optimization bugs. does this really hurt, unless the loop opts are used? The testsuite fails that seem related to this are: FAIL: libgomp.c/omp-loop03.c execution test FAIL: libgomp.c++/loop-3.C -O execution test FAIL: 29_atomics/atomic_flag/clear/1.c execution test FAIL: 29_atomics/atomic_flag/test_and_set/explicit.c execution test FAIL: tr1/8_c_compatibility/complex/overloads_float.cc (test for excess errors) FAIL: tr1/8_c_compatibility/complex/overloads_int.cc (test for excess errors) and possibly FAIL: abi_check There's also an unresolved issue with pch on the 4.4 branch. I usually configure with --disable-libstdcxx-pch on the 4.4 branch. The problem seems to be fixed on head. ok, I'll add this for hppa. The testsuite fails related to the pch bug are: FAIL: 26_numerics/complex/13450.cc (test for excess errors) FAIL: 26_numerics/complex/pow.cc (test for excess errors) Dave -- J. David Anglin dave.ang...@nrc-cnrc.gc.ca National Research Council of Canada (613) 990-0752 (FAX: 952-6602) -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#554574: libstdc++6: apt segfaults on hppa
On Thu, Nov 05, 2009 at 06:47:11PM +0100, Domenico Andreoli wrote: On Thu, Nov 5, 2009 at 5:43 PM, Matthias Klose d...@debian.org wrote: On 05.11.2009 14:30, Domenico Andreoli wrote: frankly i do not know what to do next, besides trying to rebuild gcc-4.4 4.4.2-1 with latest eglibc to see if it is the culprit or rebuild against eglibc-2.9. could you do this as a test? yes, build started the gcc 4.4.2-2 built with eglibc 2.9-25 has not the problem and current gcc 4.4.2-1 is built with eglibc 2.9-26 [0]. should i try building 4.4.2-1 with eglibc 2.10.1-5 or are we convinced it is NPTL? in case anyone is interested, the binaries and the build log are here: https://mnl.crema.unimi.it/~cavok/gcc-4.4_4.4.2-2 regards, Domenico [0] https://buildd.debian.org/fetch.cgi?pkg=gcc-4.4ver=4.4.2-1arch=hppastamp=1255927737file=log -[ Domenico Andreoli, aka cavok --[ http://www.dandreoli.com/gpgkey.asc ---[ 3A0F 2F80 F79C 678A 8936 4FEE 0677 9033 A20E BC50 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
