Date: 25 May 2006 18:01:30 +0200 From: "Arno J. Klaassen" <arno@heho.snv.jussieu.fr> To: freebsd-stable@freebsd.org Subject: kmem leak in tmpmfs? Message-ID: <wpy7wq6qlh.fsf@heho.labo>
next in thread | raw e-mail | index | archive | help
Hello,
I get a very easy to reproduce panic on 6.1-STABLE :
/etc/periodic/weekly/310.locate panics with
panic: kmem_malloc(4096): kmem_map too small: 335544320 total allocated
(kgdb) where
#0 doadump () at pcpu.h:165
#1 0xc0577574 in boot (howto=260)
at /files/bsd/src6/sys/kern/kern_shutdown.c:409
#2 0xc05778a6 in panic (
fmt=0xc078dc1d "kmem_malloc(%ld): kmem_map too small: %ld total allocated")
at /files/bsd/src6/sys/kern/kern_shutdown.c:565
#3 0xc06df1ab in kmem_malloc (map=0xc10430c0, size=4096, flags=258)
at /files/bsd/src6/sys/vm/vm_kern.c:299
#4 0xc06d49a7 in page_alloc (zone=0xc1035700, bytes=0, pflag=0x0, wait=0)
at /files/bsd/src6/sys/vm/uma_core.c:958
#5 0xc06d43db in slab_zalloc (zone=0xc1035700, wait=258)
at /files/bsd/src6/sys/vm/uma_core.c:823
#6 0xc06d60f6 in uma_zone_slab (zone=0xc1035700, flags=2)
at /files/bsd/src6/sys/vm/uma_core.c:2025
#7 0xc06d635f in uma_zalloc_bucket (zone=0xc1035700, flags=2)
at /files/bsd/src6/sys/vm/uma_core.c:2134
#8 0xc06d5f39 in uma_zalloc_arg (zone=0xc1035700, udata=0x0, flags=2)
at /files/bsd/src6/sys/vm/uma_core.c:1942
#9 0xc05d17ff in cache_enter (dvp=0xc8bf1110, vp=0xc8dd4110, cnp=0xfe14bbbc)
at uma.h:275
#10 0xc06c77c4 in ufs_lookup (ap=0xfe14ba40)
at /files/bsd/src6/sys/ufs/ufs/ufs_lookup.c:583
#11 0xc0756073 in VOP_CACHEDLOOKUP_APV (vop=0x0, a=0x0) at vnode_if.c:150
#12 0xc05d1dfa in vfs_cache_lookup (ap=0x0) at vnode_if.h:82
#13 0xc0755fe8 in VOP_LOOKUP_APV (vop=0xc07c8a60, a=0xfe14baec)
at vnode_if.c:99
#14 0xc05d71fb in lookup (ndp=0xfe14bb94) at vnode_if.h:56
#15 0xc05d6998 in namei (ndp=0xfe14bb94)
at /files/bsd/src6/sys/kern/vfs_lookup.c:203
#16 0xc05e865f in kern_lstat (td=0xc6b29780, path=0x0, pathseg=UIO_USERSPACE,
sbp=0x0) at /files/bsd/src6/sys/kern/vfs_syscalls.c:2125
#17 0xc05e85df in lstat (td=0x0, uap=0xfe14bd04)
at /files/bsd/src6/sys/kern/vfs_syscalls.c:2109
#18 0xc073e672 in syscall (frame=
{tf_fs = 59, tf_es = 59, tf_ds = 59, tf_edi = 134664008, tf_esi = 134663936, tf_ebp = -1077941544, tf_isp = -32195228, tf_ebx = 672511016, tf_edx = 134663936, tf_ecx = 134561792, tf_eax = 190, tf_trapno = 0, tf_err = 2, tf_eip = 672396855, tf_cs = 51, tf_eflags = 582, tf_esp = -1077941700, tf_ss = 59})
at /files/bsd/src6/sys/i386/i386/trap.c:981
#19 0xc072b21f in Xint0x80_syscall ()
at /files/bsd/src6/sys/i386/i386/exception.s:200
#20 0x00000033 in ?? ()
Previous frame inner to this frame (corrupt stack?)
(kgdb)
This box has nothing particular, apart from maybe a large number
of stamp-file based test-databases (with a lot of zero-sized
files named .key=value).
Producing this bug is easy :
- set tmpmfs="YES" and set tmpsize greater than around 220m
- start /etc/periodic/weekly/310.locate (and nothing else!)
- wait two-three hours and bang
Last test is with tmpfs=1024m and I monitored df -h /tmp and
vmstat -zm every minute; when the system panics, last output is :
Filesystem Size Used Avail Capacity Mounted on
/dev/md0 989M 219M 691M 24% /var/tmp
vmstat -zm | fgrep md0
md0: 512, 0, 453257, 15, 453437
I'm quite not an expert, but looks to me as if md0 use stays
almost 100% in kmem and is never swapped (as it is supposed to do
by default according to the man-page).
While here, and being struck as well by the nfsd-bug, at least
vfs_lookup.c seems common to both problems.
Full vmstat-zm logs available.
Thanx, Arno
--
Arno J. Klaassen
SCITO S.A.
8 rue des Haies
F-75020 Paris, France
http://scito.com
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?wpy7wq6qlh.fsf>