Outstanding issues with current DLL?

[Egor Duda]

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.

Egor.            mailto:deo@logos-m.ru ICQ 5165414 FidoNet 2:5020/496.19