Mail Archives: cygwin-developers/2001/03/19/14:29:26
Hi!
Monday, 19 March, 2001 Christopher Faylor cgf AT redhat DOT com wrote:
CF> On Mon, Mar 19, 2001 at 09:47:25PM +0300, Egor Duda wrote:
>>CF> I assume that the SIGCHLD is getting delivered but it's blocked for
>>CF> some reason. That is usually what causes this kind of symptom.
>>CF> If you can attach to a hung rxvt, could you look at myself->_sigtodo[SIGCHLD+3]?
>>If that has a >>0 number in it, then the signal is blocked.
>>
>>bull's eye! it does contain 1.
>>
>>I've also noticed that chance of freezing increases greatly if
>>you're actively move mouse pointer over rxvt's gui window while
>>pressing ctrl-d.
CF> Hmm. What about myself->sigaction[SIGCHLD]. What does that look like?
(gdb) p myself->procinfo->sigs[20]
$4 = {sa_handler = 0x401048, sa_mask = 0, sa_flags = 0}
looks pretty valid to me.
moreover, 'kill -USR1 <rxvt_pid>' closes rxvt window! i think i know
the reason why. see below.
CF> If that has masked SIGCHLD then that means there is probably a race
CF> somewhere. It's hard to imagine what this would be in a long-running
CF> program that just starts one subprocess (bash), though.
below is strace.
2032 771795 [proc] rxvt 193 proc_subproc: args: 2, 0
468 772263 [proc] rxvt 193 proc_subproc: pid 206[0] terminated, handle 0x188, nchildren 1, nzombies 0
284 772547 [proc] rxvt 193 proc_subproc: removing [0], pid 206, handle 0x188, nchildren 1
247 772794 [proc] rxvt 193 proc_subproc: returning 1
243 773037 [proc] rxvt 193 sig_send: pid 193, signal 20, its_me 1
242 773279 [proc] rxvt 193 sig_send: Not waiting for sigcomplete. its_me 1 sig 20
239 773518 [proc] rxvt 193 sig_send: returning 0 from sending signal 20
242 773760 [proc] rxvt 193 wait_subproc: looping
711 774471 [select_pipe] rxvt 193 fhandler_pty_master::hit_eof: all other handles closed
294 774765 [select_pipe] rxvt 193 peek_pipe: /dev/ptmx, saw EOF
233 774998 [select_pipe] rxvt 193 peek_pipe: saw eof on '/dev/ptmx'
236 775234 [select_pipe] rxvt 193 thread_pipe: stopping
842 776076 [main] rxvt 193 select_stuff::~select_stuff: deleting select records
766 776842 [sig] rxvt 193 wait_sig: awake
265 777107 [sig] rxvt 193 wait_sig: processing signal 20
232 777339 [sig] rxvt 193 wait_sig: Got signal 20
232 777571 [sig] rxvt 193 sig_handle: signal 20
229 777800 [sig] rxvt 193 sig_handle: signal 20, about to call 0x401048
236 778036 [sig] rxvt 193 setup_handler: suspending mainthread
1421 779457 [sig] rxvt 193 setup_handler: couldn't send signal 20
336 779793 [main] rxvt 193 cygwin_select: 5, 0x242FDFC, 0x0, 0x0, 0x0
446 780239 [main] rxvt 193 dtable::select_read: /dev/windows fd 3
418 780657 [main] rxvt 193 dtable::select_read: /dev/ptmx fd 4
217 780874 [main] rxvt 193 cygwin_select: to NULL, ms FFFFFFFF
203 781077 [main] rxvt 193 cygwin_select: sel.always_ready 0
688 781765 [main] rxvt 193 select_stuff::wait: m 2, ms 4294967295
481 782246 [sig] rxvt 193 setup_handler: ResumeThread returned 1
300 782546 [sig] rxvt 193 setup_handler: returning 0
239 782785 [sig] rxvt 193 sig_handle: returning 0
246 783031 [sig] rxvt 193 proc_subproc: args: 3, 0
236 783267 [sig] rxvt 193 proc_subproc: looking for processes to reap
238 783505 [sig] rxvt 193 proc_subproc: finished processing terminated/stopped child
241 783746 [sig] rxvt 193 proc_subproc: returning 1
i've added some sigproc_printf()'s and it looks that sigchild is added
to sigtodo, because we're in kernel (interruptible() returns FALSE).
but sigtodo isn't scanend again until new signal arrives. but it never
arrives if we won't send it explicitly via 'kill'. note, that it
doesn't matter, which signal it will be.
looks like sigtodo array should be rescanned on periodic basis.
Egor. mailto:deo AT logos-m DOT ru ICQ 5165414 FidoNet 2:5020/496.19
- Raw text -