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 22:28:05 +0300
From: Egor Duda <deo AT logos-m DOT ru>
X-Mailer: The Bat! (v1.45) Personal
Reply-To: Egor Duda <cygwin-developers AT cygwin DOT com>
Organization: DEO
X-Priority: 3 (Normal)
Message-ID: <712746649.20010319222805@logos-m.ru>
To: Christopher Faylor <cgf AT redhat DOT com>
CC: Egor Duda <cygwin-developers AT cygwin DOT com>
Subject: Re: Outstanding issues with current DLL?
In-reply-To: <20010319135052.A13780@redhat.com>
References: <20010308133552 DOT A878 AT redhat DOT com> <3AA7E05A DOT BF9F2535 AT yahoo DOT com>
 <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>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

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