DragonFlyBSD

panic: vm_object: self-hold in terminate or collapse
cpuid = 0
Trace beginning at frame 0x598b9a7c
panic(ffffffff,0,8304098,598b9ab0,59c0b8d8) at 0x80f22cd
panic(8304098,59c0b8d8,59c0b9ec,5a5242dc,5a5242dc) at 0x80f22cd
vm_object_lock(831dbb4,828dc20,828d3f4,0,59c0b8d8) at 0x828b8d5
vm_object_terminate(5a5242dc,828eedb,5a5245cc,7,59c0b8d8) at 0x828bec3
vm_object_deallocate_locked(5a5242dc,7,0,0,0) at 0x828d222
vmspace_fork(577def78,80c7b93,571c4460,571c4438,59bd54b4) at 0x82868c5
vm_fork(59bd5460,571c43e0,40000014,82d2910,138) at 0x8282ba1
fork1(59ab2278,40000014,598b9c30,831dbb4,59ab2278) at 0x80de720
sys_fork(598b9c7c,5724bd58,4,5724be6c,831dbbc) at 0x80dea42
syscall2(598b9d40,40400f74,598b9cf0,31307,0) at 0x82b1525
user_trap(598b9d40,1,598b9d40,59c0bb04,28348360) at 0x82b1799
go_user(598b9d38,0,0,7b,0) at 0x82b1c97
Debugger("panic")

Running latest commit with vm_object fixes; vkernel compiled with DEBUG_LOCKS.
(without debug locks, there is a stall on vmobj hold_wait).
'self-hold' panic is a check in debug_locks that checks if the current thread
attempts to release a vm_object but that thread itself has a hold on the object.

(running http://leaf.dragonflybsd.org/~vsrinivas/vm.c in a vkernel, with 4
virtual CPUs).