Hello everybody,
when we have mdb active there is a core for raidctl every 5 minutes. Can you
help to debug it ?
# mdb core.raidctl.10987
Loading modules: [ libumem.so.1 libc.so.1 libnvpair.so.1 libavl.so.1
libuutil.so.1 ld.so.1 ]
> ::status
debugging core file of raidctl (32-bit) from srx114
file: /usr/sbin/raidctl
initial argv: /usr/sbin/raidctl
threading model: multi-threaded
status: process terminated by SIGSEGV (Segmentation Fault)
> ::showrev
Hostname: srx114
Release: 5.10
Kernel architecture: i86pc
Application architecture: i386
Kernel version: SunOS 5.10 i86pc Generic_137112-01
Platform: i86pc
> ::stack
libraidcfg.so.1`obj_controller_act+0x1ae(fef692b8, 1, 0, 0, 0)
libraidcfg.so.1`raidcfg_open_controller+0x55(1, 0)
0x8053361(1, 0, 0)
0x805280a(0, 80473d0, 1, 0)
main+0x492(1, 80473d0, 80473d8)
_start+0x7a(1, 8047530, 0, 8047542, 804772f, 8047738)
> $G
C++ symbol demangling enabled
> ::stack
libraidcfg.so.1`obj_controller_act+0x1ae(fef692b8, 1, 0, 0, 0)
libraidcfg.so.1`raidcfg_open_controller+0x55(1, 0)
0x8053361(1, 0, 0)
0x805280a(0, 80473d0, 1, 0)
main+0x492(1, 80473d0, 80473d8)
_start+0x7a(1, 8047530, 0, 8047542, 804772f, 8047738)
> ::walk thread
1
> ::walk ulwps
> ::stackregs 1 ! grep '('
080472b4 libraidcfg.so.1`obj_controller_act+0x1ae(fef692b8)
080472e0 libraidcfg.so.1`raidcfg_open_controller+0x55(1)
080472f4 0x8053361(1)
08047354 0x805280a(0)
080473a4 main+0x492(1)
080473c4 _start+0x7a(1)
> ::umem_verify
Cache Name Addr Cache Integrity
umem_magazine_1 808e010 clean
umem_magazine_3 808e390 clean
umem_magazine_7 808e710 clean
umem_magazine_15 808ea90 clean
umem_magazine_31 808f010 clean
umem_magazine_47 808f390 clean
umem_magazine_63 808f710 clean
umem_magazine_95 808fa90 clean
umem_magazine_143 8091010 clean
umem_slab_cache 8091390 clean
umem_bufctl_cache 8091710 clean
umem_bufctl_audit_cache 8091a90 clean
umem_alloc_8 8093010 clean
umem_alloc_16 8093390 clean
umem_alloc_24 8093710 clean
umem_alloc_32 8093a90 clean
umem_alloc_40 8096010 clean
umem_alloc_48 8096390 clean
umem_alloc_56 8096710 clean
umem_alloc_64 8096a90 clean
umem_alloc_80 8097010 clean
umem_alloc_96 8097390 clean
umem_alloc_112 8097710 clean
umem_alloc_128 8097a90 clean
umem_alloc_160 8099010 clean
umem_alloc_192 8099390 clean
umem_alloc_224 8099710 clean
umem_alloc_256 8099a90 clean
umem_alloc_320 809b010 clean
umem_alloc_384 809b390 clean
umem_alloc_448 809b710 clean
umem_alloc_512 809ba90 clean
umem_alloc_640 809e010 clean
umem_alloc_768 809e390 clean
umem_alloc_896 809e710 clean
umem_alloc_1152 809ea90 clean
umem_alloc_1344 80a0010 clean
umem_alloc_1600 80a0390 clean
umem_alloc_2048 80a0710 clean
umem_alloc_2688 80a0a90 clean
umem_alloc_4096 80a1010 clean
umem_alloc_8192 80a1390 clean
umem_alloc_12288 80a1710 clean
umem_alloc_16384 80a1a90 clean
> ::findleaks -dv
findleaks: maximum buffers => 78
findleaks: actual buffers => 40
findleaks:
findleaks: potential pointers => 72395
findleaks: dismissals => 51899 (71.6%)
findleaks: misses => 17320 (23.9%)
findleaks: dups => 3137 ( 4.3%)
findleaks: follows => 39 ( 0.0%)
findleaks:
findleaks: elapsed wall time => 0 seconds
findleaks:
CACHE LEAKED BUFCTL CALLER
08097390 1 080cbae8 libraidcfg.so.1`raid_obj_attr_new+0x87
----------------------------------------------------------------------
Total 1 buffer, 96 bytes
umem_alloc_96 leak: 1 buffer, 96 bytes
ADDR BUFADDR TIMESTAMP THREAD
CACHE LASTLOG CONTENTS
80cbae8 80caf58 4613796dd970 1
8097390 8076c1c 0
libumem.so.1`umem_cache_alloc_debug+0x16c
libumem.so.1`umem_cache_alloc+0x15c
libumem.so.1`umem_alloc+0x3f
libumem.so.1`malloc+0x23
libumem.so.1`calloc+0x49
libraidcfg.so.1`raid_obj_attr_new+0x87
libraidcfg.so.1`raid_obj_create+0x68
libraidcfg.so.1`obj_scan_comp+0xbc
libraidcfg.so.1`obj_get_comp+0x4a
libraidcfg.so.1`raidcfg_list_head+0x51
0x8053350
0x805280a
main+0x492
_start+0x7a
>
6000 -rw------- 1 root root 3056302 Jul 8 10:10 core.raidctl.10987
6000 -rw------- 1 root root 3056302 Jul 8 10:15 core.raidctl.14336
Any clue ?
This message posted from opensolaris.org
