In Message <20030824200040.A25950@noc.untraceable.net> ,
   Andrew Brown <atatat@atatdot.net> wrote:

=>>   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".

   The original message, which was dropped from the reply, was:

lsof: can't read process table: proc size mismatch (61696 total, 804 chunks)

which is raised by kvm_getprocs() when the size returned from
sysctl({CTL_KERN, KERN_PROC, op, arg}, 4, NULL, &size, NULL, 0)
isn't zero mod sizeof(struct kinfo_proc). In this case, the kernel
sees the size as 964, while libkvm sees 804.

=>>   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?
=>
=> [ ... ]
=>
=>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.

   That wouldn't help since the error occurs in libkvm. I'm running
without LOCKDEBUG in the kernel and it is fine. I don't really have
particular needs for LOCKDEBUG or lsof on this box; I'd just like
to see the bug squashed.

					Gary D. Duzan