Bash Segmentation fault within lastpipe mode
Configuration Information [Automatically generated, do not change]:
Machine: x86_64
OS: linux-gnu
Compiler: gcc
Compilation CFLAGS: -DPROGRAM='bash' -DCONF_HOSTTYPE='x86_64'
-DCONF_OSTYPE='linux-gnu' -DCONF_MACHTYPE='x86_64-pc-linux-gnu'
-DCONF_VENDOR='pc' -DLOCALEDIR='/usr/share/locale' -DPACKAGE='bash' -DSHELL
-DHAVE_CONFIG_H -I. -I../bash -I../bash/include -I../bash/lib
-D_FORTIFY_SOURCE=2 -g -O2 -fstack-protector --param=ssp-buffer-size=4 -Wformat
-Werror=format-security -Wall
uname output: Linux PCM14 3.11.0-12-generic #19-Ubuntu SMP Wed Oct 9 16:20:46
UTC 2013 x86_64 x86_64 x86_64 GNU/Linux
Machine Type: x86_64-pc-linux-gnu
Bash Version: 4.2
Patch Level: 45
Release Status: release
Description:
in case use overwrite variables within "while loop" in lastpipe mode i get
"Segmentation fault"
## example script ##
#!/bin/bash
shopt -s lastpipe
allUsersArray=( a b c d e d g)
allActiveArray=( a b )
allSuspendArray=( ${allUsersArray[@]} )
for i in ${!allSuspendArray[@]}
do
echo ${i} ${allSuspendArray[${i}]} |
while read _USER_ID _USER_NAME
do
for _activeUser in ${allActiveArray[@]}
do
echo ${_activeUser} |
grep -E "^${_USER_NAME}$" && unset allSuspendArray[${_USER_ID}]
done
done
done
echo allUsersArray ${!allUsersArray[@]}
echo allSuspendArray ${!allSuspendArray[@]}
## END example script ##
## trace ##
bash -x ts.sh
+ shopt -s lastpipe
+ allUsersArray=(a b c d e d g)
+ allActiveArray=(a b)
+ allSuspendArray=(${allUsersArray[@]})
+ for i in '${!allSuspendArray[@]}'
+ read _USER_ID _USER_NAME
+ echo 0 a
+ for _activeUser in '${allActiveArray[@]}'
+ grep -E '^a$'
+ echo a
a
+ for _activeUser in '${allActiveArray[@]}'
+ grep -E '^a$'
+ echo b
+ read _USER_ID _USER_NAME
Segmentation fault
## END trace ##
Re: Bash Segmentation fault within lastpipe mode
On 6/19/14, 4:43 AM, scorp.dev.n...@gmail.com wrote: > Bash Version: 4.2 > Patch Level: 45 > Release Status: release > > Description: > > in case use overwrite variables within "while loop" in lastpipe mode i get > "Segmentation fault" Thanks for the report. The lastpipe code needs to be more careful checking whether or not the jobs list has not been modified. I've attached a patch to bash-4.3 that fixes the problem. Chet -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, ITS, CWRUc...@case.eduhttp://cnswww.cns.cwru.edu/~chet/ *** ../bash-4.3-patched/execute_cmd.c 2014-01-31 10:54:52.0 -0500 --- execute_cmd.c 2014-06-19 08:05:49.0 -0400 *** *** 2410,2414 lstdin = wait_for (lastpid); #if defined (JOB_CONTROL) ! exec_result = job_exit_status (lastpipe_jid); #endif unfreeze_jobs_list (); --- 2425,2438 lstdin = wait_for (lastpid); #if defined (JOB_CONTROL) ! /* If wait_for removes the job from the jobs table, use result of last ! command as pipeline's exit status as usual. The jobs list can get ! frozen and unfrozen at inconvenient times if there are multiple pipelines ! running simultaneously. */ ! if (INVALID_JOB (lastpipe_jid) == 0) ! exec_result = job_exit_status (lastpipe_jid); ! else if (pipefail_opt) ! exec_result = exec_result | lstdin; /* XXX */ ! /* otherwise we use exec_result */ ! #endif unfreeze_jobs_list ();
Re: dotgob+extglob bug
On 6/9/14, 3:42 PM, Ian Kelling wrote: > > Running this script with your own bash path demonstrates the bug. > > #!/home/ian/opt/bash/bash --norc > shopt -s extglob > shopt -s dotglob > cd $(mktemp -d) > mkdir a > touch a/.b > touch a/c > echo a/!(.b) > > output: > a/. a/.. a/c > > this happens with all bash versions 4.3+ (latest is patch 18). Yes, it's an interesting question: what exactly does pattern negation include? You can match all filenames beginning with a `.' by using `.' as the first character of the pattern, so should a negated pattern beginning with a `.' match all filenames beginning with a `.' that don't match that particular pattern? The bash-4.3 implementation says yes. (FWIW, ksh93 disagrees.) > before that, the output is: > > a/c Yes, bash-4.2 had real problems with pattern negation (all extglob patterns, really) and files beginning with `.'. So much so that it failed to generate any matches for *(.*), which is just totally wrong. > Another related bug. man bash states: > > The file names ``.'' and ``..'' are always ignored >when GLOBIGNORE is set and not null. > > Which clearly implies that . and .. should not be ignored in some other > case. Sure. One is that they're not ignored when the pattern begins with a `.'. For instance, using .* as the pattern with the above directory contents expands to ". .. .b c". > Well, that was not true before 4.3 Absolutely it was true before bash-4.3. , but I'm guess this new > behavior is a bug, and the doc is a bug, since the doc hasn't changed, > and setting GLOBIGNORE doesn't actually make . and .. be ignored. Of course it does. When GLOBIGNORE is set to something that's not a null value (say, GLOBIGNORE=a) , echo .* in a directory with the contents as above expands to ".b c", echo !(.*) expands to "c", and echo *(.*) expands to ".b". Chet -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, ITS, CWRUc...@case.eduhttp://cnswww.cns.cwru.edu/~chet/
Re: Possible bug when combining Bash's process substitution with HERE-document?
Hi, first I want to thank you for your help. While searching for an alternative I came up with the following code which does not work when I have the "shopt -os errexit" command line at the top of my script: read -d '' -r foobar <: > On 6/18/14, 4:27 PM, Dan Douglas wrote: >> On Wed, Jun 18, 2014 at 2:49 PM, Chet Ramey wrote: >>> Yes, since bash can parse the same construct without any problems if you >>> use command substitution, it looks like a bug. I'll take a look. >> >> It brings to mind all those unbalanced paren case..esac bugs that >> affected every shell ever. >> I suppose this might qualify as a bug too? > > Yes, with the same fix. > > Chet > > -- > ``The lyf so short, the craft so long to lerne.'' - Chaucer > ``Ars longa, vita brevis'' - Hippocrates > Chet Ramey, ITS, CWRUc...@case.eduhttp://cnswww.cns.cwru.edu/~chet/
Re: dot gob+extglob bug
Chet Ramey writes: > On 6/9/14, 3:42 PM, Ian Kelling wrote: > Yes, it's an interesting question: what exactly does pattern negation > include? You can match all filenames beginning with a `.' by using `.' > as the first character of the pattern, so should a negated pattern > beginning with a `.' match all filenames beginning with a `.' that don't > match that particular pattern? The bash-4.3 implementation says yes. > (FWIW, ksh93 disagrees.) Yes, now I understand. I agree with this bash 4.3 behavior. As you pointed out, some of my comments about past bash were wrong. Thank you. Now I think I have I have explored properly the latest version and found some problems I did not fully see before: The doc says "When matching a pathname, the slash character must always be matched explicitly." Shortly thereafter, in the next paragraph of the same section, GLOBIGNORE is described, which does not treat / as special, but this is not mentioned, and is very unexpected to me. Closer inspection, I see same language "filenames matching a pattern" is used in both paragraphs, so I think some clarification is needed. # example: / matters to GLOBIGNORE ~/opt/bash (master) $ ./bash --norc bash-4.3$ cd $(mktemp -d) bash-4.3$ touch a bash-4.3$ GLOBIGNORE=a bash-4.3$ echo * * bash-4.3$ echo ./* ./a # another example of the same phenomenon bash-4.3$ GLOBIGNORE='*a' bash-4.3$ echo ./* ./* And then, this definitely seems like a bug: * matches / in GLOGIGNORE, and so does [/], but ? does not match / # example: ? does not match "/" bash-4.3$ GLOBIGNORE=.?a bash-4.3$ echo ./* ./a # example: ? does match "x" bash-4.3$ touch .xa bash-4.3$ echo .x* .x* # example: [/] matches "/" bash-4.3$ GLOBIGNORE=.[/]a bash-4.3$ echo ./* ./.xa And then, another bug or doc clarification. The various [:class:] forms don't seem to work at all in GLOBIGNORE. Side note, I've added to my bashrc: GLOBIGNORE=*/.:*/..
Re: Possible bug when combining Bash's process substitution with HERE-document?
On Jun 19, 2014 5:00 PM, "Tim Friske" wrote: > > Hi, > > first I want to thank you for your help. > > While searching for an alternative I came up with the following code > which does not work when I have the "shopt -os errexit" command line > at the top of my script: > > read -d '' -r foobar < bla bla > BARFOO > > When I try to explicitly return success in case read fails because of > EOF the script indefinitely waits: > > read -d '' -r foobar || true < bla bla > BARFOO > > Do you know a solution? > > Cheers > Tim > > 2014-06-18 22:35 GMT+02:00 Chet Ramey : > > On 6/18/14, 4:27 PM, Dan Douglas wrote: > >> On Wed, Jun 18, 2014 at 2:49 PM, Chet Ramey wrote: > >>> Yes, since bash can parse the same construct without any problems if you > >>> use command substitution, it looks like a bug. I'll take a look. > >> > >> It brings to mind all those unbalanced paren case..esac bugs that > >> affected every shell ever. > >> I suppose this might qualify as a bug too? > > > > Yes, with the same fix. > > > > Chet > > > > -- > > ``The lyf so short, the craft so long to lerne.'' - Chaucer > > ``Ars longa, vita brevis'' - Hippocrates > > Chet Ramey, ITS, CWRUc...@case.edu http://cnswww.cns.cwru.edu/~chet/ > Yes. Never use errexit. Use proper error handling.
