Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

BUG: bash-4.0.17 and SIGWINCH during initialization

12 views
Skip to first unread message

Nicolai Lissner

unread,
Apr 11, 2009, 10:05:11 PM4/11/09
to bug-...@gnu.org, Aron Griffis
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.

--


Chet Ramey

unread,
Apr 13, 2009, 5:48:57 PM4/13/09
to Nicolai Lissner, chet....@case.edu, bug-...@gnu.org, Aron Griffis
Nicolai Lissner wrote:
> 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.

Not a race condition exactly, but a timing issue. The problem occurs
when a SIGWINCH arrives during redisplay. The SIGWINCH handler tries
to update the display immediately to reflect the new window size, but
steps on itself when calling the redisplay code recursively. A simple
semaphore is enough to prevent the double calls.

Try the attached patch and let me know how it works.

Chet

--
``The lyf so short, the craft so long to lerne.'' - Chaucer

Chet Ramey, ITS, CWRU ch...@case.edu http://cnswww.cns.cwru.edu/~chet/

redisplay-sigwinch

Nicolai Lissner

unread,
Apr 13, 2009, 9:21:24 PM4/13/09
to bug-...@gnu.org, chet....@case.edu
On Mon, Apr 13, 2009 at 17:48:57 -0400, Chet Ramey wrote:
> Try the attached patch and let me know how it works.

Works perfectly here, too :)
Thanks a lot for the quick fix.

Aron Griffis

unread,
Apr 13, 2009, 6:33:48 PM4/13/09
to Chet Ramey, bug-...@gnu.org, Nicolai Lissner
Chet Ramey wrote: [Mon Apr 13 2009, 05:48:57PM EDT]

> Try the attached patch and let me know how it works.

Works for me on bash-4.0.17. Thanks Chet!

Aron


0 new messages