SIGTSTP and select
Fri Apr 13 15:04:00 GMT 2007
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 184.108.40.206, 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
>> 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
>> + Stopped ./main
>> $ fg
>> 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'
I'm not in a position to test this right now but, if cygwin is in
blocking mode, i.e., select is in an infinite wait, it should be
possible to use CTRL-Z to suspend it. I will look into this once I have
my computers put back together.
>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
>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.
Or start gdb in a pty.
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html
More information about the Cygwin