SIGTSTP and select

Corinna Vinschen
Fri Apr 13 14:51:00 GMT 2007

On Apr 13 10:01, Bob Rossi wrote:
> On Fri, Apr 13, 2007 at 03:25:01PM +0200, Corinna Vinschen wrote:
> > > > On Mon, Apr 02, 2007 at 08:07:23PM -0400, Bob Rossi wrote:
> > > > >When ctrl-z is typed, CGDB receives a SIGTSTP on both linux and cygwin.
> > > > >When CGDB is at the select loop and this happens on linux select returns
> > > > >-1 and errno is set to EINTR. My code simple does a 'continue' when this
> > > > >happens and the select loop is reentered. All works well. On cygwin,
> > > > >select does not return with -1. (I didn't check the return value but I
> > > > >can, I just compare to -1 in an if statement). In fact, select also
> > > > >detects that input is ready on stdin. This causes CGDB to get to a read
> > > > >system call (which is non blocking) and the read system call fails with
> > > > >errno set to EAGAIN. This causes CGDB to exit.
> > > > >[...]
> > I'm a bit puzzled.  I don't see any difference in behaviour on Linux and
> > Cygwin related to your testcase.  I have no problems to trigger the
> > user_input_loop call on Linux and Cygwin.  After I press ctrl-z, I don't
> > get into it on both systems.  After unsuspending the process, I get into
> > user_input_loop on both systems again.  Either your testcase is wrong,
> > or you should exactly specify what has to be typed to trigger the
> > problem.  I tested this with Cygwin 1.5.24 and Linux, btw.
> Hi Corinna,
> Thanks for testing this! I definately do not get the same results as
> you. On ubuntu linux,
>   $ uname -a
>   Linux black 2.6.17-11-386 #2 Thu Feb 1 19:50:13 UTC 2007 i686
>   GNU/Linux
> I'm running cygwin version 1.5.24 and have attached cygcheck.out.
> I've modified the main program slightly to better show the problem.
> On both platforms I do,
>   gcc -g main.c -o main
> On cygwin when I type './main' and then I type 'ctrl-z', I see this,
>   $ ./main.exe
>   Select return value:1
>   In user_input_loop
> On linux when I type './main' and then I type 'ctrl-z', I see this,
>   $ ./main
>   [1]+  Stopped                 ./main
>   $ fg
>   ./main
> In fact, I never see the user_input_loop on linux.
> What's interesting and annoying is that when I tested this last time on
> linux, I was sure that after the SIGTSTP was sent, the select loop
> returned. The value of val was -1 and errno was EINTR and I did a
> continue to the loop again. However, with the example I just posted, it
> appears that linux never breaks free of the select loop. I am still
> seeing a difference between linux and cygwin as shown above.
> I'm curious to know if this is a programming error on my part or if it
> is a bug in the select call on cygwin.

Ok, there's a difference between tty and notty mode here.  I can
reproduce this with notty, while I get a -1/EINTR with CYGWIN=tty. 
This is a bit unfortunate difference which is probably a result of
different handling of console handles (notty) vs. pipe handles (tty).
I'm not sure how to fix that.  Signals and select are rather Chris'
contruction lot.

The restart behaviour as you observed on Linux is not implemented for
select in Cygwin so far.  Only a few system calls actually implement
this right now.  You should always handle EINTR yourself, as your loop
already does.

While that's not a nice solution in the long run, it might be better
to ask the use to run cgdb with CYGWIN=tty for now (which is default
in remote sessions, that's why I couldn't reproduce anything first).
You could for instance add a cgdb wrapper script which always adds tty
to $CYGWIN and starts the cgdb binary.

When you observed -1/EINTR on Linux, did you install a SIGTSTP signal
handle, maybe?


Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Project Co-Leader          cygwin AT cygwin DOT com
Red Hat

Unsubscribe info:
Problem reports:

More information about the Cygwin mailing list