This is the mail archive of the cygwin@cygwin.com mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

RE: Brainstorming a fix for CTRL-C handling in an emacs shell buf fer (non-TTY)


Looks like a I caught a break this time.

I can't tell if we're converging on a solution at this point or
diverging.  However, I did want to get you some usable strace
output if possible.

Let me know if I've worn out my welcome or if you want me to
move to the developer list to cut down the traffic on this list.

I started bash in an emacs buffer, then ran "strace bash",
then ran my "ls -lR".  Then pressed CTRL-C.

If I read the strace output correctly,
it looks like bash figures out that it has a child process,
and I can see the child process responding to the SIGINT signal.
The "ls" process ctrl_c_handler never gets invoked, which is
good.  So I'm 99% sure that ls shut down in response to bash's
signal.  Bash then detects that the child exited and removes
it from its table of child processes.

Here's the relevant strace output:

  138 31106454 [main] bash 2616 wait4: *** errno = 4
  107 31106561 [main] bash 2616 wait4: calling proc_subproc, pid -1, options
0
  102 31106663 [main] bash 2616 proc_subproc: args: 4, 1628040088
   99 31106762 [main] bash 2616 proc_subproc: wval->pid -1, wval->options 0
  102 31106864 [main] bash 2616 checkstate: nchildren 1, nzombies 0
 1052 3175655 [sig] ls 2632 wait_sig: awake
  310 31107174 [main] bash 2616 checkstate: checking alive children
  109 31107283 [main] bash 2616 stopped_or_terminated: considering pid 2632
  195 31107478 [main] bash 2616 checkstate: returning -1
  101 31107579 [main] bash 2616 proc_subproc: only found non-terminated
children
   98 31107677 [main] bash 2616 proc_subproc: finished processing
terminated/stopped child
   98 31107775 [main] bash 2616 proc_subproc: returning 1
  900 3176555 [sig] ls 2632 wait_sig: processing signal 2
  101 3176656 [sig] ls 2632 wait_sig: Got signal 2
   97 3176753 [sig] ls 2632 sig_handle: signal 2
   98 3176851 [sig] ls 2632 sig_handle: signal 2, about to call do_exit
  297 3177148 [sig] ls 2632 signal_exit: about to call do_exit (10200)
   96 3177244 [sig] ls 2632 do_exit: do_exit (66048)
  108 3177352 [sig] ls 2632 void: 0x0 = signal (20, 0x1)
   98 3177450 [sig] ls 2632 void: 0x0 = signal (1, 0x1)
   94 3177544 [sig] ls 2632 void: 0x0 = signal (2, 0x1)
   95 3177639 [sig] ls 2632 void: 0x0 = signal (3, 0x1)
   97 3177736 [sig] ls 2632 fhandler_base::close: handle 0xF8
  116 3177852 [sig] ls 2632 fhandler_base::close: handle 0x100
  105 3177957 [sig] ls 2632 fhandler_base::close: handle 0x104
  106 3178063 [sig] ls 2632 fhandler_base::close: handle 0x0
  103 3178166 [sig] ls 2632 fhandler_base::close: CloseHandle (0
</usr/share/locale/locale.alias>) failed
  101 3178267 [sig] ls 2632 seterrno_from_win_error:
/work/build/src/winsup/cygwin/fhandler.cc:774 errno 6
   99 3178366 [sig] ls 2632 geterrno_from_win_error: windows error 6 ==
errno 9
  140 3178506 [sig] ls 2632 proc_terminate: nchildren 0, nzombies 0
   97 3178603 [sig] ls 2632 proc_terminate: leaving
225091 3403694 [sig] ls 2632 sigproc_terminate: entering
  184 3403878 [sig] ls 2632 sigproc_terminate: done
  372 3404250 [sig] ls 2632 __to_clock_t: dwHighDateTime 0, dwLowDateTime
600864
  104 3404354 [sig] ls 2632 __to_clock_t: total 00000000 0000003C
  100 3404454 [sig] ls 2632 __to_clock_t: dwHighDateTime 0, dwLowDateTime
200288
   98 3404552 [sig] ls 2632 __to_clock_t: total 00000000 00000014
   97 3404649 [sig] ls 2632 _pinfo::exit: Calling ExitProcess 66048
 2278 31110053 [sig] bash 2616 wait_sig: looping
227830 31337883 [proc] bash 2616 proc_subproc: args: 2, 0
  164 31338047 [proc] bash 2616 proc_subproc: pid 2632[0] terminated, handle
0x11C, nchildren 1, nzombies 0
  106 31338153 [proc] bash 2616 proc_subproc: removing [0], pid 2632, handle
0x11C, nchildren 1
  102 31338255 [proc] bash 2616 proc_subproc: returning 1
   98 31338353 [proc] bash 2616 sig_send: pid 2616, signal 20, its_me 1
  101 31338454 [proc] bash 2616 sig_send: Not waiting for sigcomplete.
its_me 1 signal 20
  109 31338563 [proc] bash 2616 sig_send: returning 0 from sending signal 20
   98 31338661 [proc] bash 2616 wait_subproc: looping

-----Original Message-----
From: Christopher Faylor [mailto:cgf@redhat.com]
Sent: Tuesday, May 08, 2001 5:08 PM
To: 'cygwin@cygwin.com'
Subject: Re: Brainstorming a fix for CTRL-C handling in an emacs shell
buf fer (non-TTY)


On Tue, May 08, 2001 at 04:26:09PM -0600, Troy Noble wrote:
>> >I immediately got a SIGINT in the child process, even before its
>> >CTRL-C handler got invoked.
>
>> That's a "Windows" SIGINT, which is the only thing that gdb can
>> detect.  A Cygwin SIGINT is a different thing entirely.  Since Cygwin
>> has the full complement of Windows signals, it uses another complicated
>> method for sending signals between processes.
>
>> Running in strace would tell whether you received a SIGINT or not.  You'd
>> see the signal_thread responding to a SIGINT.
>
>This is what I get.
>
>Didn't see anything before the ctrl_c_handler output that looked like an
>incoming SIGINT from bash.exe.  Also no hit on a serch for "signal_thread".
>What is "[unknown (0x7FC)]" indicated.  Could that be the signal thread?

Actually, I should have checked before I responded.  The name of the thread
is just "sig".  The unknown thread is started by Windows when it wants to
deliver a CTRL-C.

>Interestingly, running "strace ls -lR" the child doesn't get the SIGINT
>until after it's ctrl_c_handler runs and it sends itself a SIGINT.

Oh well.  That sounds right, since strace isn't a cygwin application
the pid_exists (t->getpgid ()) will == FALSE and the process will send
a SIGINT to itself.

The only way to test this is to run strace on the bash process itself
and then watch for SIGINTs when a subprocess is running.  I don't think
you'll see them, though.

>Also interesting that the code inside ls.exe now thinks that
>t->getpgid() == myself->pid.  How does that happen?

Because strace acted as a barrier in this case.

cgf

--
Want to unsubscribe from this list?
Check out: http://cygwin.com/ml/#unsubscribe-simple

--
Want to unsubscribe from this list?
Check out: http://cygwin.com/ml/#unsubscribe-simple


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]