>Hi, > >I've got this on b129 (with dedup enabled). >Is it a known issue? > >> ::regs >%rax = 0x0000000000000000 %r9 = 0xffffff003de35cf0 >%rbx = 0x0000000000000000 %r10 = 0xffffff0910223400 >%rcx = 0x0000000400000008 %r11 = 0x0000000000000000 >%rdx = 0xffffff0ad3f94900 %r12 = 0x0000000400000008 >%rsi = 0xffffff003de35cb0 %r13 = 0xffffff0ad3f94900 >%rdi = 0xfffffffffbbb0470 %r14 = 0xffffff090080d000 >%r8 = 0xffffff003de35c00 %r15 = 0x0000000000000000 > >%rip = 0xfffffffffb85b540 vpanic >%rbp = 0xffffff003de35ce0 >%rsp = 0xffffff003de35bf8 >%rflags = 0x00000246 > id=0 vip=0 vif=0 ac=0 vm=0 rf=0 nt=0 iopl=0x0 > status=<of,df,IF,tf,sf,ZF,af,PF,cf> > > %cs = 0x0030 %ds = 0x004b %es = 0x004b >%trapno = 0x0 %fs = 0x0000 %gs = 0x01c3 > %err = 0x0 >> $C >ffffff003de35ce0 vpanic() >ffffff003de35d30 vmem_hash_delete+0xd1(ffffff090080d000, >ffffff0ad3f94900, 400000008) >ffffff003de35d80 vmem_xfree+0x40(ffffff090080d000, ffffff0ad3f94900, 400000008) >ffffff003de35db0 vmem_free+0x29(ffffff090080d000, ffffff0ad3f94900, 400000008) >ffffff003de35dd0 kmem_free+0x217(ffffff0ad3f94900, 400000008) >ffffff003de35df0 crgrprele+0x36(ffffff0ad3f94900) >ffffff003de35e10 crfree+0x6a(ffffff0942e62480) >ffffff003de35e40 crset+0x36(ffffff092fa02728, ffffff0941e47128) >ffffff003de35ec0 seteuid+0x19e(0) >ffffff003de35f10 sys_syscall32+0xff() >
No, it's not a "known issue" in that sense that we know that some part of the code plays loose and fast with the credential references but we haven't quite figured it out yet. If you can forward use the core dump that might be helpful. One additional problem is that "cred_t" used to include all the groups as part of the cred_t proper but as of build 129 the groups are allocated in a different structure. Before build 129 a bad credential reference count wouldn't be detected but in build 129, the crgrp_t is freed and a second free or use after free will typically cause a panic. We've seen panics in build 130 and this panic in build 129 adds a little bit of information. Casper
