bug-bash
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Segmentation faults with 64bit bash on sparc64 linux


From: andrew
Subject: Segmentation faults with 64bit bash on sparc64 linux
Date: Thu, 26 Oct 2006 15:25:17 +0000
User-agent: Mutt/1.4.2.1i

Configuration Information [Automatically generated, do not change]:
Machine: sparc64
OS: linux-gnu
Compiler: gcc
Compilation CFLAGS:  -DPROGRAM='bash' -DCONF_HOSTTYPE='sparc64' 
-DCONF_OSTYPE='linux-gnu' -DCONF_MACHTYPE='sparc64-unknown-linux-gnu' 
-DCONF_VENDOR='unknown' -DLOCALEDIR='/pkg/bash/share/locale' -D
PACKAGE='bash' -DSHELL -DHAVE_CONFIG_H   -I.  -I. -I./include -I./lib   -g -O2
uname output: Linux spawn.secure 2.6.18.1 #1 SMP Thu Oct 19 16:38:47 BST 2006 
sparc64 GNU/Linux
Machine Type: sparc64-unknown-linux-gnu

Bash Version: 3.2
Patch Level: 1
Release Status: release

Description:
        Reproducible Segmentation fault when building large packages like
gcc, binutils, glibc etc.

        This is a 64bit bash running under linux 2.6.18.1 and the latest
glibc2.5-branch, built with gcc-4.1.1 and linux binutils 2.17.50.0.6

        The problem has been seen with bash 2.05b, 3.0, 3.1 and 3.2, all
with the official patches. Different versions seem to segfault at
different places during the (for example) gcc build, but always
reproducibly and the symtoms are similar.

As an example, during the 'make' phase of building gcc-4.1.1, the
Makefile runs various configure scripts. Here is a typical failure:

  Links are now set up to build a native compiler for sparc64-unknown-linux-gnu.
  updating cache ./config.cache
  configure: creating ./config.status
  /home/andrew/dump/gcc-4.1.1/gcc/configure: line 18008: 25581 Segmentation 
fault      (core dumped) $SHELL $CONFIG_STATUS $ac_config_status_args
  make[1]: *** [configure-gcc] Error 1
  make[1]: Leaving directory home/andrew/dump/gcc-4.1.1'
  make: *** [all] Error 2

Analysing the core file with gdb:

  andrew@spawn gcc-4.1.1 $ gdb
  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/bash
  Reading symbols from /bin/bash...(no debugging symbols found)...done.
  Using host libthread_db library "/pkg/glibc/lib/libthread_db.so.1".
  (gdb) core-file /tmp/corefiles/core
  warning: core file may not match specified executable file.
  Reading symbols from /pkg/ncurses/lib/libncurses.so.5...(no debugging symbols 
found)...done.
  Loaded symbols for /pkg/ncurses/lib/libncurses.so.5
  Reading symbols from /pkg/glibc/lib/libdl.so.2...(no debugging symbols 
found)...done.
  Loaded symbols for /pkg/glibc/lib/libdl.so.2
  Reading symbols from /pkg/glibc/lib/libc.so.6...(no debugging symbols 
found)...done.
  Loaded symbols for /pkg/glibc/lib/libc.so.6
  Reading symbols from /lib/ld-linux.so.2...(no debugging symbols found)...done.
  Loaded symbols for /lib64/ld-linux.so.2
  Core was generated by bin/sh ./config.status'.
  Program terminated with signal 11, Segmentation fault.
  #0  0xfffff801bed5e9b0 in siglongjmp () from /lib64/ld-linux.so.2
  (gdb) bt
  #0  0xfffff801bed5e9b0 in siglongjmp () from /lib64/ld-linux.so.2
  #1  0xfffff801bed55ef4 in _dl_signal_error () from /lib64/ld-linux.so.2
  (gdb)

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.

Google does not show any similar reports, but I may be peculiar in
running a pure 64bit sparc64 distro (and hence bash) since debian, ubuntu
et al run a predominately 32bit distro with 32bit bash.

I'm not entirely sure where to go next; I have temporarily solved the
issue by using a statically linked bash, but any suggestions on how to
resolve this issue would be gratefully received :)

Andrew Walrond




reply via email to

[Prev in Thread] Current Thread [Next in Thread]