Hi, Seems like it was caused by the ftp daemon from a non global zone. Opened files by the process: /var/run/name_service_door /etc/passwd /etc/group
On Mon, Feb 8, 2010 at 11:32 AM, <Casper.Dik at sun.com> wrote: > >>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 > > -- Piotr Jasiukajtis | estibi | SCA OS0072 http://estseg.blogspot.com
