https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=6898
--- Comment #5 from Guy Harris <guy@xxxxxxxxxxxx> 2012-04-12 15:14:49 PDT ---
(In reply to comment #2)
> The problem is the RTMPT dissector is allocating more memory than the fuzz
> script thinks is reasonable.
...
> Not sure what to do about this. Maybe RTMPT needs to limit its *total* memory
> usage. Or a preference for that max packet size (with a low default)?
Now that we support fast random access to gzipped capture files, it might be
possible to, in the reassembly code:
keep, for each reassembled chunk, a data structure indicating which data in
which frames contributed to the reassembled chunk (if we don't already do so);
on the first pass through the packets, free up the reassembled chunk's data
once we're done with it;
on all subsequent passes, reconstruct the reassembled chunk by reading the
frames that contributed to it, and free *that* up once we're done with it;
which would reduce the memory consumption of both Wireshark *and* TShark when
dealing with captures with large amounts of reassembly.
--
Configure bugmail: https://bugs.wireshark.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching all bug changes.