Evan Huus
changed
bug 8093
| What |
Removed |
Added |
| Status |
INCOMPLETE
|
RESOLVED
|
| Resolution |
---
|
NOTABUG
|
Comment # 5
on bug 8093
from Evan Huus
(In reply to comment #4)
> (In reply to comment #3)
> > I believe Guy is correct.
> >
> > What do you mean that frame_data_cleanup does not free the memory? Which
> > memory is it not freeing?
>
> He's probably referring to the per-packet data attached to pfd in the
> frame_data structure.
Right. We're freeing the list itself, but it's up to the dissector to use the
appropriate scoped memory for what the list stores, so this is also acting as
designed.
> Dissectors are probably either using se_ allocated memory, so they get freed
> when the capture is closed (in the case of tshark, that would happen when it
> exits), or are keeping track of it themselves, and have an init routine
> registered that frees up any old data.
>
> Ideally, there should be another memory pool for per-packet data, which
> would be released after each packet in one-pass tshark and released after a
> file is closed in Wireshark and two-pass tshark, to reduce the ongoing
> memory consumption by one-pass tshark.
This is pretty trivial to do with wmem, but obviously very low priority. I'm
also not sure how many instances of this kind of memory there would be - it
would be memory that isn't needed for subsequent packets, but might be needed
if we see the same packet again, in which case can't we just rederive the
needed information? It certainly wouldn't apply to conversations or reassembly,
which are the two biggest file-scope memory users right now.
Or am I misunderstanding?
You are receiving this mail because:
- You are watching all bug changes.