Bug 34646

Summary: 4.5-stable crashes on thttpd restart under heavy traffic
Product: Base System Reporter: Dima Ruban <dima>
Component: kernAssignee: freebsd-bugs (Nobody) <bugs>
Status: Closed FIXED    
Severity: Affects Only Me    
Priority: Normal    
Version: 4.5-STABLE   
Hardware: Any   
OS: Any   

Description Dima Ruban 2002-02-05 20:10:01 UTC
	I was able to crash 4.5-stable box by killing thttpd and starting
	it again on a machine with heavy traffic.
	thttpd version is: thttpd/2.22beta4 14nov2001
	Crash dump is available.

	Here's backtrace:

GNU gdb 4.18
Copyright 1998 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "i386-unknown-freebsd"...
SMP 2 cpus
IdlePTD at phsyical address 0x0038d000
initial pcb at physical address 0x002ea860
panicstr: page fault
panic messages:
---
panic: ipsec4_setspidx_inpcb: no PCB found.

mp_lock = 01000001; cpuid = 1; lapic.id = 00000000
boot() called on cpu#1

syncing disks... 

Fatal trap 12: page fault while in kernel mode
mp_lock = 01000002; cpuid = 1; lapic.id = 00000000
fault virtual address   = 0x10
fault code              = supervisor read, page not present
instruction pointer     = 0x8:0xc0235f7f
stack pointer           = 0x10:0xff80faa0
frame pointer           = 0x10:0xff80faf8
code segment            = base rx0, limit 0xfffff, type 0x1b
                        = DPL 0, pres 1, def32 1, gran 1
processor eflags        = interrupt enabled, resume, IOPL = 0
current process         = Idle
interrupt mask          =  <- SMP: XXX
trap number             = 12
panic: page fault
mp_lock = 01000002; cpuid = 1; lapic.id = 00000000
boot() called on cpu#1
Uptime: 18m11s

dumping to dev #da/0x20001, offset 3145752
dump 511 510 509 508 507 506 505 504 503 502 501 500 499 498 497 496 495 494
493 492 491 490 489 488 487 486 485 484 483 482 481 480 479 478 477 476 475
[ ... dump stuff removed ... ]
10 9 8 7 6 5 4 3 2 1 0 
---
#0  dumpsys () at ../../kern/kern_shutdown.c:485
485             if (dumping++) {
#0  dumpsys () at ../../kern/kern_shutdown.c:485
#1  0xc0175f37 in boot (howto=260) at ../../kern/kern_shutdown.c:314
#2  0xc01763a9 in panic (fmt=0xc02bbb79 "%s") at
../../kern/kern_shutdown.c:593
#3  0xc026e535 in trap_fatal (frame=0xff80fa60, eva=16)
    at ../../i386/i386/trap.c:956
#4  0xc026e1a1 in trap_pfault (frame=0xff80fa60, usermode=0, eva=16)
    at ../../i386/i386/trap.c:849
#5  0xc026dcfb in trap (frame={tf_fs = -955777000, tf_es = -952238064, 
      tf_ds = -955777008, tf_edi = 2, tf_esi = 0, tf_ebp = -8324360, 
      tf_isp = -8324468, tf_ebx = 0, tf_edx = 160, tf_ecx = 8192, tf_eax = 0, 
      tf_trapno = 12, tf_err = 0, tf_eip = -1071423617, tf_cs = 8, 
      tf_eflags = 66118, tf_esp = -558233024, tf_ss = 0})
    at ../../i386/i386/trap.c:448
#6  0xc0235f7f in vnode_pager_generic_putpages (vp=0xdeba0a40, m=0xff80fb9c, 
    bytecount=8192, flags=0, rtvals=0xff80fb68) at machine/globals.h:114
#7  0xc0220d96 in ffs_putpages (ap=0xff80fb2c)
    at ../../ufs/ufs/ufs_readwrite.c:722
#8  0xc0235de2 in vnode_pager_putpages (object=0xdee4b840, m=0xff80fb9c, 
    count=2, sync=0, rtvals=0xff80fb68) at vnode_if.h:1147
#9  0xc0232d3f in vm_pageout_flush (mc=0xff80fb9c, count=2, flags=0)
    at ../../vm/vm_pager.h:145
#10 0xc022fcef in vm_object_page_clean (object=0xdee4b840, start=0, end=0, 
    flags=4) at ../../vm/vm_object.c:680
#11 0xc01a579c in vfs_msync (mp=0xc715f000, flags=2)
    at ../../kern/vfs_subr.c:2712
#12 0xc01a6810 in sync (p=0xc0302080, uap=0x0) at
../../kern/vfs_syscalls.c:546
#13 0xc0175cea in boot (howto=256) at ../../kern/kern_shutdown.c:235
#14 0xc01763a9 in panic (
    fmt=0xc029cf80 "ipsec4_setspidx_inpcb: no PCB found.\n")
    at ../../kern/kern_shutdown.c:593
#15 0xc01dd1a3 in ipsec4_setspidx_inpcb (m=0xc1102000, pcb=0x0)
    at ../../netinet6/ipsec.c:721
#16 0xc01dcbb9 in ipsec4_getpolicybysock (m=0xc1102000, dir=2, so=0xdac7df00, 
    error=0xff80fdd4) at ../../netinet6/ipsec.c:258
#17 0xc01ca14a in ip_output (m0=0xc1102000, opt=0x0, ro=0xdc97ab98, flags=0, 
    imo=0x0) at ../../netinet/ip_output.c:446
#18 0xc01d2fe7 in syncache_respond (sc=0xdc97ab60, m=0xc1102000)
    at ../../netinet/tcp_syncache.c:1184
#19 0xc01d2871 in syncache_add (inc=0xff80fedc, to=0xff80ff48, th=0xc113a034, 
    sop=0xff80fed8, m=0xc1102000) at ../../netinet/tcp_syncache.c:842
#20 0xc01cd6ac in tcp_input (m=0xc1102000, off0=20, proto=6)
    at ../../netinet/tcp_input.c:826
#21 0xc01c8a17 in ip_input (m=0xc1102000) at ../../netinet/ip_input.c:815
#22 0xc01c8a8b in ipintr () at ../../netinet/ip_input.c:843
(kgdb)

Even though IPSec is compiled into the kernel, this particular box isn't
running any of the IPSec stuff.

Fix: 

Not known.
How-To-Repeat: 	I haven't tried to reproduce this problem outside my enviroment.
	But for me all it comes down to is rebooting machine (thttpd
	starts on reboot), waiting a few minutes 'till it starts getting
	traffic, then killing thttpd and starting it again.
Comment 1 silby freebsd_committer freebsd_triage 2002-02-24 07:44:30 UTC
State Changed
From-To: open->closed

This should be fixed by the recent fixes to the syncache. 
If cvsupping to the latest -stable does not solve the problem, 
please tell me so that the PR can be reopened.