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

[Joe Peterson]

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