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 <chet.ra...@case.edu>
To: Rishita Saha16 <risah...@in.ibm.com>
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" <bug-bash-bounces+ayappap2=in.ibm....@gnu.org>
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 <parent-pid>). 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, CWRU c...@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=
