>   I sorted out what the problem was. I had LOCKDEBUG enabled in
>my kernel, which adds fields to struct lock and struct simplelock,
>which must end up being part of struct kinfo_proc, since changing
>the flag changes the struct size, which confuses kvm_getprocs().

actually, it might be confusing something else.  lsof does a lot of
groveling, any piece of which might be confused by lockdebug being
set.  i know i encountered this when developing pmap(1), but since we
control that program entirely, i simply taught it to figure out
whether LOCKDEBUG was set and built the code that needed to know
twice.  the use of LOCKDEBUG inflates the size of the lock structures,
which inflates the size of some other structures as a "side effect".

>   Should I send-pr this? In general, kernel options shouldn't
>break userland APIs, but LOCKDEBUG may be different enough not to
>care. (For example, it doesn't show up in options(4).)  Or maybe
>kvm_getprocs() and/or the KERN_PROC sysctl API are just hopelessly
>broken and lsof needs to use something else. Opinions?

if lsof was using kvm_getproc2() and/or the KERN_PROC2 sysctl, it
might be okay, but i think lsof is just using kvm_read().  not that
that would help much, i suspect.

for now, you can try building lsof with LOCKDEBUG set (add it to the
CPPFLAGS value in the pkg Makefile).  i'll see what other things i can
find out.

-- 
|-----< "CODE WARRIOR" >-----|
codewarrior@daemon.org             * "ah!  i see you have the internet
twofsonet@graffiti.com (Andrew Brown)                that goes *ping*!"
werdna@squooshy.com       * "information is power -- share the wealth."