[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

BUG: bash-4.0.17 and SIGWINCH during initialization

From: Nicolai Lissner
Subject: BUG: bash-4.0.17 and SIGWINCH during initialization
Date: Sun, 12 Apr 2009 04:05:11 +0200
User-agent: Mutt/1.5.18 (2008-05-17)

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 #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


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

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.


The complete discussion on the rxvt-unicode mailinglist can be
reviewed in the archive of that mailing list:

The probably most interesting part is Aron's successful strace of the
multi-line prompt-problem, posted here:


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

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.


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


Beside this little problem I really love bash-4. 
Thanks a lot for developing it.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]