Date: Fri, 13 Apr 2007 11:05:22 -0400
From: Bob Rossi <bob_rossi AT cox DOT net>
To: cygwin AT cygwin DOT com
Subject: Re: SIGTSTP and select
Message-ID: <20070413150522.GC25914@cox.net>
Mail-Followup-To: cygwin AT cygwin DOT com
References: <20070403000723 DOT GG24160 AT cox DOT net> <20070403003753 DOT GA11244 AT ednor DOT casa DOT cgf DOT cx> <20070403141320 DOT GA3459 AT cox DOT net> <20070413132501 DOT GG15801 AT calimero DOT vinschen DOT de> <20070413140108 DOT GA25914 AT cox DOT net> <20070413145136 DOT GK15801 AT calimero DOT vinschen DOT de>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20070413145136.GK15801@calimero.vinschen.de>
User-Agent: Mutt/1.5.12-2006-07-14
Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
Precedence: bulk
Sender: cygwin-owner AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com

On Fri, Apr 13, 2007 at 04:51:36PM +0200, Corinna Vinschen wrote:
> 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 2.6.20.5, 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.

OK, good that we see this now. Chris, what do you recommend? Is this
something that would be fixed in select?

> 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.

I have a nasty change I could make to cgdb to make it work when notty is
set. I could change this,
     if (FD_ISSET (STDIN_FILENO, &rset)) {
        if (user_input_loop () == -1)
           return -1;
        return 0;
     }
to this,
     if (FD_ISSET (STDIN_FILENO, &rset)) {
        int val = user_input_loop ();
        if (val == -1) {
           if (errno == EAGAIN)
             continue;
           else
             return -1;
        }
        return 0;
     }

That's because i get down to the user_input_loop, and then go do some
stuff, and then do a non blocking read call. It returns -1 and sets
errno to EAGAIN.  However, this is a less than ideal hack.

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

That's possible. I don't currently install a handler for that with cgdb,
so, it's not really a big deal.

Thanks for your help,
Bob Rossi

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/