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. ___________________________________________________________________________ Sent via: Wireshark-dev mailing list <wireshark-dev@wireshark.org> Archives: http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
