Huge thanks to our Platinum Members Endace and LiveAction,
and our Silver Member Veeam, for supporting the Wireshark Foundation and project.

Wireshark-dev: Re: [Wireshark-dev] composite tvbuffs

From: John Sullivan <jsethdev@xxxxxxxxxxxxxxxxxxxx>
Date: Tue, 12 Oct 2010 19:55:23 +0100
On Tuesday, October 12, 2010, 3:27:09 PM, Jeff Morriss wrote:
> I think composite tvbuffs probably do work, but their use is hindered by
> the fact that each tvb that you get (each time a frame is handed to your 
> dissector) is freed/reused after the packet is dissected.  That is, 
> Wireshark does _not_ keep the entire capture file in memory.  Because of 
> that, there's relatively little need/use for the composite functions and 
> it's why you need to allocate copies of whatever data you want to 
> reassemble.

This. I was digging into the RTMPT dissector again over the weekend,
hoping I could move from allocating memory for every reassembled pdu
to just creating composite tvbs overlaying the original packets. This
would have been a big win memory-wise, since the reassembled packets
have to live for the entire capture session (multiple non-contiguous
chunks based on multiple prior TCP segments), but turns out not to be
possible for the above reason.

So it looks like it's necessary to either tvb_memdup from the original
data, then add a tvb_new_real_data to a composite and use that, or
se_alloc the entire buffer up front, tvb_memcpy into it and use a
tvb_new_real_data from that which has a lower overhead in terms of
tvbuff structures.

(I have a concern that neither of those will free up the used memory.
tvb_memdup uses g_malloc and there is no notification of when this is
safe to free so AFAICS it is leaked. The se_alloced blocks will of
course be freed once the capture is closed, but what of the extra tvb
structures on top of them? I presume they are permanent rather than
seasonal so ought to be tvb_freed at some point, but again I can't see
any notification of when that should happen, so it doesn't.)

John
--