This is the mail archive of the cygwin-developers@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: Outstanding issues with current DLL?


On Mon, Mar 19, 2001 at 10:28:05PM +0300, Egor Duda wrote:
>Hi!
>
>Monday, 19 March, 2001 Christopher Faylor cgf@redhat.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


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