The problem appears with bash-3.0-r1.ebuild installed. When running FireHOL v1.191 bash reports: FireHOL: Saving your old firewall to a temporary file: OK FireHOL: Processing file /etc/firehol/firehol.conf: FireHOL: Restoring old firewall: OK Segmentation fault I am the FireHOL developer. My understanding is that BASH 3.0 has some memory leak in it, since this situation should never happen - a BASH script should not be able to crash BASH itself. Trying to find out where to report this, I lookup for the source of BASH 3.0. The home page reported by the ebuild does not seem to provide any source for this version of BASH (see: http://ftp.gnu.org/gnu/bash/). Please advice, since BASH 3.0 should not be considered stable. Costa Tsaousis Reproducible: Always Steps to Reproduce: 1. Just run: firehol start 2. 3. Actual Results: The BASH process crashed with a segmentation fault. Expected Results: Versions prior to BASH 3.0 run FireHOL without problems.
bash isnt considered stable, that's why it's in our unstable branch atm :P if you want the source to bash, just `emerge -f bash` and it'll be in $DISTDIR (/usr/portage/distfiles/) re-open when you've provided `emerge info` like the bug report page says to also provide some example script (as basic as possible) that triggers the crash
Bellow you will find the "ebuild info" of my system. I am very sorry but I cannot create a script to reproduce the problem. I have however traced it down to the array variables management of BASH 3.0 and more specifically to the expansion: "variable[@]" This produces segmentation faults at random points within a BASH script. Other expansions, like "variable[1]" do not have problems. Only the expansion with the AT character. This means that if I try to expand variable[0], variable[1], variable[2], etc, all work perfectly, but if just bellow I place a "variable[@]", it crashes. However, when I isolated, to a separate BASH script, all the statements that manipulated the array, BASH did not crash. Therefore, I am not sure that the problem is strictly there. If something else makes BASH 3.0 corrupt its memory, it may be possible to crash at random points. --- Portage 2.0.50-r9 (default-x86-1.4, gcc-3.3.4, glibc-2.3.4.20040619-r0, 2.6.7-gentoo-r11-mppc) ================================================================= System uname: 2.6.7-gentoo-r11-mppc i686 Intel(R) Pentium(R) 4 Mobile CPU 2.00GHz Gentoo Base System version 1.5.1 Autoconf: sys-devel/autoconf-2.59-r4 Automake: sys-devel/automake-1.8.5-r1 ACCEPT_KEYWORDS="x86 ~x86" AUTOCLEAN="yes" CFLAGS="-march=pentium4 -O3 -pipe -funroll-loops -fomit-frame-pointer" CHOST="i686-pc-linux-gnu" COMPILER="gcc3" CONFIG_PROTECT="/etc /etc/tomcat5 /usr/X11R6/lib/X11/xkb /usr/kde/2/share/config /usr/kde/3.1/share/config /usr/kde/3.2/share/config /usr/kde/3.3/share/config /usr/kde/3/share/config /usr/lib/mozilla/defaults/pref /usr/share/config /usr/share/texmf/dvipdfm/config/ /usr/share/texmf/dvips/config/ /usr/share/texmf/tex/generic/config/ /usr/share/texmf/tex/platex/config/ /usr/share/texmf/xdvi/ /var/bind /var/qmail/control" CONFIG_PROTECT_MASK="/etc/gconf /etc/terminfo /etc/env.d" CXXFLAGS="-march=pentium4 -O3 -pipe -funroll-loops -fomit-frame-pointer" DISTDIR="/usr/portage/distfiles" FEATURES="autoaddcvs ccache sandbox" GENTOO_MIRRORS="ftp://files.gentoo.gr" MAKEOPTS="-j2" PKGDIR="/usr/portage/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="" SYNC="rsync://rsync.gentoo.gr/gentoo-portage" USE="X aalib acl acpi activefilter alsa apache2 apm arts avantgo avi berkdb bonobo caps cdr crypt cups curl dga directfb divx4linux doc dvd dvdr encode escreen esd etwin f77 fam fbcon firebird flac flash foomaticdb freetds gcj gd gdbm ggi gif gmp gnome gphoto2 gpm gstreamer gtk gtk2 guile icc idea imagemagick imap imlib innodb ipv6 jabber java javamail javascript jbig jpeg justify kde lcms ldap libg++ libwww lzo mad mcal md5sum mikmod mmap mmx motif mozcalendar mozilla mozp3p mozsvg mozxmlterm mpeg mysql mythtv nas ncurses network nls nptl oav objc odbc oggvorbis opengl oss pam pcmcia pda pdflib perl pic png pnp postgres pwdb python qt quicktime readline rtc samba sasl scanner sdk sdl skey slang slp snmp socks5 speex spell sse ssl svga tcltk tcpd tetex theora threads tiff truetype trusted unicode usb v4l v4l2 vhosts video_cards_radeon vim-with-x wifi wmf x86 xine xinerama xml xml2 xmms xv xvid yaz zlib"
I think I have found the bug. The script bellow crashes at the third echo (UNSET). It seems to be a problem of the "unset" BASH function when erasing arrays. It leaves something behind so that if the array just unset is referenced, it produces a segmentation fault. According to the documentation the first and the third expansions should be exactly the same. --- !/bin/sh rule() { echo "1. BEFORE SET:" "${s[@]}" local -a s=() echo "2. SET TO EMPTY:" "${s[@]}" unset s echo "3. UNSET:" "${s[@]}" } rule
Thanks Costa, confirmed here: rule() { declare -a s=(); unset s; echo "${s[@]}"; } ( rule; ) Segmentation fault #0 0x0806844f in make_bare_word (string=0x0) at make_cmd.c:90 #1 0x080685d5 in make_word (string=0x0) at make_cmd.c:141 #2 0x08094d18 in array_value_internal (s=0x81064a8 "s[@]", quoted=1, allow_all=1, rtype=0xbfffea90) at arrayfunc.c:658 #3 0x08094ea5 in array_value (s=0x81064a8 "s[@]", quoted=1, rtype=0xbfffea90) at arrayfunc.c:711 #4 0x080864fb in parameter_brace_expand_word (name=0x81064a8 "s[@]", var_is_special=0, quoted=1) at subst.c:4499 #5 0x08088b29 in parameter_brace_expand (string=0x8106400 "${s[@]}", indexp=0xbfffebac, quoted=1, quoted_dollar_atp=0xbfffec78, contains_dollar_at=0xbfffec6c) at subst.c:5596 #6 0x0808937e in param_expand (string=0x8106400 "${s[@]}", sindex=0xbfffec7c, quoted=1, expanded_something=0x0, contains_dollar_at=0xbfffec6c, quoted_dollar_at_p=0xbfffec78, had_quoted_null_p=0xbfffec70, pflags=0) at subst.c:5920 #7 0x08089bfb in expand_word_internal (word=0x81064f8, quoted=1, isexp=0, contains_dollar_at=0xbfffed3c, expanded_something=0x0) at subst.c:6260 #8 0x0808a0b9 in expand_word_internal (word=0x81064c8, quoted=0, isexp=0, contains_dollar_at=0xbfffeda8, expanded_something=0xbfffedac) at subst.c:6364 #9 0x0808b1e9 in shell_expand_word_list (tlist=0x81064e8, eflags=31) at subst.c:7215 #10 0x0808b464 in expand_word_list_internal (list=0x8105740, eflags=31) at subst.c:7332 #11 0x0808acd4 in expand_words (list=0x8105740) at subst.c:6990 #12 0x0806f77e in execute_simple_command (simple_command=0x8105718, pipe_in=-1, pipe_out=-1, async=0, fds_to_close=0x8105ad0) at execute_cmd.c:2793 #13 0x0806c10a in execute_command_internal (command=0x8105380, asynchronous=0, pipe_in=-1, pipe_out=-1, fds_to_close=0x8105ad0) at execute_cmd.c:660 #14 0x0806d68b in execute_connection (command=0x8105b30, asynchronous=0, pipe_in=-1, pipe_out=-1, fds_to_close=0x8105ad0) at execute_cmd.c:1505 #15 0x0806c411 in execute_command_internal (command=0x8105b30, asynchronous=0, pipe_in=-1, pipe_out=-1, fds_to_close=0x8105ad0) at execute_cmd.c:820 #16 0x0806c3e2 in execute_command_internal (command=0x8105c58, asynchronous=0, pipe_in=-1, pipe_out=-1, fds_to_close=0x8105ad0) at execute_cmd.c:812 #17 0x080704ff in execute_function (var=0x8105e18, words=0x8105b20, flags=0, fds_to_close=0x8105ad0, async=0, subshell=0) at execute_cmd.c:3249 #18 0x080708e1 in execute_builtin_or_function (words=0x8105b20, builtin=0, var=0x8105e18, redirects=0x0, fds_to_close=0x8105ad0, flags=0) at execute_cmd.c:3437 #19 0x0806fc11 in execute_simple_command (simple_command=0x8105ce8, pipe_in=-1, pipe_out=-1, async=0, fds_to_close=0x8105ad0) at execute_cmd.c:2950 #20 0x0806c10a in execute_command_internal (command=0x8105d70, asynchronous=0, pipe_in=-1, pipe_out=-1, fds_to_close=0x8105ad0) at execute_cmd.c:660 #21 0x0806bae2 in execute_command (command=0x8105d70) at execute_cmd.c:347 #22 0x0805e957 in reader_loop () at eval.c:146 #23 0x0805c9b0 in main (argc=2, argv=0xbffff294, env=0xbffff2a0) at shell.c:704 Pushing this upstream
I've filed a bug with the bash maintainers about this. Hopefully it will be fixed soon.
http://lists.gnu.org/archive/html/bug-bash/2004-08/msg00011.html
Fixed in bash-3.0-r4, thanks See also http://article.gmane.org/gmane.comp.shells.bash.bugs/4113
