Recently we came across a bug in bash which was introduced by below patch :
In bash 4.2 this could lead to a race condition. 'yy_readline_get ()' function sets 'terminate_immediately' to 1 before calling readline() at .
If shell receives SIGHUP and executes 'termsig_handler ()' before setting 'terminate_immediately' back to 0 , we will end up at  (considering 'RL_ISSTATE (RL_STATE_READCMD)' evaluates to 0 when readline is not waiting to read command from user), and ~/.bash_history will not be updated.
We started seeing this bug after above mentioned patch was backported to RHEL 6. Sometimes ~/.bash_history is not updated when user executes 'reboot' command in a ssh session. This is caused by race condition in handling SIGHUP.
While this issue was fixed by backporting somes changes (See attached patch) from  to bash-4.2 or older versions, there is still a corner case which may cause race condition in handling SIGHUP in current upstream.
'bash_tilde_expand ()' function sets 'terminate_immediately' to 1 at 
If SIGHUP is received and termsig_handler () gets executed before reaching , ~/.bash_history will not be updated. This can happen in a scenario where user is running ssh session and requests for expansion for '~', if an admin issues 'reboot' command at the same time then ~/.bash_history may not be updated.
I have 2 questions about how current upstream handles this condition :
1. Why 'terminate_immediately' is set to 1 at ?
2. Why 'RL_ISSTATE (RL_STATE_READCMD)' is being checked at ? This will evaluate to 0 if readline is not waiting to read a command from user. I believe this check can be removed.