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:
_select(0, 0x0000000000000000, 0x0000000000000000,
0x0000000000000000, 0x0000000000000000) (sleeping...)
_select(0, 0x0000000000000000, 0x0000000000000000, 0x0000000000000000,
0x0000000000000000) Err#4 EINTR
Received signal #1, SIGHUP [caught]
ksetcontext_sigreturn(0x0FFFFFFFFFFFBB90, 0x0000000000000000,
0x0FFFFFFFFFFFBB90, 0xF00000002FF48000, 0x000000010002AEDC,
0xA00000000000D032, 0x0000000000000000, 0x0000000110005CB0)
= 0x0000000000000004
ksetcontext_sigreturn(0x0FFFFFFFFFFFBB90, 0x0000000000000004,
0x0FFFFFFFFFFFFFE0, 0x800000000000D032, 0x0000000000003B98,
0x0000000000000000, 0xF1000C01C2D9F000, 0x8000000000001032)
Received signal #1, SIGHUP [caught]
ksetcontext_sigreturn(0x0FFFFFFFFFFFBB90, 0x0000000000000000,
0x0FFFFFFFFFFFBB90, 0xF00000002FF48000, 0x000000010002AEDC,
0xA00000000000D032, 0x0000000000000000, 0x0000000110005CB0)
kfcntl(2, F_GETFL, 0x0000000000000000) = 67110914
kioctl(2, 536900718, 0x0000000000000000, 0x0000000000000000) = 0
kfcntl(2, F_GETFL, 0x0FFFFFFFFFFFFFE8) = 67110914
kioctl(0, 22528, 0x0000000000000000, 0x0000000000000000) = 0
kioctl(0, 21507, 0x0000000110013AF8, 0x0000000000000000) Err#25 ENOTTY
Received signal #1, SIGHUP [caught]
ksetcontext_sigreturn(0x0FFFFFFFFFFFD930, 0x0000000000000000,
0x0FFFFFFFFFFFD930, 0xF00000002FF48000, 0x000000010002AEDC,
0xA00000000000D032, 0x0000000000000000, 0x0000000110005CB0)
kfcntl(2, F_GETFL, 0xFFFFFFFFFFFFFFFF) = 67110914
kioctl(2, 536900718, 0x0000000000000000, 0x0000000000000000) = 0
kfcntl(2, F_GETFL, 0x0FFFFFFFFFFFFFE8) = 67110914
kioctl(0, 22528, 0x0000000000000000, 0x0000000000000000) = 0
kioctl(0, 21507, 0x0000000110013AF8, 0x0000000000000000) Err#25 ENOTTY
Received signal #1, SIGHUP [caught]
ksetcontext_sigreturn(0x0FFFFFFFFFFFD780, 0x0000000000000000,
0x0FFFFFFFFFFFD780, 0xF00000002FF48000, 0x000000010002AEDC,
0xA00000000000D032, 0x0000000000000000, 0x0000000110005CB0)
kfcntl(2, F_GETFL, 0xFFFFFFFFFFFFFFFF) = 67110914
kioctl(2, 536900718, 0x0000000000000000, 0x0000000000000000) = 0
kfcntl(2, F_GETFL, 0x0FFFFFFFFFFFFFE8) = 67110914
kioctl(0, 22528, 0x0000000000000000, 0x0000000000000000) = 0
kioctl(0, 21507, 0x0000000110013AF8, 0x0000000000000000) Err#25 ENOTTY
Received signal #1, SIGHUP [caught]
ksetcontext_sigreturn(0x0FFFFFFFFFFFD5D0, 0x0000000000000000,
0x0FFFFFFFFFFFD5D0, 0xF00000002FF48000, 0x000000010002AEDC,
0xA00000000000D032, 0x0000000000000000, 0x0000000110005CB0)
kfcntl(2, F_GETFL, 0xFFFFFFFFFFFFFFFF) = 67110914
kioctl(2, 536900718, 0x0000000000000000, 0x0000000000000000) = 0
kfcntl(2, F_GETFL, 0x0FFFFFFFFFFFFFE8) = 67110914
kioctl(0, 22528, 0x0000000000000000, 0x0000000000000000) = 0
kioctl(0, 21507, 0x0000000110013AF8, 0x0000000000000000) 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 <chet.ra...@case.edu>
To: Rishita Saha16 <risah...@in.ibm.com>
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, CWRU c...@case.edu
[1]http://tiswww.cwru.edu/~chet/
References
1. http://tiswww.cwru.edu/~chet/
