Wireshark-bugs: [Wireshark-bugs] [Bug 11944] libwireshark too big
Date Index · Thread Index · Other Months · All Mailing Lists
Date Prev · Date Next · Thread Prev · Thread Next
From: bugzilla-daemon@xxxxxxxxxxxxx
Date: Sat, 18 Jun 2016 17:37:41 +0000

Comment # 11 on bug 11944 from 
I suggest measuring before cutting. Tshark from latest master consumes up to
~33 MB heap on my system which is not much at all and most of them coming from
reserving initial blocks for wmem:

$ WIRESHARK_RUN_FROM_BUILD_DIRECTORY=1 valgrind --tool=massif
--alloc-fn=wmem_alloc -- run/tshark -r
~/projects/wireshark.git/test/captures/dhcp.pcapng
$ms_print
--------------------------------------------------------------------------------
Command:            run/tshark -r
/home/rbalint/projects/wireshark.git/test/captures/dhcp.pcapng
Massif arguments:   --alloc-fn=wmem_alloc
ms_print arguments: massif.out.24247
--------------------------------------------------------------------------------


    MB
33.27^                                                                       #
     |                                                                       #
     |                                                                       #
     |                                                                       #
     |                                                                       #
     |                                                                       #
     |                                                                       #
     |                                                                       #
     |                            @               :::::::@::::@:::::@::::::::#
     |                            @:::::::::::::@::::::::@::::@:::::@::     :#
     |                            @::::::::: :::@::::::::@::::@:::::@::     :#
     |                       ::::@@::::::::: :::@::::::::@::::@:::::@::     :#
     |                     ::::: @@::::::::: :::@::::::::@::::@:::::@::     :#
     |                 ::::::::: @@::::::::: :::@::::::::@::::@:::::@::     :#
     |                :::::::::: @@::::::::: :::@::::::::@::::@:::::@::     :#
     |         :@::@@::::::::::: @@::::::::: :::@::::::::@::::@:::::@::     :#
     |   ::@:@::@::@@::::::::::: @@::::::::: :::@::::::::@::::@:::::@::     :#
     |   ::@:@::@::@@::::::::::: @@::::::::: :::@::::::::@::::@:::::@::     :#
     |   ::@:@::@::@@::::::::::: @@::::::::: :::@::::::::@::::@:::::@::     :#
     |   ::@:@::@::@@::::::::::: @@::::::::: :::@::::::::@::::@:::::@::     :#
   0
+----------------------------------------------------------------------->Mi
     0                                                                   626.6

Number of snapshots: 85
 Detailed snapshots: [5, 7, 10, 13, 14, 28, 29, 43, 55, 65, 75, 81, 82, 83
(peak)]
...
--------------------------------------------------------------------------------
  n        time(i)         total(B)   useful-heap(B) extra-heap(B)    stacks(B)
--------------------------------------------------------------------------------
 83    652,019,185       34,885,760       33,686,493     1,199,267            0
96.56% (33,686,493B) (heap allocation functions) malloc/new/new[], --alloc-fns,
etc.
->71.58% (24,972,498B) 0xAA1DA57: g_malloc (in
/lib/x86_64-linux-gnu/libglib-2.0.so.0.4800.0)
| ->48.09% (16,777,216B) 0x71F8D6B: wmem_block_alloc
(wmem_allocator_block.c:777)
| | ->48.09% (16,777,216B) 0x71FC10C: wmem_tree_new (wmem_tree.c:214)
| |   ->24.05% (8,388,608B) 0x664259F: guids_init (guid-utils.c:175)
| |   | ->24.05% (8,388,608B) 0x663CFA0: epan_init (epan.c:106)
| |   |   ->24.05% (8,388,608B) 0x115D61: main (tshark.c:1210)
| |   |     
| |   ->24.05% (8,388,608B) 0x6DD4316: tcp_init (packet-tcp.c:6093)
| |     ->24.05% (8,388,608B) 0xAA35AAB: g_slist_foreach (in
/lib/x86_64-linux-gnu/libglib-2.0.so.0.4800.0)
| |       ->24.05% (8,388,608B) 0x66473CB: init_dissection (packet.c:282)
| |         ->24.05% (8,388,608B) 0x663D201: epan_new (epan.c:193)
| |           ->24.05% (8,388,608B) 0x11D981: cf_open (tshark.c:2563)
| |             ->24.05% (8,388,608B) 0x117BC1: main (tshark.c:2256)
| |               
| ->12.02% (4,194,304B) 0x71F968C: wmem_block_fast_alloc
(wmem_allocator_block_fast.c:87)
| | ->06.01% (2,097,152B) 0x71FA24C: wmem_list_new (wmem_list.c:177)
| | | ->06.01% (2,097,152B) 0x6648D84: dissect_record (packet.c:519)
| | |   ->06.01% (2,097,152B) 0x663D602: epan_dissect_run_with_taps
(epan.c:378)
| | |     ->06.01% (2,097,152B) 0x11D114: process_packet (tshark.c:3807)
| | |       ->06.01% (2,097,152B) 0x118051: main (tshark.c:3563)
| | |         

...

The following small change decreases it to ~25MB max.:

diff --git a/epan/wmem/wmem_allocator_block.c
b/epan/wmem/wmem_allocator_block.c
index c487db6..1eb853f 100644
--- a/epan/wmem/wmem_allocator_block.c
+++ b/epan/wmem/wmem_allocator_block.c
@@ -151,7 +151,7 @@
  * 8MB is a pretty arbitrary value - it's big enough that it should last a
while
  * and small enough that a mostly-unused one doesn't waste *too* much. It's
  * also a nice power of two, of course. */
-#define WMEM_BLOCK_SIZE (8 * 1024 * 1024)
+#define WMEM_BLOCK_SIZE (1 * 1024 * 1024)

 /* The header for an entire OS-level 'block' of memory */
 typedef struct _wmem_block_hdr_t {


There are other other interesting places the attached log points at, such as
the t125 dissector.

You are receiving this mail because:
  • You are watching all bug changes.