Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > gnu.bash.bug > #16559

Re: Issue with Bash

Show all headers | View raw

Hi Rishita,

Thanks for the try. But as Chet said it was unlikely to be related to these patches.
We'll have to understand what is causing this loop. Did you confirm that the signal delivered is SIGTTOU ?

Thanks,

Clément


________________________________
From: Rishita Saha16 <risaha16@in.ibm.com>
Sent: Friday, July 10, 2020 1:40 PM
To: CHIGOT, CLEMENT <clement.chigot@atos.net>
Cc: bug-bash@gnu.org <bug-bash@gnu.org>
Subject: RE: Issue with Bash


Caution! External email. Do not open attachments or click links, unless this email comes from a known sender and you know the content is safe.

Hi Clement,

We have given it a try after applying the patches that you are referring to. We are still seeing the core dump.

Regards,
Rishita
----- Original message -----
From: "CHIGOT, CLEMENT" <clement.chigot@atos.net>
To: Rishita Saha16 <risaha16@in.ibm.com>, "bug-bash@gnu.org" <bug-bash@gnu.org>
Cc:
Subject: [EXTERNAL] Re: Issue with Bash
Date: Thu, Jul 9, 2020 7:46 PM

Hi Rishita,

Could you try with BullFreeware's version, which have a slightly higher version (5.0.11 instead of 5.0) ?
You can find it at http://www.bullfreeware.com/pkg?id=5740<https://eur01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.bullfreeware.com%2Fpkg%3Fid%3D6102&data=02%7C01%7Cclement.chigot%40atos.net%7C3d9263d48ac2401b40bd08d824c622c9%7C33440fc6b7c7412cbb730e70b0198d5a%7C0%7C0%7C637299780715264030&sdata=7tBnO%2BRlHBA2SFnUsR%2Fpf%2BztMszUnYHZugGq3Z5Hw58%3D&reserved=0>.

If it's not working, I'll check what's wrong.

Clément

________________________________
From: bug-bash <bug-bash-bounces+clement.chigot=atos.net@gnu.org> on behalf of Rishita Saha16 <risaha16@in.ibm.com>
Sent: Thursday, July 9, 2020 11:17 AM
To: bug-bash@gnu.org <bug-bash@gnu.org>
Subject: Issue with Bash

