Fwd: propgagate_priority() crashes: recursive msleep() ??

John Baldwin jhb at FreeBSD.org
Fri Nov 14 08:30:21 PST 2003


On 14-Nov-2003 Peter Edwards wrote:
> (Aplogies if this message is a duplicate: The original is AWOL for quite 
> a while now)
> 
> Hi,
> I'm getting a crash in propagate priority, as mentioned by a few people recently. Bug reports and
> comments about it seemed to have dropped off, so given that I can reliably reproduce it, I was
> trying to work out why it's going on.
> 
> One thing I found quite odd was the following stack trace. It appears that msleep() is being
> called recursively via cursig() calling stopevent. When msleep calls cursig(), it has temporarily
> dropped Giant. Surely this is bogus? (This is from a a kernel updated in the last few hours)
> 
>#0  sched_switch (td=0xc4b30780) at /scratch/src/sys/kern/sched_4bsd.c:606
>#1  0xc050d8db in mi_switch () at /scratch/src/sys/kern/kern_synch.c:514
>#2  0xc050cf7f in msleep (ident=0xc4dc2bc8, mtx=0xc4dc2b04, priority=92, wmesg=0x0, 
>     timo=0) at /scratch/src/sys/kern/kern_synch.c:255
>#3  0xc0534255 in stopevent (p=0xc4dc2a98, event=2, val=2)
>     at /scratch/src/sys/kern/sys_process.c:740
>#4  0xc0509362 in issignal (td=0xc4b30780) at /scratch/src/sys/kern/kern_sig.c:2082
>#5  0xc0504eb8 in cursig (td=0xc4b30780) at /scratch/src/sys/sys/signalvar.h:227
>#6  0xc050d0f2 in msleep (ident=0xc4dc2a98, mtx=0xc4dc2b04, priority=348, wmesg=0x0, 
>     timo=0) at /scratch/src/sys/kern/kern_synch.c:294
>#7  0xc04eb82f in wait1 (td=0xc4b30780, uap=0xddcd6d10, compat=0)
>     at /scratch/src/sys/kern/kern_exit.c:766
>#8  0xc04eab90 in wait4 (td=0x0, uap=0x0) at /scratch/src/sys/kern/kern_exit.c:548
>#9  0xc06241d0 in syscall (frame=
>       {tf_fs = 47, tf_es = 47, tf_ds = 47, tf_edi = 134899628, tf_esi = 134912305, tf_ebp =
> -1077943784, tf_isp = -573739660, tf_ebx = 772, tf_edx = 135012352, tf_ecx = 13, tf_eax = 7,
> tf_trapno = 12, tf_err = 2, tf_eip = 134525375, tf_cs = 31, tf_eflags = 646, tf_esp =
> -1077943812, tf_ss = 47}) at /scratch/src/sys/i386/i386/trap.c:1010

Are you using gdb or something else that does ptrace?  Jeff has pointed
out why pp panics here, because this thread owns the sigacts lock while
asleep.  However, doing a double sleep like this is very bogus and bad.
Grrrr.

-- 

John Baldwin <jhb at FreeBSD.org>  <><  http://www.FreeBSD.org/~jhb/
"Power Users Use the Power to Serve!"  -  http://www.FreeBSD.org/


More information about the freebsd-current mailing list