Hello,
I have a example of memory leak.
What does means the alloc fail= 335 ?
# mdb -p 1408
Loading modules: [ ld.so.1 libumem.so.1 libc.so.1 libuutil.so.1 ]
> ::findleaks -dv
findleaks: maximum buffers => 14920
findleaks: actual buffers => 14497
findleaks:
findleaks: potential pointers => 316574898
findleaks: dismissals => 309520985 (97.7%)
findleaks: misses => 6929221 ( 2.1%)
findleaks: dups => 110601 ( 0.0%)
findleaks: follows => 14091 ( 0.0%)
findleaks:
findleaks: elapsed wall time => 54 seconds
findleaks:
BYTES LEAKED VMEM_SEG CALLER
4096 4 fffffd7ffc539000 MMAP
16384 1 fffffd7ffe83d000 MMAP
4096 1 fffffd7ffe812000 MMAP
8192 1 fffffd7ffd7bc000 MMAP
24016 397 124a2a0 libstdc++.so.6.0.8`_Znwm+0x1e
------------------------------------------------------------------------
Total 401 oversized leaks, 9567120 bytes
CACHE LEAKED BUFCTL CALLER
00000000004cf468 1 000000000050ed20 libstdc++.so.6.0.8`_Znwm+0x1e
00000000004cf468 1 000000000050c000 libstdc++.so.6.0.8`_Znwm+0x1e
00000000004cf468 1 000000000050ea80 libstdc++.so.6.0.8`_Znwm+0x1e
00000000004cf468 1 000000000050c0e0 libstdc++.so.6.0.8`_Znwm+0x1e
00000000004cf468 1 000000000050ee00 libstdc++.so.6.0.8`_Znwm+0x1e
----------------------------------------------------------------------
Total 5 buffers, 80 bytes
mmap(2) leak: [fffffd7ffc539000, fffffd7ffc53a000), 4096 bytes
mmap(2) leak: [fffffd7ffe83d000, fffffd7ffe841000), 16384 bytes
mmap(2) leak: [fffffd7ffe812000, fffffd7ffe813000), 4096 bytes
mmap(2) leak: [fffffd7ffd7bc000, fffffd7ffd7be000), 8192 bytes
umem_oversize leak: 397 vmem_segs, 24016 bytes each, 9534352 bytes total
ADDR TYPE START END SIZE
THREAD TIMESTAMP
124a2a0 ALLC 1252000 1257dd0 24016
1 56bd6f2a6fe1
libumem.so.1`vmem_hash_insert+0x90
libumem.so.1`vmem_seg_alloc+0x1c4
libumem.so.1`vmem_xalloc+0x50b
libumem.so.1`vmem_alloc+0x15a
libumem.so.1`umem_alloc+0x60
libumem.so.1`malloc+0x2e
libstdc++.so.6.0.8`_Znwm+0x1e
libstdc++.so.6.0.8`_Znam+9
> ::umastat
cache buf buf buf memory alloc alloc
name size in use total in use succeed fail
------------------------- ------ ------ ------ --------- --------- -----
umem_magazine_1 16 5 101 4096 6 0
umem_magazine_3 32 356 378 24576 356 0
umem_magazine_7 64 20 84 8192 92 0
umem_magazine_15 128 11 21 4096 11 0
umem_magazine_31 256 0 0 0 0 0
umem_magazine_47 384 0 0 0 0 0
umem_magazine_63 512 0 0 0 0 0
umem_magazine_95 768 0 0 0 0 0
umem_magazine_143 1152 0 0 0 0 0
umem_slab_cache 56 638 650 53248 638 0
umem_bufctl_cache 24 0 0 0 0 0
umem_bufctl_audit_cache 192 15328 15336 3489792 15328 0
umem_alloc_8 8 0 0 0 0 0
umem_alloc_16 16 79 170 8192 2098631 0
umem_alloc_32 32 267 320 20480 306 0
umem_alloc_48 48 4653 4692 376832 6028 0
umem_alloc_64 64 5554 5568 712704 12642 0
umem_alloc_80 80 2492 2520 286720 5185 0
umem_alloc_96 96 492 512 65536 654 0
umem_alloc_112 112 95 112 16384 103 0
umem_alloc_128 128 38 42 8192 42 0
umem_alloc_160 160 12 21 4096 86 0
umem_alloc_192 192 2 16 4096 2 0
umem_alloc_224 224 5 16 4096 848 0
umem_alloc_256 256 1 12 4096 1 0
umem_alloc_320 320 7 1010 413696 560719 0
umem_alloc_384 384 34 36 16384 41 0
umem_alloc_448 448 5 8 4096 10 0
umem_alloc_512 512 1 7 4096 2 0
umem_alloc_640 640 11 22 16384 16 0
umem_alloc_768 768 2 9 8192 424 0
umem_alloc_896 896 1 4 4096 2 0
umem_alloc_1152 1152 11 20 24576 127 0
umem_alloc_1344 1344 4 40 61440 17179 0
umem_alloc_1600 1600 3 7 12288 5 0
umem_alloc_2048 2048 2 9 20480 6 0
umem_alloc_2688 2688 5 7 20480 10 0
umem_alloc_4096 4096 6 7 57344 335 0
umem_alloc_8192 8192 118 119 1462272 565 0
umem_alloc_12288 12288 20 21 344064 485 0
umem_alloc_16384 16384 1 1 20480 1 0
------------------------- ------ ------ ------ --------- --------- -----
Total [umem_internal] 3584000 16431 0
Total [umem_default] 4001792 2704455 0
------------------------- ------ ------ ------ --------- --------- -----
vmem memory memory memory alloc alloc
name in use total import succeed fail
------------------------- --------- ---------- --------- --------- -----
sbrk_top 25309184 25399296 0 3192 335
sbrk_heap 25309184 25309184 25309184 3192 0
vmem_internal 2965504 2965504 2965504 366 0
vmem_seg 2875392 2875392 2875392 351 0
vmem_hash 51200 53248 53248 7 0
vmem_vmem 46200 55344 36864 15 0
umem_internal 3788864 3792896 3792896 900 0
umem_cache 42968 57344 57344 41 0
umem_hash 142336 147456 147456 36 0
umem_log 131776 135168 135168 3 0
umem_firewall_va 0 0 0 0 0
umem_firewall 0 0 0 0 0
umem_oversize 14130869 14413824 14413824 1286 0
umem_memalign 0 0 0 0 0
umem_default 4001792 4001792 4001792 638 0
------------------------- --------- ---------- --------- --------- -----
>
-----Original Message-----
From: dtrace-discuss-boun...@opensolaris.org
[mailto:dtrace-discuss-boun...@opensolaris.org] On Behalf Of ext David
Lutz
Sent: Friday, January 16, 2009 6:07 PM
To: venkat
Cc: dtrace-discuss@opensolaris.org
Subject: Re: [dtrace-discuss] C++ Applications with Dtrace
Hi Venkat,
I believe "alloc succeed" is a count of memory requests that
were successful. That memory may have been freed later,
so it doesn't necessarily point to the reason for a growing
memory foot print. The column to be concerned with is
"memory in use".
David
----- Original Message -----
From: venkat <venki.dammalap...@gmail.com>
Date: Friday, January 16, 2009 2:44 pm
> Hi david,
>
>
> What is allocated succeed block from umastat dcmd . that value is
> keep on increasing . Is that memory occupieng by process?
> like that way my process memory usage also keep on increasing ?
>
> can u clarify plz ?
>
>
> Thanks,
> Venkat
> --
> This message posted from opensolaris.org
> _______________________________________________
> dtrace-discuss mailing list
> dtrace-discuss@opensolaris.org
_______________________________________________
dtrace-discuss mailing list
dtrace-discuss@opensolaris.org
_______________________________________________
dtrace-discuss mailing list
dtrace-discuss@opensolaris.org