Caution! External email. Do not open attachments or click links, unless this email comes from a known sender and you know the content is safe.

   Hi All,

   We are using Bash 5.0 (64bit built using gcc ) in AIX 7.2 machine .This
   is the spec file for reference -->
   [1]https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpublic.dhe.ibm.com%2Faix%2FfreeSoftware%2Faixtoolbox%2FSPECS%2Fbash-5&amp;data=02%7C01%7Cclement.chigot%40atos.net%7C2310b33a682446f8ff2108d82409a6ef%7C33440fc6b7c7412cbb730e70b0198d5a%7C0%7C1%7C637298971158015991&amp;sdata=kVr8cM1wtAs00LdGp11Sjz1Mo8wuvdTwJ0ZQD4hP%2B5g%3D&amp;reserved=0<https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpublic.dhe.ibm.com%2Faix%2FfreeSoftware%2Faixtoolbox%2FSPECS%2Fbash-5&data=02%7C01%7Cclement.chigot%40atos.net%7C3d9263d48ac2401b40bd08d824c622c9%7C33440fc6b7c7412cbb730e70b0198d5a%7C0%7C0%7C637299780715274019&sdata=xRy2tS5mliwQ7Z8diVHSwc8517WtymAu6wCt8LHWpf0%3D&reserved=0>.
   0-1.spec.
   We are seeing recurring bash core dumps on our servers. Leaving bash
   sessions running on the servers for extended periods of time causes the
   core dump (to recreate it, we left httpd running for about a week and a
   half and encountered the core dump). I am hereby sharing the stack
   trace of the core so generated.

   #0  0x0900000000038d0c in __ioctl () from /usr/lib/libc.a(shr_64.o)
   #1  0x09000000000392c8 in ioctl () from /usr/lib/libc.a(shr_64.o)
   #2  0x09000000001c16f0 in tcsetattr () from /usr/lib/libc.a(shr_64.o)
   #3  0x00000001000aec78 in set_tty_settings (tty=0, tiop=0x110013a90
   <_rltty.bss_3_+64>) at rltty.c:466
   #4  0x00000001000aef58 in rl_deprep_terminal () at rltty.c:704
   #5  0x000000010002cf38 in rl_cleanup_after_signal () at signals.c:559
   #6  0x000000010002d500 in _rl_handle_signal (sig=268438344) at
   signals.c:249
   #7  0x00000001000aef80 in rl_deprep_terminal () at rltty.c:713
   #8  0x000000010002cf38 in rl_cleanup_after_signal () at signals.c:559
   #9  0x000000010002d500 in _rl_handle_signal (sig=268438344) at
   signals.c:249
   #10 0x00000001000aef80 in rl_deprep_terminal () at rltty.c:713
   #11 0x000000010002cf38 in rl_cleanup_after_signal () at signals.c:559
   #12 0x000000010002d500 in _rl_handle_signal (sig=268438344) at
   signals.c:249
   #13 0x00000001000aef80 in rl_deprep_terminal () at rltty.c:713
   #14 0x000000010002cf38 in rl_cleanup_after_signal () at signals.c:559
   #15 0x000000010002d500 in _rl_handle_signal (sig=268438344) at
   signals.c:249
   #16 0x00000001000aef80 in rl_deprep_terminal () at rltty.c:713
   #17 0x000000010002cf38 in rl_cleanup_after_signal () at signals.c:559
   #18 0x000000010002d500 in _rl_handle_signal (sig=268438344) at
   signals.c:249
   #19 0x00000001000aef80 in rl_deprep_terminal () at rltty.c:713
   #20 0x000000010002cf38 in rl_cleanup_after_signal () at signals.c:559
   #21 0x000000010002d500 in _rl_handle_signal (sig=268438344) at
   signals.c:249
   #22 0x00000001000aef80 in rl_deprep_terminal () at rltty.c:713
   #23 0x000000010002cf38 in rl_cleanup_after_signal () at signals.c:559
   #24 0x000000010002d500 in _rl_handle_signal (sig=268438344) at
   signals.c:249
   #25 0x00000001000aef80 in rl_deprep_terminal () at rltty.c:713
   #26 0x000000010002cf38 in rl_cleanup_after_signal () at signals.c:559
   #27 0x000000010002d500 in _rl_handle_signal (sig=268438344) at
   signals.c:249
   #28 0x00000001000aef80 in rl_deprep_terminal () at rltty.c:713
   #29 0x000000010002cf38 in rl_cleanup_after_signal () at signals.c:559
   #30 0x000000010002d500 in _rl_handle_signal (sig=268438344) at
   signals.c:249
   #31 0x00000001000aef80 in rl_deprep_terminal () at rltty.c:713
   #32 0x000000010002cf38 in rl_cleanup_after_signal () at signals.c:559
   #33 0x000000010002d500 in _rl_handle_signal (sig=268438344) at
   signals.c:249
   #34 0x00000001000aef80 in rl_deprep_terminal () at rltty.c:713
   #35 0x000000010002cf38 in rl_cleanup_after_signal () at signals.c:559
   #36 0x000000010002d500 in _rl_handle_signal (sig=268438344) at
   signals.c:249
   #37 0x00000001000aef80 in rl_deprep_terminal () at rltty.c:713
   #38 0x000000010002cf38 in rl_cleanup_after_signal () at signals.c:559
   #39 0x000000010002d500 in _rl_handle_signal (sig=268438344) at
   signals.c:249
   #40 0x00000001000aef80 in rl_deprep_terminal () at rltty.c:713
   #41 0x000000010002cf38 in rl_cleanup_after_signal () at signals.c:559
   #42 0x000000010002d500 in _rl_handle_signal (sig=268438344) at
   signals.c:249

   From the stack trace , it looks like bash is looping in a code that is
   setting terminal attributes in response to a signal, and dumps core
   once it runs out of stack.
   Any insights will be greatly helpful.

   Thanks and Regards
   Rishita Saha

References

   1. https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpublic.dhe.ibm.com%2Faix%2FfreeSoftware%2Faixtoolbox%2FSPECS%2Fbash-5.0-1.spec&amp;data=02%7C01%7Cclement.chigot%40atos.net%7C2310b33a682446f8ff2108d82409a6ef%7C33440fc6b7c7412cbb730e70b0198d5a%7C0%7C1%7C637298971158015991&amp;sdata=CJmbnCe8hEUbpVBeKDP%2FHWofB9PbIB2FEkDL3aBQeBA%3D&amp;reserved=0<https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpublic.dhe.ibm.com%2Faix%2FfreeSoftware%2Faixtoolbox%2FSPECS%2Fbash-5.0-1.spec&data=02%7C01%7Cclement.chigot%40atos.net%7C3d9263d48ac2401b40bd08d824c622c9%7C33440fc6b7c7412cbb730e70b0198d5a%7C0%7C0%7C637299780715274019&sdata=5eGul08Z2xkhA%2FCawsRG4GAIX6EhPpq%2BdEVmvQBFxwk%3D&reserved=0>

Back to gnu.bash.bug | Previous | Next | Find similar

Thread

Re: Issue with Bash "CHIGOT, CLEMENT" <clement.chigot@atos.net> - 2020-07-10 11:52 +0000

csiph-web