bug-bash
[Top][All Lists]
Advanced

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

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


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

Chet Ramey wrote:
> Joe Peterson wrote:
> 
>>         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()?
> 
> I don't think so.  Readline already blocks interrupts when it calls
> tcsetattr, and bash handles that call returning -1/EINTR appropriately.

Hi,

Yep, I see the code that returns -1 in jobs.c:

---------
if (tcgetattr (tty, &shell_tty_info) < 0)
{
#if 0
  /* Only print an error message if we're really interactive at
     this time. */
  if (interactive)
    sys_error ("[%ld: %d] tcgetattr", (long)getpid (), shell_level);
#endif
  return -1;
}
---------

And that sys_error message is, I believe, the exact error I am seeing.
What I am wondering is how did I manage to invoke this by using ^C?  Did
I hit some small window when readline was not running and when the
program that would normally catch the kill signal was not listening
(i.e. bash itself somehow caught it)?  I did not think this was
possible.  Just wondering if this is something that should not happen.

                                        Thanks, Joe




reply via email to

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