Scott Mueller wrote:
Hello Wireshark Dev List,
I’ve been working with my own dissector for some time now and have run
into a bit of a snag involving memory usage. I have messages that are
split up on a size boundary, so I allocate enough space for the overall
message (yes, I know this is a bit of a red flag) with se_alloc, and
then copy data from the tvb into this new buffer using tvb_memcpy. This
is great, because I then pass this into tvb_new_real_data and then
dissect those “large” tvbuffs.
Recently, I’ve been working with messages that exceed 3 megabytes or so.
In this case, se_alloc complains and throws an exception about
allocating more than 2.5 megabytes. I realized my mistake, and am now
searching for a way to have a “chunked” allocation. Searching through
the tvbuff.h header led me to the tvb_*composite* functions. Further
searches on those functions resulted in an uncertainty as to whether or
not these work. The tests in tvbtest.c which apparently exercise tvb
operations have references to the composite functions commented out, but
the packet-rtmpt.c dissector in the Wireshark development branch makes
use of these.
Packet-rtmpt.c creates a composite tvbuff, appends to it, and then calls
finalize. It then calls tvb_memdup and uses the allocated memory as
backing for another tvb (tvb_new_real_data again) , but doesn’t call
g_free to release the memory.
Am I missing something? What is the status of composite tvbuffs? If they
aren’t complete, what is needed to make this happen?
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.
