https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=5821
Jakub Zawadzki <darkjames@xxxxxxxxxxxxxxxx> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |darkjames@xxxxxxxxxxxxxxxx
--- Comment #3 from Jakub Zawadzki <darkjames@xxxxxxxxxxxxxxxx> 2011-04-13 04:47:27 PDT ---
(In reply to comment #1)
> Does anyone know of a
> Linux-based tool that does something similar?)
Valgrind suite has got DHAT & massif
Sample output from DHAT:
==5209== -------------------- 1 of 100 --------------------
==5209== max-live: 2,120,688 in 14,727 blocks
==5209== tot-alloc: 2,120,688 in 14,727 blocks (avg size 144.00)
==5209== deaths: 14,727, at avg age 953,262,727
==5209== acc-ratios: 1.45 rd, 1.19 wr (3,082,963 b-read, 2,540,705 b-written)
==5209== at 0x4C2528E: malloc (in
/usr/lib64/valgrind/vgpreload_exp-dhat-amd64-linux.so)
==5209== by 0x9B551C2: g_malloc (in /usr/lib64/libglib-2.0.so.0.2400.2)
==5209== by 0x9B7307F: g_slice_alloc (in /usr/lib64/libglib-2.0.so.0.2400.2)
==5209== by 0x43D689: read_packet (file.c:1199)
==5209== by 0x43E09D: cf_read (file.c:633)
==5209== by 0x453DEA: main (main.c:2873)
It also can print which bytes are accessed (read/write)
For example for frame_data structure it prints:
==5209== Aggregated access counts by offset:
==5209==
==5209== [ 0] 44180 44180 44180 44180 44180 44180 44180 44180 29454 29454
29454 29454 29454 29454 29454 29454
==5209== [ 16] 15415 15415 15415 15415 15415 15415 15415 15415 133231 133231
133231 133231 44199 44199 44199 44199
==5209== [ 32] 44217 44217 44217 44217 29454 29454 29454 29454 14745 14745
14745 14745 14745 14745 14745 14745
==5209== [ 48] 0 0 44235 44235 214806 0 0 0 15476 15476 15476 15476 15476
15476 15476 15476
==5209== [ 64] 128089 128089 128089 128089 128089 128089 128089 128089 142816
142816 142816 142816 42382 42382 42382 42382
==5209== [ 80] 57914 57914 57914 57914 57914 57914 57914 57914 57659 57659
57659 57659 14744 14744 14744 14744
==5209== [ 96] 15001 15001 15001 15001 15001 15001 15001 15001 15001 15001
15001 15001 18 18 18 18
==5209== [ 112] 15001 15001 15001 15001 15001 15001 15001 15001 15001 15001
15001 15001 18 18 18 18
==5209== [ 128] 30780 30780 30780 30780 30780 30780 30780 30780 29624 29624
29624 29624 29624 29624 29624 29624
==5209==
Values with smaller acess count are interesting. 18's AFAIR are from nstime
aligment (12 bytes packed -> 16 bytes aligned. 4B * 4 nstime_t structures per
frame_data == 16 B wasted ;) ), 0's don't remember.
Btw. del_cap_ts is quite easy to calculate (frame->abs_ts -
frame->prev->abs_ts)
massif can print how much memory is allocated (in current sample) by each
procedure (and how much % of total memory allocation it is)
Sample output, begin of tree:
81.91% (29,036,380B) (heap allocation functions) malloc/new/new[], --alloc-fns,
etc.
->16.29% (5,773,824B) 0x43D688: read_packet (file.c:1199)
| ->16.29% (5,773,824B) 0x43E09C: cf_read (file.c:633)
| ->16.29% (5,773,824B) 0x453DE9: main (main.c:2873)
|
->07.31% (2,591,160B) 0x9B47B74: g_list_append (in
/usr/lib64/libglib-2.0.so.0.2400.2)
| ->07.11% (2,521,632B) 0x5FE1D7B: proto_register_field_array (proto.c:4597)
| | ->04.59% (1,626,168B) in 1030 places, all below massif's threshold (00.00%)
| | |
| | ->02.53% (895,464B) in 8+ places, all below ms_print's threshold (01.00%)
| |
| ->00.20% (69,528B) in 1+ places, all below ms_print's threshold (01.00%)
|
->06.15% (2,178,520B) 0x9B831B8: ??? (in /usr/lib64/libglib-2.0.so.0.2400.2)
| ->06.15% (2,178,440B) 0x5FE1D02: proto_register_field_init (proto.c:4869)
| | ->06.06% (2,149,040B) 0x5FE1D93: proto_register_field_array (proto.c:4600)
| | | ->04.07% (1,443,080B) in 1085 places, all below massif's threshold
(00.00%)
| | | |
| | | ->01.99% (705,960B) in 7+ places, all below ms_print's threshold (01.00%)
| | |
| | ->00.08% (29,400B) in 1+ places, all below ms_print's threshold (01.00%)
| |
| ->00.00% (80B) in 1+ places, all below ms_print's threshold (01.00%)
|
(...)
Luckily these tools don't require any change in wireshark
--
Configure bugmail: https://bugs.wireshark.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
