Mail Archives: cygwin-developers/2001/03/19/14:41:03
On Mon, Mar 19, 2001 at 10:28:05PM +0300, Egor Duda wrote:
>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.
It's not supposed to be necessary. Can you send me a little more of the
previous state? I'd like to see more of what the main thread was doing.
cgf
- Raw text -