Configuration Information [Automatically generated, do not change]: Machine: x86_64 OS: linux-gnu Compiler: gcc Compilation CFLAGS: -DPROGRAM='bash' -DCONF_HOSTTYPE='x86_64' -DCONF_OSTYPE='linux-gnu' -DCONF_MACHTYPE='x86_64-unknown-linux-gnu' -DCONF_VENDOR='unknown' -DLOCALEDIR='/usr/share/locale' -DPACKAGE='bash' -DSHELL -DHAVE_CONFIG_H -I. -I. -I./include -I./lib -march=athlon64 -O2 -pipe -fPIC uname output: Linux lilith 2.6.29.1 #1 PREEMPT Fri Apr 3 03:32:29 CEST 2009 x86_64 AMD Athlon(tm) Processor LE-1620 AuthenticAMD GNU/Linux Machine Type: x86_64-unknown-linux-gnu
Bash Version: 4.0 Patch Level: 17 Release Status: release Description: There is some kind of race condition in bash-4 (or maybe even readline) when it receives SIGWINCH during initialization. This is a pretty common situation when using a tiled window manager and opening a new terminal. While I didn't had any problems with most terminal applications, the problem manifests with rxvt-unicode and results in bash not reacting on ctrl-c anymore. It happens with bash-4 only, bash-3.x behaved well, even in urxvt. I've had this problem with 4.0, 4.0.10 and 4.0.17 (no other patchlevels tested) As it happens with urxvt only, I reported this problem to the rxvt-unicode mailinglist first but the further discussion there showed the problem is actually a bash-issue (maybe a readline-issue) The difference with urxvt to other terminal applications is it resends SIGWINCH (if received) another time as soon as it receives any output from the application running in it. It does this to fix problems related to SIGWINCH in quite a lot other applications - helping the programs to behave better - especially in tiled window managers. (Un)fortunately it helps bash-4 to make a bug appear, that seems to hide well without this ;) Actually no application should have a problem with receiving SIGWINCH twice, even not during initialization or while the signal handler for a formerly received SIGWINCH is still running. So I decided to move the issue here. During the discussion on the urxvt-mailing list another issue - namely a problem with multiple line prompts not printed correctly also related to early SIGWINCH were reported. Aron Griffis had been able to strace the multi-line prompt problem and posted his results to the rxvt-unicode mailing list. Any try to strace the ctrl-c problem had been without success here, as soon as I strace the problem, it doesn't occure anymore. Both problems seem to have been earlier issues with bash (according to bash's changelog) and it seems that the special behaviour of urxvt just make these problems re-appear? (I'm not sure about this, for me this problems were new) However, I'm not sure if there is any relation between these two problems beside the fact that both are related to SIGWINCH and appear on early SIGWINCH receivement, as the multi-line-prompt problem had been reported to exist in bash-3.2, too. The problem with ctrl-c not working anymore appears to me in bash-4 only. References: The complete discussion on the rxvt-unicode mailinglist can be reviewed in the archive of that mailing list: http://lists.schmorp.de/pipermail/rxvt-unicode/2009q2/thread.html#923 The probably most interesting part is Aron's successful strace of the multi-line prompt-problem, posted here: http://lists.schmorp.de/pipermail/rxvt-unicode/2009q2/000938.html Repeat-By: The problem can be reproduced by running bash-4 with urxvt in a tiled-windowmanager (awesome, dwm, wmii, ion3...) No matter which tiled windowmanager, they all send a SIGWINCH as soon as terminal window opens. The problem can be reproduced without a tiling window manager by calling bash with rxvt-unicode and immediately maximizing the window to trigger SIGWINCH. As it is some race condition, the problem appears something between once in ten times and every time, depending on the system. As mentioned above - the resending of SIGWINCH as soon as any output is received as done by urxvt - seems to be necessary to reproduce the issue. At least I couldn't reproduce it with aterm or xterm, but that doesn't necessarily mean it cannot happen there, the chance it happens might be just more probable due to the resending of SIGWINCH done by rxvt-unicode. Fix: No idea how to fix the problem. I found a workaround only: testing the SHLVL in ~/.bashrc and starting a subshell depending on the value. Obviously not a fix at all, but it makes Ctrl-C working again for me (so I dont feel very much annoyed of it anymore) Thanks: Beside this little problem I really love bash-4. Thanks a lot for developing it. --
