RE: Issue with Bash
Hi All, We have been able to recreate a scenario where bash dumps core immediately on issuing a SIGHUP to the parent process (kill -1 ). On debugging, the core so generated shows exactly the same stack trace as we had seen with the previous core. Below is the truss output of bash process when the parent process of bash (ksh, in this case) gets a SIGHUP: _select(0, 0x, 0x, 0x, 0x) (sleeping...) _select(0, 0x, 0x, 0x, 0x) Err#4 EINTR Received signal #1, SIGHUP [caught] ksetcontext_sigreturn(0x0FFFBB90, 0x, 0x0FFFBB90, 0xF0002FF48000, 0x00010002AEDC, 0xA000D032, 0x, 0x000110005CB0) = 0x0004 ksetcontext_sigreturn(0x0FFFBB90, 0x0004, 0x0FE0, 0x8000D032, 0x3B98, 0x, 0xF1000C01C2D9F000, 0x80001032) Received signal #1, SIGHUP [caught] ksetcontext_sigreturn(0x0FFFBB90, 0x, 0x0FFFBB90, 0xF0002FF48000, 0x00010002AEDC, 0xA000D032, 0x, 0x000110005CB0) kfcntl(2, F_GETFL, 0x) = 67110914 kioctl(2, 536900718, 0x, 0x) = 0 kfcntl(2, F_GETFL, 0x0FE8) = 67110914 kioctl(0, 22528, 0x, 0x) = 0 kioctl(0, 21507, 0x000110013AF8, 0x) Err#25 ENOTTY Received signal #1, SIGHUP [caught] ksetcontext_sigreturn(0x0FFFD930, 0x, 0x0FFFD930, 0xF0002FF48000, 0x00010002AEDC, 0xA000D032, 0x, 0x000110005CB0) kfcntl(2, F_GETFL, 0x) = 67110914 kioctl(2, 536900718, 0x, 0x) = 0 kfcntl(2, F_GETFL, 0x0FE8) = 67110914 kioctl(0, 22528, 0x, 0x) = 0 kioctl(0, 21507, 0x000110013AF8, 0x) Err#25 ENOTTY Received signal #1, SIGHUP [caught] ksetcontext_sigreturn(0x0FFFD780, 0x, 0x0FFFD780, 0xF0002FF48000, 0x00010002AEDC, 0xA000D032, 0x, 0x000110005CB0) kfcntl(2, F_GETFL, 0x) = 67110914 kioctl(2, 536900718, 0x, 0x) = 0 kfcntl(2, F_GETFL, 0x0FE8) = 67110914 kioctl(0, 22528, 0x, 0x) = 0 kioctl(0, 21507, 0x000110013AF8, 0x) Err#25 ENOTTY Received signal #1, SIGHUP [caught] ksetcontext_sigreturn(0x0FFFD5D0, 0x, 0x0FFFD5D0, 0xF0002FF48000, 0x00010002AEDC, 0xA000D032, 0x, 0x000110005CB0) kfcntl(2, F_GETFL, 0x) = 67110914 kioctl(2, 536900718, 0x, 0x) = 0 kfcntl(2, F_GETFL, 0x0FE8) = 67110914 kioctl(0, 22528, 0x, 0x) = 0 kioctl(0, 21507, 0x000110013AF8, 0x) Err#25 ENOTTY As I can see from the truss output, once bash gets SIGHUP it tries to do some terminal related stuff but now since the terminal is gone, it throws ENOTTY which is normal. But the problem here is, it keeps getting SIGHUP repeatedly and does the same thing again and again, finally running out of stack or the OS kills the process. Thanks and Regards, Rishita Saha - Original message - From: Chet Ramey To: Rishita Saha16 Cc: chet.ra...@case.edu, bug-bash@gnu.org Subject: [EXTERNAL] Re: Issue with Bash Date: Mon, Jul 20, 2020 6:29 PM On 7/20/20 2:32 AM, Rishita Saha16 wrote: > Hi All, > > From what we have found out, it does not seem like the signal is SIGTTOU. > We are working to find out more about it. Meanwhile, any insight would be > helpful. If the process isn't an interactive shell, it would be helpful to know why it's calling readline and whether that's intended. Chet -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, UTech, CWRUc...@case.edu [1]http://tiswww.cwru.edu/~chet/ References 1. http://tiswww.cwru.edu/~chet/
bashbug's default editor
Configuration Information [Automatically generated, do not change]: Machine: x86_64 OS: linux-gnu Compiler: gcc Compilation CFLAGS: -O2 -Wall -D_FORTIFY_SOURCE=2 -fstack-protector-strong -funwind-tables -fasynchronous-unwind-tables -fstack-clash-protection -Werror=return-type -flto=auto -g -D_GNU_SOURCE -DRECYCLES_PIDS -Wall -g -Wuninitialized -Wextra -Wno-switch-enum -Wno-unused-variable -Wno-unused-parameter -Wno-parentheses -ftree-loop-linear -pipe -DBNC382214=0 -DIMPORT_FUNCTIONS_DEF=0 -Wno-parentheses -Wno-format-security uname output: Linux delli 5.7.9-1-default #1 SMP Thu Jul 16 09:40:08 UTC 2020 (a010166) x86_64 x86_64 x86_64 GNU/Linux Machine Type: x86_64-suse-linux-gnu Bash Version: 5.0 Patch Level: 17 Release Status: release Description: bashbug doesn't use vi as default editor Repeat-By: unset EDITOR bashbug Usually I have set my $EDITOR to /usr/bin/vim. For testing purposes I commented out that setting and forgot to uncomment it later. Because of the recent bug report "command bashbug does not work and something more…" I entered the command and was surprised to find myself in the unfamiliar emacs editor (which it took me a while to leave). However, according to the man page: ENVIRONMENT bashbug will utilize the following environment variables if they exist: EDITOR Specifies the preferred editor. If EDITOR is not set, bashbug attempts to locate a number of alternative editors, including emacs, and defaults to vi. bashbug should open vi.
Re: Should $(fg) resume a stopped job?
On 7/31/20 2:03 AM, Oğuz wrote: > $ sleep 25 > ^Z > [1]+ Stopped sleep 25 > $ > $ echo $(fg; jobs %) > bash: jobs: %: no such job > sleep 25 > $ > $ jobs > [1]+ Running sleep 25 & > > What I gather from this is that bash fakes interactive job control in > command substitution context, because otherwise `fg' wouldn't return > immediately. But I don't see any point in that `fg' resumes the stopped job > when it's faked. Is this a bug or a deliberate choice? Maybe a minor bug, but certainly a choice. The command substitution keeps the jobs list around, since the subshell is supposed to be an exact copy of the parent, and it's useful to get the output of `jobs' out of command substitution. You just can't expect to do anything with any of those jobs, since the command substitution shell is not the parent of any of them. It would make sense to have `fg' complain about that. -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, UTech, CWRUc...@case.eduhttp://tiswww.cwru.edu/~chet/
Re: File descriptor leak
On 7/31/20 12:29 AM, Chris Dunlop wrote: > Bash Version: 5.0 > Patch Level: 3 > Release Status: release > > Description: > Bash is leaking a file descriptor. Patches 16 and 17 deal with this. Patch 17 is the ultimate fix. -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, UTech, CWRUc...@case.eduhttp://tiswww.cwru.edu/~chet/
Re: bashbug's default editor
On 7/31/20 4:14 AM, jazz_...@arcor.de wrote: > Bash Version: 5.0 > Patch Level: 17 > Release Status: release > > Description: bashbug doesn't use vi as default editor This is not a bug. -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, UTech, CWRUc...@case.eduhttp://tiswww.cwru.edu/~chet/
Re: Issue with Bash
On 7/31/20 3:25 AM, Rishita Saha16 wrote: > Hi All, > > We have been able to recreate a scenario where bash dumps core immediately > on issuing a SIGHUP to the parent process (kill -1 ). On > debugging, the core so generated shows exactly the same stack trace as we > had seen with the previous core. Below is the truss output of bash process > when the parent process of bash (ksh, in this case) gets a SIGHUP: I'm trying to figure out the scenario here. An interactive bash, which is the child of an interactive ksh, runs `kill -1 $PPID'. The parent ksh apparently closes the controlling terminal (?), then resends the SIGHUP to its children (bash) before exiting. The interactive bash catches SIGHUP in readline, attempts to clean up the terminal by restoring the original settings, and gets SIGHUP (?), even though SIGHUP isn't one of the signals that's supposed to be sent when you use tcsetattr. I'd love to know what's happening to the controlling terminal here, assuming the scenario I've outlined is what's happening. Chet -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, UTech, CWRUc...@case.eduhttp://tiswww.cwru.edu/~chet/
Re: Assignment-like word shouldn't be subjected to tilde expansion in POSIX mode
On 7/30/20 10:43 AM, Robert Elz wrote:
> Date:Mon, 20 Jul 2020 10:11:59 -0400
> From:Chet Ramey
> Message-ID:
>
> Sorry, didn't reply to this at the time...
>
> | You can make a case for the bash/ksh tilde expansion: the word
> | expansion is ${PARAM:=WORD}, and the WORD is subject to tilde expansion
> | according to the enumerated list in 2.6.2.
>
> Sure. but ...
>
> | Since the first character of WORD is a tilde, if you say the
> | tilde-prefix stops at the `:',
>
> but that's true (in posix) only in an assignment. Either it is an
> assignment, or it is not.
It's not an assignment. Not according to the POSIX definition of a variable
assignment.
The terminating the tilde prefix at `:' is a bash extension. POSIX allows
it because the behavior is undefined if the tilde prefix doesn't form a
valid login name. Call it a bug if you like, but it's been there since at
least bash-1.10.
--
``The lyf so short, the craft so long to lerne.'' - Chaucer
``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, UTech, CWRUc...@case.eduhttp://tiswww.cwru.edu/~chet/
RE: Issue with Bash
We are passing SIGHUP from another terminal ( not from the terminal which has the interactive bash shell) . The terminal which has the interactive bash closes immediately. The scenario is we just open two terminals. In one terminal , just invoke bash . And from another terminal pass SIGHUP to the parent process (ksh) of bash. Thanks Ayappan P From: Chet Ramey To: Rishita Saha16 Cc: bug-bash@gnu.org, chet.ra...@case.edu Date: 31-07-2020 19:05 Subject:[EXTERNAL] Re: Issue with Bash Sent by:"bug-bash" On 7/31/20 3:25 AM, Rishita Saha16 wrote: > Hi All, > > We have been able to recreate a scenario where bash dumps core immediately > on issuing a SIGHUP to the parent process (kill -1 ). On > debugging, the core so generated shows exactly the same stack trace as we > had seen with the previous core. Below is the truss output of bash process > when the parent process of bash (ksh, in this case) gets a SIGHUP: I'm trying to figure out the scenario here. An interactive bash, which is the child of an interactive ksh, runs `kill -1 $PPID'. The parent ksh apparently closes the controlling terminal (?), then resends the SIGHUP to its children (bash) before exiting. The interactive bash catches SIGHUP in readline, attempts to clean up the terminal by restoring the original settings, and gets SIGHUP (?), even though SIGHUP isn't one of the signals that's supposed to be sent when you use tcsetattr. I'd love to know what's happening to the controlling terminal here, assuming the scenario I've outlined is what's happening. Chet -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, UTech, CWRUc...@case.edu https://urldefense.proofpoint.com/v2/url?u=http-3A__tiswww.cwru.edu_-7Echet_&d=DwIDaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=SRx7SyASbvCxu7GP-Qbph4o5MPmrwcLUo4BhenbwbOs&m=dREr3VV_1yXFT4jYksU27BGkTuQMzbiZ3YfMkA7QiyU&s=ZK-DO14m3GM4ifbR8ncAmmgyyOuGzSAcm49s_TTrRQM&e=
Re: Issue with Bash
On 7/31/20 10:04 AM, Ayappan P2 wrote: > We are passing SIGHUP from another terminal ( not from the terminal which > has the interactive bash shell) . The terminal which has the interactive > bash closes immediately. > > The scenario is we just open two terminals. In one terminal , just invoke > bash . And from another terminal pass SIGHUP to the parent process (ksh) of > bash. I'm going to have to test some more. When I tried it, all the shells died. (I did send the SIGHUP from another terminal.) I was using ksh93 as the parent and bash-5.0.18 as the interactive bash, running on macOS. -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, UTech, CWRUc...@case.eduhttp://tiswww.cwru.edu/~chet/
Re: bashbug's default editor
On 7/31/20 9:24 AM, Chet Ramey wrote: > On 7/31/20 4:14 AM, jazz_...@arcor.de wrote: > >> Bash Version: 5.0 >> Patch Level: 17 >> Release Status: release >> >> Description: bashbug doesn't use vi as default editor > > This is not a bug. The documentation is confusing (and IMHO wrong). "If EDITOR is not set, bashbug attempts to locate a number of alternative editors, including emacs, and defaults to vi." The word "defaults" there implies that vi is the preferred autolocated editor, but the intention is to have it the least preferred. Perhaps... "If EDITOR is not set, bashbug attempts to locate a number of alternative editors, including emacs, before falling back to vi." -- Eli Schwartz Arch Linux Bug Wrangler and Trusted User signature.asc Description: OpenPGP digital signature
Re: bashbug's default editor
On 7/31/20 11:05 AM, Eli Schwartz wrote: > On 7/31/20 9:24 AM, Chet Ramey wrote: >> On 7/31/20 4:14 AM, jazz_...@arcor.de wrote: >> >>> Bash Version: 5.0 >>> Patch Level: 17 >>> Release Status: release >>> >>> Description: bashbug doesn't use vi as default editor >> >> This is not a bug. > > The documentation is confusing (and IMHO wrong). > > "If EDITOR is not set, bashbug attempts to locate a number of > alternative editors, including emacs, and defaults to vi." > > The word "defaults" there implies that vi is the preferred autolocated > editor, but the intention is to have it the least preferred. I don't think it implies that. It's the default choice if there are no other alternatives. -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, UTech, CWRUc...@case.eduhttp://tiswww.cwru.edu/~chet/
Re: bashbug's default editor
On 7/31/20 11:15 AM, Chet Ramey wrote: > On 7/31/20 11:05 AM, Eli Schwartz wrote: >> On 7/31/20 9:24 AM, Chet Ramey wrote: >>> On 7/31/20 4:14 AM, jazz_...@arcor.de wrote: >>> Bash Version: 5.0 Patch Level: 17 Release Status: release Description: bashbug doesn't use vi as default editor >>> >>> This is not a bug. >> >> The documentation is confusing (and IMHO wrong). >> >> "If EDITOR is not set, bashbug attempts to locate a number of >> alternative editors, including emacs, and defaults to vi." >> >> The word "defaults" there implies that vi is the preferred autolocated >> editor, but the intention is to have it the least preferred. > > I don't think it implies that. It's the default choice if there are no > other alternatives. In the sentence in the bashbug manpage, does the word "default" refer to the probing or what happens when probing fails? My belief is that people reading the manpage will understand it to mean the former (more natural reading). Your belief seems to be that people will understand it to mean the latter (I don't feel the sentence conveys this). ... The OP here seems to have interpreted it the way I did. So clearly it's confusing to at least 2 people out of millions. ... Another possible tweak of the documentation: "If EDITOR is not set, bashbug attempts to locate a number of alternative editors, including emacs, before defaulting to vi." and -> before -- Eli Schwartz Arch Linux Bug Wrangler and Trusted User signature.asc Description: OpenPGP digital signature
Re: Should $(fg) resume a stopped job?
31 Temmuz 2020 Cuma tarihinde Chet Ramey yazdı: > On 7/31/20 2:03 AM, Oğuz wrote: > > $ sleep 25 > > ^Z > > [1]+ Stopped sleep 25 > > $ > > $ echo $(fg; jobs %) > > bash: jobs: %: no such job > > sleep 25 > > $ > > $ jobs > > [1]+ Running sleep 25 & > > > > What I gather from this is that bash fakes interactive job control in > > command substitution context, because otherwise `fg' wouldn't return > > immediately. But I don't see any point in that `fg' resumes the stopped > job > > when it's faked. Is this a bug or a deliberate choice? > > Maybe a minor bug, but certainly a choice. The command substitution keeps > the jobs list around, since the subshell is supposed to be an exact copy of > the parent, and it's useful to get the output of `jobs' out of command > substitution. > > You just can't expect to do anything with any of those jobs, since the > command substitution shell is not the parent of any of them. It would > make sense to have `fg' complain about that. > > Right, it would. bosh behaves the same way as bash btw. > -- > ``The lyf so short, the craft so long to lerne.'' - Chaucer > ``Ars longa, vita brevis'' - Hippocrates > Chet Ramey, UTech, CWRUc...@case.eduhttp://tiswww.cwru.edu/~chet/ > -- Oğuz
Re: bashbug's default editor
On 2020-07-31 at 11:26 -0400, Eli Schwartz wrote: > In the sentence in the bashbug manpage, does the word "default" refer to > the probing or what happens when probing fails? > > My belief is that people reading the manpage will understand it to mean > the former (more natural reading). > > Your belief seems to be that people will understand it to mean the > latter (I don't feel the sentence conveys this). > > ... > > The OP here seems to have interpreted it the way I did. So clearly it's > confusing to at least 2 people out of millions. I agree with the OP and Eli. This is not a bug against the code, but against the documentation, and I do think there is an issue here. We are in the context of a software program and its configuration. A phrase following the pattern > If is not set (...) defaults to . is commonly used to mean that the program will act as if was set to Here it gets a bit odd, since the part about "bashbug attempting to locate a number of alternative editors, including emacs" adds no value. In fact, the whole thing about emacs and vi there seems of little use (maybe it was added to please members of both cults?), unless you document the actual algorithm the user just knows that it will open a random editor. I suggest the following wording: > EDITOR Specifies the preferred editor. If EDITOR is not set, bashbug > will attempt to locate some common editors on the system and choose > one for you. It's still a black box, but at least doesn't distract about emacs or vi. If you don't like what bashbug choose, you should have picked one yourself. :) While poking at $EDITOR defaults, vim should probably be added to the list, somewhere. For those interested, here is the actual guessing code: https://git.savannah.gnu.org/cgit/bash.git/tree/support/bashbug.sh#n122 I'm a bit surprised by the hardcoded paths, actually. I understand it may not want to use something like Debian's which may not be generally available, but I was expecting a loop trying to exec alternatives would work, even in the sh mode. I wasn't expecting exec to finish the parent script rather than a function. :/ Best regards
Re: Issue with Bash
On 2020-07-31 at 10:13 -0400, Chet Ramey wrote: > > I'm going to have to test some more. When I tried it, all the shells > died. > (I did send the SIGHUP from another terminal.) I was using ksh93 as > the parent and bash-5.0.18 as the interactive bash, running on macOS. This is probably AIX-specific in that some ioctl called by tcsetattr seems to cause a SIGHUP when there is no tty. Their behavior kinda make sense. Can probably be easily fixed by masking SIGHUP in the handler. Cheers
Re: bashbug's default editor
Chet Ramey writes: >> "If EDITOR is not set, bashbug attempts to locate a number of >> alternative editors, including emacs, and defaults to vi." >> >> The word "defaults" there implies that vi is the preferred autolocated >> editor, but the intention is to have it the least preferred. > > I don't think it implies that. It's the default choice if there are no > other alternatives. It needs work. It states "attempts to locate a number of alternative editors", which makes perfect sense. But it doesn't make sense to say that it "defaults to vi" in either possible interpretation: 1) The not-intended interpretation is that "it defaults to vi" in the sense that it runs vi if it can. But the preceding text suggests that Emacs is searched for first. 2) The intended interpretation is that if bashbug can't find an editor it somehow attempts to run vi as the default or final fall-back. But that doesn't make sense either, since attempting to do so is ipso facto an attempt to locate vi (presumably through an exec() variant that searches the path), in which case the action is part of the "attempts to locate a number of alternative editors" (in this case "vi"), and thus the first clause would have succeeded. It would make more sense to say something like "attempts to locate a number of alternative editors, including emacs and vi." Dale
