bug-bash
[Top][All Lists]
Advanced

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

"tcsetattr: Interrupted system call" after rapid-fire ^C chars


From: Joe Peterson
Subject: "tcsetattr: Interrupted system call" after rapid-fire ^C chars
Date: Tue, 14 Oct 2008 07:12:35 -0600
User-agent: Thunderbird 2.0.0.17 (X11/20081002)

Configuration Information [Automatically generated, do not change]:
Machine: i686
OS: linux-gnu
Compiler: i686-pc-linux-gnu-gcc
Compilation CFLAGS:  -DPROGRAM='bash' -DCONF_HOSTTYPE='i686'
-DCONF_OSTYPE='linux-gnu' -DCONF_MACHTYPE='i686-pc-linux-gnu'
-DCONF_VENDOR='pc' -DLOCALEDIR='/usr/share/locale' -DPACKAGE='bash'
-DSHELL -DHAVE_CONFIG_H   -I.  -I. -I./include -I./lib   -march=i686 -O2
-pipe
uname output: Linux crater 2.6.27-gentoo #1 SMP PREEMPT Mon Oct 13
13:37:45 MDT 2008 i686 Intel(R) Pentium(R) 4 CPU 2.40GHz GenuineIntel
GNU/Linux
Machine Type: i686-pc-linux-gnu

Bash Version: 3.2
Patch Level: 33
Release Status: release

Description:
        (Note that this may be hard to reproduce, at least how I did it,
         on a stock kernel)

        I've been doing some work in the kernel N_TTY line discipline
        and pty code, and one issue was that when a tty is stopped
        (with ^S) and a lot of input/output happens - enough to fill
        the buffer more than 1/2 way, the tty will stop being polled
        for more data.  Holding down a key, thereby producing a rapid
        series of characters, will slowly let the tty continue to
        process blocks of characters.  I've fixed the issue in the
        kernel, but it seems I uncovered a potential bash issue.

        Anyway, when testing this with the "tr" program in a bash
        shell, I tried holding down ctrl-C.  Eventually the tty
        got to reading these characters and produced an interrupt
        as expected.  However, instead of breaking out of tr, as
        usual, I got:

        "-bash: [6630: 5] tcsetattr: Interrupted system call"

        So my question is: is this because there is a small window
        of opportunity for ^C to cause tcsetattr() to get interrupted?
        Is there any way to close this window if so?  Sorry if this
        problem has already been addressed in bash 4...

Repeat-By:

        Well, without a hacked kernel, you'll probably not hit
        *this* manifestation of the issue, but what I did was:

        - run a text processing program (like "cat" or "tr")
        - hit ctrl-S
        - enter lots of text that will then produce lots of output
        - hold down ctrl-C until the error is produced

Fix:
        Should interrupts be trapped during call to tcsetattr()?


                                        Thanks, Joe

P.S. Please cc my email address in any replies...






reply via email to

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