[OmniOS-discuss] ILB memory leak?

Al Slater al.slater at scluk.com
Fri Nov 6 07:22:11 UTC 2015


Hi Dan,

On 05/11/2015 14:57, Dan McDonald wrote:
>
>> On Nov 5, 2015, at 6:38 AM, Al Slater <al.slater at 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 at 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.slater at 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



More information about the OmniOS-discuss mailing list