Re: panic caused by EVFILT_SIGNAL detaching in rfork()ed thread

From: John-Mark Gurney <gurney_j_at_resnet.uoregon.edu>
Date: Wed, 1 Sep 2004 08:53:04 -0700
Igor Sysoev wrote this message on Wed, Sep 01, 2004 at 14:47 +0400:
> 5.3-BETA2 still may panic as described in
> http://freebsd.rambler.ru/bsdmail/freebsd-hackers_2004/msg02732.html

Well, between then an now, I have committed kqueue locking, though
I can't say they are similar since you completely dropped the panic
message from your email...

> #11 0xc077631a in calltrap () at /usr/src/sys/i386/i386/exception.s:140
> #12 0xc0620018 in removechild (parent=0x0, child=0x5de)
>     at /usr/src/sys/kern/subr_witness.c:1443
> #13 0xc05e86ab in knlist_remove_kq (knl=0xc39724f4, kn=0x0,
>     knlislocked=-1065428340, kqislocked=0)
>     at /usr/src/sys/kern/kern_event.c:1502
> #14 0xc05e87b3 in knlist_remove (knl=0xc39724f4, kn=0xc3e1d154, islocked=0)
>     at /usr/src/sys/kern/kern_event.c:1527
> #15 0xc060451b in filt_sigdetach (kn=0x0) at /usr/src/sys/kern/kern_sig.c:2733

I love how bt's can not find the value of some arguments.. :(

> #16 0xc05e826a in kqueue_close (fp=0xc394ebb0, td=0xc3a22420)
>     at /usr/src/sys/kern/kern_event.c:1372
> #17 0xc05e5524 in fdrop_locked (fp=0xc394ebb0, td=0xc3a22420) at file.h:289
> #18 0xc05e47b8 in fdrop (fp=0xc394ebb0, td=0xc3a22420)
>     at /usr/src/sys/kern/kern_descrip.c:1897
> #19 0xc05e478b in closef (fp=0xc394ebb0, td=0xc3a22420)
>     at /usr/src/sys/kern/kern_descrip.c:1883
> #20 0xc05e40e7 in fdfree (td=0xc3a22420)
>     at /usr/src/sys/kern/kern_descrip.c:1610
> #21 0xc05ea896 in exit1 (td=0xc3a22420, rv=0)
>     at /usr/src/sys/kern/kern_exit.c:242
> #22 0xc05ea494 in sys_exit (td=0xc3a22420, uap=0x0)
>     at /usr/src/sys/kern/kern_exit.c:94
> #23 0xc07881cf in syscall (frame=
>       {tf_fs = 47, tf_es = 47, tf_ds = 47, tf_edi = 2, tf_esi = 134873108, tf_ebp = -1077941784, tf_isp = -355476108, tf_ebx = 672658924, tf_edx = 10, tf_ecx = 672658608, tf_eax = 1, tf_trapno = 12, tf_err = 2, tf_eip = 672162923, tf_cs = 31, tf_eflags = 662, tf_esp = -1077941812, tf_ss = 47})
>     at /usr/src/sys/i386/i386/trap.c:1004
> #24 0xc077636f in Xint0x80_syscall () at /usr/src/sys/i386/i386/exception.s:201
> 
> [ ... ]
> 
> (kgdb) fr 15
> #15 0xc060451b in filt_sigdetach (kn=0x0) at /usr/src/sys/kern/kern_sig.c:2733
> 2733            knlist_remove(&p->p_klist, kn, 0);
> (kgdb) down
> #14 0xc05e87b3 in knlist_remove (knl=0xc39724f4, kn=0xc3e1d154, islocked=0)
>     at /usr/src/sys/kern/kern_event.c:1527
> 1527            knlist_remove_kq(knl, kn, islocked, 0);
> (kgdb) p *knl
> $1 = {kl_lock = 0x0, kl_list = {slh_first = 0x0}}
>
> 
> However, I do not know is it safe to test !SLIST_EMPTY(&p->p_klist) in

It is possible to call SLIST_EMPTY, but you need to make you have proper
locks held between the time you call SLIST_EMPTY, and knlist_remove...
But I don't think that's the problem, the problem is else where...

> filt_sigdetach() because in 5.3-BETA2 kqueue uses own mutex. Unfortunately,
> I could not just now to write a small test case to allow everyone to
> reproduce the panic but my user-level server always causes panic on exit on
> unpatched 5.x and sometimes on unpatched 4.10.

Could you print *kn?

also in frame 16:
print kq
print *kq

The problem is some how that the knote is being removed from the list
(or was never on the list), but not being marked detached...

Hmmm. what are the options you are using for rfork?

-- 
  John-Mark Gurney				Voice: +1 415 225 5579

     "All that I will do, has been done, All that I have, has not."
Received on Wed Sep 01 2004 - 13:53:07 UTC

This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:38:09 UTC