Mailing-List: contact cygwin-developers-help AT sourceware DOT cygnus DOT com; run by ezmlm
List-Subscribe: <mailto:cygwin-developers-subscribe AT sources DOT redhat DOT com>
List-Archive: <http://sources.redhat.com/ml/cygwin-developers/>
List-Post: <mailto:cygwin-developers AT sources DOT redhat DOT com>
List-Help: <mailto:cygwin-developers-help AT sources DOT redhat DOT com>, <http://sources.redhat.com/ml/#faqs>
Sender: cygwin-developers-owner AT sources DOT redhat DOT com
Delivered-To: mailing list cygwin-developers AT sources DOT redhat DOT com
Date: Mon, 19 Mar 2001 14:41:15 -0500
From: Christopher Faylor <cgf AT redhat DOT com>
To: Egor Duda <cygwin-developers AT cygwin DOT com>
Subject: Re: Outstanding issues with current DLL?
Message-ID: <20010319144115.A22891@redhat.com>
Reply-To: cygwin-developers AT cygwin DOT com
Mail-Followup-To: Egor Duda <cygwin-developers AT cygwin DOT com>
References: <20010310184508 DOT A16745 AT redhat DOT com> <3AAFF6E9 DOT DFBF2C8 AT yahoo DOT com> <20010317180414 DOT A22971 AT redhat DOT com> <3AB4DE20 DOT 7CEAE79B AT yahoo DOT com> <3AB532F3 DOT B3D3916 AT yahoo DOT com> <7176922078 DOT 20010319210004 AT logos-m DOT ru> <20010319131711 DOT A19248 AT redhat DOT com> <183306951 DOT 20010319214725 AT logos-m DOT ru> <20010319135052 DOT A13780 AT redhat DOT com> <712746649 DOT 20010319222805 AT logos-m DOT ru>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.3.11i
In-Reply-To: <712746649.20010319222805@logos-m.ru>; from deo@logos-m.ru on Mon, Mar 19, 2001 at 10:28:05PM +0300

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