Re: Segmentation faults with 64bit bash on sparc64 linux
On Thu, Oct 26, 2006 at 03:25:17PM +, [EMAIL PROTECTED] wrote: > > Given the involvement of ld-linux.so.2, I tried building and using a > statically linked bash (3.2), and sure enough it does NOT exhibit the > segfaults at all. > It seems I was a bit premature here. The static bash does indeed segfault with the same symptoms: GNU gdb 6.5 Copyright (C) 2006 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "sparc64-unknown-linux-gnu". (gdb) file /bin/sh Reading symbols from /bin/sh...(no debugging symbols found)...done. Using host libthread_db library "/pkg/glibc/lib/libthread_db.so.1". (gdb) core-file /tmp/corefiles/core Core was generated by bin/sh /home/public/sparc64/tmp/gcc-4-1.heretix/gcc-4.1.1/libiberty/configure'. Program terminated with signal 11, Segmentation fault. #0 0x00196a90 in siglongjmp () (gdb) bt #0 0x00196a90 in siglongjmp () #1 0x00205cac in _dl_signal_error () (gdb) > > Andrew Walrond ___ Bug-bash mailing list Bug-bash@gnu.org http://lists.gnu.org/mailman/listinfo/bug-bash
Re: Segmentation faults with 64bit bash on sparc64 linux
[EMAIL PROTECTED] wrote: > On Thu, Oct 26, 2006 at 03:25:17PM +, [EMAIL PROTECTED] wrote: >> Given the involvement of ld-linux.so.2, I tried building and using a >> statically linked bash (3.2), and sure enough it does NOT exhibit the >> segfaults at all. >> > > It seems I was a bit premature here. The static bash does indeed > segfault with the same symptoms: OK, but knowing that helps only a little. There is still no indication of what the problem with bash might be. Since I have no 64-bit linux or sparc systems, I need a place to start. Chet -- ``The lyf so short, the craft so long to lerne.'' - Chaucer Live Strong. No day but today. Chet Ramey, ITS, CWRU[EMAIL PROTECTED]http://cnswww.cns.cwru.edu/~chet/ ___ Bug-bash mailing list Bug-bash@gnu.org http://lists.gnu.org/mailman/listinfo/bug-bash
Re: Segmentation faults with 64bit bash on sparc64 linux
On Fri, Oct 27, 2006 at 12:42:13PM -0400, Chet Ramey wrote: > > OK, but knowing that helps only a little. There is still no indication > of what the problem with bash might be. Since I have no 64-bit linux > or sparc systems, I need a place to start. > Chet - thanks for the reply. Park this for a moment; I am nearly convinced this problem is down to the sparc64 linux kernel being miscompiled by gcc-4.1.1. I'm in the middle of running some tests using a kernel built with a patched compiler; so far, everything is working fine, but I'll let you know the outcome shortly. Andrew Walrond ___ Bug-bash mailing list Bug-bash@gnu.org http://lists.gnu.org/mailman/listinfo/bug-bash
Re: bash-3.x problems on IRIX
Matthew Woehlke wrote: Stuart Shelton wrote: The following problems exist, at the very least, in bash 3.1.16, 3.1.17, and 3.2.1 - I assume it affects the all bash-3.x releases. The hang is a different issue that seems to affect bash when built with compilers other than gcc; I can reproduce it on x86 Solaris as well as Irix with 'builtin printf "%G" 0'. The original test hangs because asprintf is seeing 0 rather than 4.2 (see below for a guess at an explanation, but more importantly the start of a fix). It's pretty nasty because it causes bash to stop responding to signals, and you have to kill it from an independent session. Chet indicated in a private e-mail that he thinks he knows what causes this one. If bash is built with the SGI MIPSpro compilers then, now matter what other CFLAGS are in affect, the test suite fails in many ways (and one of the many issues this causes is what I describe in the first posts on the above forum). [snippity snip] run-printf - at which point the test-suite hangs (and reports "Error 130" if interrupted). Looking at the contents of /tmp/xx, the output up to the point of the failure was: 0.00 0.00 0.0 0.00 0.00 0.0 -INF -inf -INF -inf ... which means that the test which causes the hang is 'printf "%G\n" 4.2'. There's clearly some broken magic here if it causes MIPSpro to generate code which hangs, and GCC to produce code which always outputs a variant of "0"! Repeat-By: Attemping to build bash-3.x on IRIX with GCC or MIPSpro, regardless of CFLAGS. Oh-oh, you're right, trying 'builtin printf "%G" 4.2' on my own Irix box just broke my login... Confirming the bug (I'm using 3.1.17) and the apparent test case. I'll also volunteer as another tester for any patches. I think I have found the problem. When I build, I get this: ld32: WARNING 110: Floating-point parameters exist in the call for "asprintf", a VARARG function, in object "./builtins/libbuiltins.a(printf.o)" without a prototype -- would result in invalid result. Definition can be found in object "./lib/sh/libsh.a(snprintf.o)" ld32: WARNING 110: Floating-point parameters exist in the call for "asprintf", a VARARG function, in object "./builtins/libbuiltins.a(printf.o)" without a prototype -- would result in invalid result. Definition can be found in object "./lib/sh/libsh.a(snprintf.o)" ld32: WARNING 110: Floating-point parameters exist in the call for "asprintf", a VARARG function, in object "./builtins/libbuiltins.a(printf.o)" without a prototype -- would result in invalid result. Definition can be found in object "./lib/sh/libsh.a(snprintf.o)" Adding 'extern int asprintf(char **stringp, const char * format, ...);' to builtins/printf.def seems to fix the bug where '0' is being passed to asprintf (using Irix's 'cc' anyway; I don't have gcc). Obviously this is not the correct place/way to fix the problem, but it seems to indicate /what/ the problem is. -- Matthew "Two IIRC's must make a right" -- Larry Hall (paraphrased) ___ Bug-bash mailing list Bug-bash@gnu.org http://lists.gnu.org/mailman/listinfo/bug-bash
Re: bash-3.x problems on IRIX
Matthew Woehlke wrote: > Chet indicated in a private e-mail that he thinks he knows what causes > this one. It's not hard to stop the hangs. The hard part is making sure you get the right answer. Chet -- ``The lyf so short, the craft so long to lerne.'' - Chaucer Live Strong. No day but today. Chet Ramey, ITS, CWRU[EMAIL PROTECTED]http://cnswww.cns.cwru.edu/~chet/ ___ Bug-bash mailing list Bug-bash@gnu.org http://lists.gnu.org/mailman/listinfo/bug-bash
