>Number:         35723
>Category:       kern
>Synopsis:       LOCKDEBUG doesn't handle leaks very well
>Confidential:   no
>Severity:       non-critical
>Priority:       low
>Responsible:    kern-bug-people
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Tue Feb 20 02:45:00 +0000 2007
>Originator:     Andrew Doran
>Release:        NetBSD 4.99.12
>Organization:
The NetBSD Project
>Environment:
Architecture: i386
Machine: i386
>Description:
xtraeme@ noted the following panic:

panic: lockdebug_lookup: uninitialized lock (1, id=1049007)
lockdebug_more(1001af,c028e84d,0,cfa3db28,c2daf800) at netbsd:lockdebug_more
mutex_vector_enter(ce63c08c,c2641e00,c2655300,c2648360,0) at netbsd:mutex_vector_enter+0x9a
kauth_cred_free(ce63c08c,cfa17200,3b9aca00,0,cfa17200) at netbsd:kauth_cred_free+0x11
nfs_request(cd634c30,c2651b00,12,cfa17200,ce63c114) at netbsd:nfs_request+0x420
nfs_statvfs(c2dae000,c4262000,cfa17200,c2dae000,0) at netbsd:nfs_statvfs+0x12e
dostatvfs(c2dae000,c4262000,cfa17200,1,1) at netbsd:dostatvfs+0x143
sys_statvfs1(cfa17200,cfa3dc48,cfa3dc68,0,c032390f) at netbsd:sys_statvfs1+0x8e
syscall_plain() at netbsd:syscall_plain+0x115
--- syscall (number 357) ---

There are at least three problems:

1. Something in the MI kernel is either leaking memory, or failing to destroy
   locks. The "id" above indicates that the system has over 1M active locks.

2. The ID is above the current limit for subr_lockdebug.c (1048576).  It may
   be allocating more IDs/memory than it should.

3. subr_lockdebug.c should note when the limit is exceeded.
>How-To-Repeat:
Long uptime.
>Fix:
As above.