[bugzilla-daemon@xxxxxxxxxxxxx]

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.