Hi Dan,
On 05/11/2015 14:57, Dan McDonald wrote:
On Nov 5, 2015, at 6:38 AM, Al Slater <al.sla...@scluk.com> wrote:
I have the 4Gb core file. Is there anything useful I can extract
from it to try and spot where the problem is?
Your one ::findleaks showed nothing. Did your 4GB corefile have
::findleaks show nothing as well?
::umausers may be helpful.
root@loki:/export/home/BRIGHTON/aslate# mdb core.3041
Loading modules: [ libumem.so.1 libc.so.1 libcmdutils.so.1 libuutil.so.1
ld.so.1 ]
::umausers
71424 bytes for 62 allocations with data size 1152:
libumem.so.1`umem_cache_alloc_debug+0x1fe
libumem.so.1`umem_cache_alloc+0x18f
libumem.so.1`umem_alloc+0x50
libumem.so.1`umem_malloc+0x36
libumem.so.1`calloc+0x50
i_ilbd_alloc_sg+0x13
ilbd_create_sg+0x9a
ilbd_scf_instance_walk_pg+0x2a6
ilbd_walk_sg_pgs+0x37
i_ilbd_read_config+0x28
main_loop+0x7f
main+0x1d3
_start+0x83
53120 bytes for 664 allocations with data size 80:
libumem.so.1`umem_cache_alloc_debug+0x1fe
libumem.so.1`umem_cache_alloc+0x18f
libumem.so.1`umem_alloc+0x50
libumem.so.1`umem_malloc+0x36
libumem.so.1`calloc+0x50
ilbd_hc_srv_add+0x18
ilbd_hc_associate_rule+0xd8
ilbd_create_rule+0x1a3
ilbd_scf_instance_walk_pg+0x1c4
ilbd_walk_rule_pgs+0x37
i_ilbd_read_config+0x4e
main_loop+0x7f
main+0x1d3
_start+0x83
53120 bytes for 664 allocations with data size 80:
libumem.so.1`umem_cache_alloc_debug+0x1fe
libumem.so.1`umem_cache_alloc+0x18f
libumem.so.1`umem_alloc+0x50
libumem.so.1`umem_malloc+0x36
libumem.so.1`calloc+0x50
i_add_srv2sg+0x15
ilbd_add_server_to_group+0x310
ilbd_scf_instance_walk_pg+0x2dd
ilbd_walk_sg_pgs+0x37
i_ilbd_read_config+0x28
main_loop+0x7f
main+0x1d3
_start+0x83
31584 bytes for 658 allocations with data size 48:
libumem.so.1`umem_cache_alloc_debug+0x1fe
libumem.so.1`umem_cache_alloc+0x99
libumem.so.1`umem_alloc+0x50
libumem.so.1`umem_malloc+0x36
libumem.so.1`calloc+0x50
libinetutil.so.1`iu_schedule_timer_ms+0x2d
libinetutil.so.1`iu_schedule_timer+0x37
ilbd_hc_restart_timer+0xbc
ilbd_hc_probe_timer+0x23
libinetutil.so.1`iu_expire_timers+0xbe
ilbd_hc_timeout+0x11
main_loop+0xe6
main+0x1d3
_start+0x83
12288 bytes for 1 allocations with data size 12288:
libumem.so.1`umem_cache_alloc_debug+0x1fe
libumem.so.1`umem_cache_alloc+0x18f
libumem.so.1`umem_alloc+0x50
libumem.so.1`umem_malloc+0x36
libc.so.1`ltzset_u+0xa2
libc.so.1`localtime_r+0x35
libc.so.1`ctime_r+0x2c
libc.so.1`vsyslog+0x1e4
ilbd_log+0x48
main+0x15e
_start+0x83
10368 bytes for 54 allocations with data size 192:
libumem.so.1`umem_cache_alloc_debug+0x1fe
libumem.so.1`umem_cache_alloc+0x99
libumem.so.1`umem_alloc+0x50
libumem.so.1`umem_malloc+0x36
libumem.so.1`calloc+0x50
i_alloc_ilbd_rule+0x17
ilbd_create_rule+0xfa
ilbd_scf_instance_walk_pg+0x1c4
ilbd_walk_rule_pgs+0x37
i_ilbd_read_config+0x4e
main_loop+0x7f
main+0x1d3
_start+0x83
Sharing the corefile would also be helpful.
I have put it on dropbox
https://www.dropbox.com/s/y6cv78d1xk5j5u7/core.3041.gz?dl=0
I'm assuming, given you see problems at 4GB that ilbd is a 32-bit
process, right?
Yes,
# file /usr/lib/inet/ilbd
/usr/lib/inet/ilbd: ELF 32-bit LSB executable 80386 Version 1,
dynamically linked, not stripped, no debugging information available
cheers
--
Al Slater
Technical Director
SCL
Phone : +44 (0)1273 666607
Fax : +44 (0)1273 666601
email : al.sla...@scluk.com
Stanton Consultancy Ltd
Park Gate, 161 Preston Road, Brighton, East Sussex, BN1 6AU
Registered in England Company number: 1957652 VAT number: GB 760 2433 55
_______________________________________________
OmniOS-discuss mailing list
OmniOS-discuss@lists.omniti.com
http://lists.omniti.com/mailman/listinfo/omnios-discuss
