Re: errexit inconsistent behaviour with pipelines
Marcin Owsiany wrote: > I expected that if a simple pipeline failure causes the shell to exit, and a > simple for loop failure causes it to exit, then a failure in their > combination would also cause an exit. However it is not so. You've found a probable bug, but it's not where you think. Each element of a pipeline is run in a separate execution environment and a separate process. Even if the child process inherits the errexit flag, the fact that false returns failure should not affect the parent shell: a pipeline is not a simple command. You can see this by adding another process to the pipeline: set -e true | false | echo final echo after In all cases, `final' and `after' are both displayed. This bug only occurs when errexit is enabled and the final element of a pipeline is a simple command that returns a non-zero exit status. I will devise a fix for the next bash release. Chet -- ``The lyf so short, the craft so long to lerne.'' - Chaucer Chet Ramey, ITS, CWRU[EMAIL PROTECTED]http://cnswww.cns.cwru.edu/~chet/
"Display all XXX possibilities" bug - bash, readline or something else?
I was going about my business one day when I executed the following steps in order without meaning to: 1. Caused the "Display all XXX possibilities? (y or n)" message to appear 2. Resized the window 3. Noticed that the message disappeared, but the acceptance of y or n (and only y or n, save ^C of course) was still in effect. So, I first started out by posting a message to my distro's forum, and got a pile of confirmations with a bunch of different terminals. The post is here: http://bbs.archlinux.org/viewtopic.php?pid=429633 I'd say this was an official bug, and needs to be fixed. -dav7
Re: bash cores if nscd disabled on Solaris LDAP sasl/gssapi client
Hi Chet, thanks for the quick answer. More in-line: On 10/ 3/08 10:52 PM, Chet Ramey wrote: Serge Dussud - Sun Microsystems wrote: Hello bug-bash, please find attached a bashbug report. I am not sure how to follow-up then, could you advise ? This is the appropriate venue for these reports. I have a few questions OK. about this one. 1. The trace shows that the process is not, in fact, using the bash malloc when it dies. The traced _malloc_unlocked and cleanfree functions are not in the bash malloc, but are present in libc. ff137068 sigacthandler (efe08, f706, 0, f8ca0, 0, 0) --- called from signal handler with signal 982536 (SIG Unknown) --- ff0e62a4 cleanfree (0, 8, ff1e64f8, ff1de63c, f83ec, 2) + 58 ff0e53d8 _malloc_unlocked (20, f7065554, efe00, f706, ff1e0468, ffdf) + 104 ff0e52b8 malloc (20, 0, 1, ff1de63c, f93c8, ff1e4864) + 48 I saw that, still, when I tried to analyze the core some while back, I had the feeling that debugger (mdb at the time ?) was confused with these malloc routines. That's when I realized about the malloc bash internal routines and tried compiling with --witthou-bash-malloc. 2. What library installs the `sigacthandler'? It's not a function in bash. It is a symbol in libc, but there's no indication which library installs it as a signal handler. I have just tried psig on on running bash (in another config), and see that the function that set signals handler for SIGV is indeed: bash-3.2# pgrep bash 16384 bash-3.2# psig 16384 | grep "^SEGV" SEGVblocked,caught termsig_sighandler 0 HUP,INT,ILL,TRAP,ABRT,EMT,FPE,BUS,SEGV,SYS,PIPE,ALRM,TERM,USR1,USR2,VTALRM,XCPU,XFSZ,LOST bash-3.2# termsig_sighandler() is part bash source code (sig.c) if I am not mistaken. 3. What does the traceback look like when bash is run under gdb and allowed to fail? I suspect that the libraries are pre-bound to use the system's malloc, and the calls to different malloc libraries are causing the core dumps. Another possibility is that libc functions are using private pseudo- global libc malloc interfaces, causing the libc malloc to be linked in. Either way, the trace and library load address maps indicate that the process is dying in the libc malloc. One way to confirm my suspicion is to start bash under gdb, set a breakpoint in malloc, and see where it stops. OK, I'll try that and come back to you. Thanks, Serge If it's documented that applications on Solaris may no longer link with their own versions of malloc, that's fine -- I can arrange things so that bash doesn't try to use it's internal malloc on Solaris 10 and 11. Chet
Re: bash cores if nscd disabled on Solaris LDAP sasl/gssapi client
> > > > 2. What library installs the `sigacthandler'? It's not a function in > > bash. It is a symbol in libc, but there's no indication which > > library installs it as a signal handler. > > > > I have just tried psig on on running bash (in another config), and see > that the function that set signals handler for SIGV is indeed: > > bash-3.2# pgrep bash > 16384 > bash-3.2# psig 16384 | grep "^SEGV" > SEGVblocked,caught termsig_sighandler 0 > HUP,INT,ILL,TRAP,ABRT,EMT,FPE,BUS,SEGV,SYS,PIPE,ALRM,TERM,USR1,USR2,VTALRM,XCPU,XFSZ,LOST > bash-3.2# > > termsig_sighandler() is part bash source code (sig.c) if I am not mistaken. It is, but that's not what shows up in the call trace. Is `sigacthandler' part of the Solaris signal trampoline code? Chet -- ``The lyf so short, the craft so long to lerne.'' - Chaucer Chet Ramey, ITS, CWRU[EMAIL PROTECTED]http://tiswww.tis.case.edu/~chet/
Re: bash cores if nscd disabled on Solaris LDAP sasl/gssapi client
On 10/ 6/08 05:11 PM, Chet Ramey wrote: 2. What library installs the `sigacthandler'? It's not a function in bash. It is a symbol in libc, but there's no indication which library installs it as a signal handler. I have just tried psig on on running bash (in another config), and see that the function that set signals handler for SIGV is indeed: bash-3.2# pgrep bash 16384 bash-3.2# psig 16384 | grep "^SEGV" SEGVblocked,caught termsig_sighandler 0 HUP,INT,ILL,TRAP,ABRT,EMT,FPE,BUS,SEGV,SYS,PIPE,ALRM,TERM,USR1,USR2,VTALRM,XCPU,XFSZ,LOST bash-3.2# termsig_sighandler() is part bash source code (sig.c) if I am not mistaken. It is, but that's not what shows up in the call trace. Is `sigacthandler' part of the Solaris signal trampoline code? it's part of libc, sigaction() related code as far as I can tell: http://src.opensolaris.org/source/xref/onnv/onnv-gate/usr/src/lib/libc/port/threads/sigaction.c#283 I am not very familiar with this part of Solaris code to be honest. Serge Chet
Re: errexit inconsistent behaviour with pipelines
On Mon, Oct 06, 2008 at 09:22:30AM -0400, Chet Ramey wrote: > Marcin Owsiany wrote: > > > I expected that if a simple pipeline failure causes the shell to exit, and > > a simple for loop failure causes it to exit, then a failure in their > > combination would also cause an exit. However it is not so. > > You've found a probable bug, but it's not where you think. Each element > of a pipeline is run in a separate execution environment and a separate > process. Even if the child process inherits the errexit flag, the fact > that false returns failure should not affect the parent shell: a pipeline > is not a simple command. You can see this by adding another process to > the pipeline: > > set -e > true | false | echo final > echo after > > In all cases, `final' and `after' are both displayed. Yes, I am aware that only the exit status of the last process in the pipeline is ever propagated to the parent shell (unless you set pipefail, in which case your example above will only print "final" and not "after"). By the way - is pipefail a new thing? I only noticed this last week, and I'm using bash for almost a decade :-) > This bug only occurs when errexit is enabled and the final element of a > pipeline is a simple command that returns a non-zero exit status. Well, if the final element in the pipeline is a simple command, all works as is supposed to. When it's a-not-so-simple command, like a for or while loop, then it does not terminate the parent. > I will devise a fix for the next bash release. Great, thanks! Marcin -- Marcin Owsiany <[EMAIL PROTECTED]> http://marcin.owsiany.pl/ GnuPG: 1024D/60F41216 FE67 DA2D 0ACA FC5E 3F75 D6F6 3A0D 8AA0 60F4 1216 "Every program in development at MIT expands until it can read mail." -- Unknown
Re: errexit inconsistent behaviour with pipelines
Marcin Owsiany <[EMAIL PROTECTED]> wrote: > On Mon, Oct 06, 2008 at 09:22:30AM -0400, Chet Ramey wrote: >> This bug only occurs when errexit is enabled and the final element of a >> pipeline is a simple command that returns a non-zero exit status. > > Well, if the final element in the pipeline is a simple command, all > works as is supposed to. No. It works the way you want it to, but not the way SUS says it should. > When it's a-not-so-simple command, like a for or while loop, then it > does not terminate the parent. That's the case that's behaving correctly, even though it's not the way you want it to behave. Neither case should terminate the shell. Only a simple command should terminate the shell, and a pipeline is not a simple command, even if its components are. Chet is saying that the next bash release will fix this bug - meaning that "true | false" will no longer cause the shell to exit. paul
Re: errexit inconsistent behaviour with pipelines
> That's the case that's behaving correctly, even though it's not the > way you want it to behave. Neither case should terminate the shell. > Only a simple command should terminate the shell, and a pipeline is > not a simple command, even if its components are. Chet is saying that > the next bash release will fix this bug - meaning that "true | false" > will no longer cause the shell to exit. Yes. I'm sorry that I was not as clear as I should have been. Chet -- ``The lyf so short, the craft so long to lerne.'' - Chaucer Chet Ramey, ITS, CWRU[EMAIL PROTECTED]http://tiswww.tis.case.edu/~chet/
Re: errexit inconsistent behaviour with pipelines
On Mon, Oct 06, 2008 at 04:09:49PM -0400, Chet Ramey wrote: > > That's the case that's behaving correctly, even though it's not the > > way you want it to behave. Neither case should terminate the shell. > > Only a simple command should terminate the shell, and a pipeline is > > not a simple command, even if its components are. Chet is saying that > > the next bash release will fix this bug - meaning that "true | false" > > will no longer cause the shell to exit. > > Yes. I'm sorry that I was not as clear as I should have been. Oh, I certainly didn't expect it to be fixed this way :-) Will setting pipefail have any effect on this? If not, then is there a way to make bash abort when one of the pipeline components fails, without too much additional code? On the other hand, to match the documentation, you would also have to fix cases such as: set -e true && false echo done As they are not simple commands either, right? The manpage even explicitly says that it "does not exit if the command that fails is [...] part of a && or ││ list". Marcin -- Marcin Owsiany <[EMAIL PROTECTED]> http://marcin.owsiany.pl/ GnuPG: 1024D/60F41216 FE67 DA2D 0ACA FC5E 3F75 D6F6 3A0D 8AA0 60F4 1216 "Every program in development at MIT expands until it can read mail." -- Unknown
Re: errexit inconsistent behaviour with pipelines
Marcin Owsiany wrote: > On Mon, Oct 06, 2008 at 04:09:49PM -0400, Chet Ramey wrote: >>> That's the case that's behaving correctly, even though it's not the >>> way you want it to behave. Neither case should terminate the shell. >>> Only a simple command should terminate the shell, and a pipeline is >>> not a simple command, even if its components are. Chet is saying that >>> the next bash release will fix this bug - meaning that "true | false" >>> will no longer cause the shell to exit. >> Yes. I'm sorry that I was not as clear as I should have been. > > Oh, I certainly didn't expect it to be fixed this way :-) > > Will setting pipefail have any effect on this? If not, then is there a > way to make bash abort when one of the pipeline components fails, > without too much additional code? > > On the other hand, to match the documentation, you would also have to > fix cases such as: > > set -e > true && false > echo done > > As they are not simple commands either, right? The manpage even > explicitly says that it "does not exit if the command that fails is > [...] part of a && or ││ list". That's true, except every other shell behaves this way. It works for compatibility. I'm going to have to audit this stuff, at the very least. Chet -- ``The lyf so short, the craft so long to lerne.'' - Chaucer Chet Ramey, ITS, CWRU[EMAIL PROTECTED]http://cnswww.cns.cwru.edu/~chet/
Re: errexit inconsistent behaviour with pipelines
Chet Ramey wrote: >> Will setting pipefail have any effect on this? If not, then is there a >> way to make bash abort when one of the pipeline components fails, >> without too much additional code? Not easily. >> On the other hand, to match the documentation, you would also have to >> fix cases such as: >> >> set -e >> true && false >> echo done >> >> As they are not simple commands either, right? The manpage even >> explicitly says that it "does not exit if the command that fails is >> [...] part of a && or ││ list". > > That's true, except every other shell behaves this way. It works for > compatibility. I'm going to have to audit this stuff, at the very > least. I should add that it's pretty much unanimous consensus among the `major' shell implementers that this ambiguous language is a defect in the standard, and the failure of the rightmost command in an AND or OR list should cause the shell to exit. I think the current behavior, once the pipeline stuff is fixed, is pretty much correct. Chet -- ``The lyf so short, the craft so long to lerne.'' - Chaucer Chet Ramey, ITS, CWRU[EMAIL PROTECTED]http://cnswww.cns.cwru.edu/~chet/
