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/
