Wireshark-dev: Re: [Wireshark-dev] Filebacked-tvbuffs : GSoC'13
Date Index · Thread Index · Other Months · All Mailing Lists
Date Prev · Date Next · Thread Prev · Thread Next
From: Ambarisha B <b.ambarisha@xxxxxxxxx>
Date: Sat, 20 Apr 2013 02:31:52 +0530
Hi,

On Thu, Apr 18, 2013 at 11:31 PM, Ambarisha B <b.ambarisha@xxxxxxxxx> wrote:
 I'll also see if I can get a profile from massif as Evan suggested. 

I tried out massif on wireshark today. I just profiled on a web-browsing session capture file of 12Mb. I am not sure if that is too less to profile on.

Wireshark's memory usage was about 60mb. When browsing the packets, ~35% of the memory was g_malloc'ed. Infact, the reassembled data is also g_malloc'ed in fragment_add_work(). Looking more closely, about 20% of this(20% of total) is because of reassembly (g_malloc() from fragment_add_work()). Ofcourse, this is with such a small capture. On large captures, the percentage would probably shoot up.

I have attached the massif output and ms_print output (1mB I'm not sure if that's ok). Just search for "g_malloc " or dissect_tcp_payload in ms_print, to find the interesting part. Also some of the function names are missing. But the two above dissect_tcp_payload are definitely desegment_tcp() and fragment_add() (fragment_add_work() being static). But, do I need to compile wireshark with debug symbols or something to get them right?

Also, if we modify the reassembly code to take a tvbuff_filebacked and reassemble (not the data) in it, we'll have to modify all the dissectors accordingly, right? I guess that'll have to be done anyways if we introduce tvbuff_filebacked.


Cheers
Ambarish

Attachment: massif.out.3872
Description: Binary data

Attachment: ms_print.out
Description: Binary data