nothing obvious from that info, no.  how about "call dump_kmemstats"?
if that doesn't point out anything that you could look at all
the various pools to see if you can find the memory that way.
unfortunately there's no handy function for that...  yet.

what were you doing at the time (other than compiling something)?

-Chuck


"Gordon W. Ross" writes:
> Does anyone see anything obviously wrong with this?
> 
> panic: malloc: out of space in kmem_map
> Stopped in cpp at       _Debugger+0x6:  unlk    a6
> db> call uvm_dump
> Current UVM status:
>   pagesize=8192 (0x2000), pagemask=0x1fff, pageshift=13
>   1850 VM pages: 434 active, 292 inactive, 26 wired, 646 free
>   freemin=32, free-target=42, inactive-target=448, wired-max=616
>   faults=2409323, traps=3257168, intrs=1573255, ctxswitch=1244209
>   softint=626483, syscalls=3923933, swapins=130, swapouts=136
>   fault counts:
>     noram=0, noanon=0, pgwait=9, pgrele=0
>     ok relocks(total)=20519(20524), anget(retrys)=529054(3955), amapcopy=349619
>     neighbor anon/obj pg=627292/2401008, gets(lock/unlock)=1063845/16569
>     cases: anon=407890, anoncow=121164, obj=906573, prcopy=157267, przero=816429
>   daemon and swap counts:
>     woke=1143, revs=120, scans=12957, swout=96
>     busy=85, freed=7922, reactivate=2, deactivate=15652
>     pageouts=1239, pending=1239, nswget=3960
>     nswapdev=1, nanon=14062, nfreeanon=13525
>     swpages=12330, swpginuse=383, swpgonly=272 paging=0
>   kernel pointers:
>     objs(kern/kmem/mb)=0xf80f31e8/0xf80f32b8/0xf80f32d0
> 0x2704
> db> cont