https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=4051
Jeff Morriss <jeff.morriss.ws@xxxxxxxxx> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |jeff.morriss.ws@xxxxxxxxx
Summary|Memory leak in TCP |Memory leak in TCP
|dissector (OutOfMemoryError |dissector
|isn't being caught at the |
|top level) |
--- Comment #17 from Jeff Morriss <jeff.morriss.ws@xxxxxxxxx> 2012-01-30 07:32:09 PST ---
(In reply to comment #1)
> "Signal 6" is OutOfMemoryError, so TShark just ran out of memory. That's why
> it's hard to reproduce - you have to capture for long enough, or read a big
> enough capture file, so that you run out of memory, and the memory requirements
> aren't based on the size of the file, it's based on a number of things,
> including the amount of packet reassembly done.
>
> The problem is that we don't catch OutOfMemoryError at a sufficiently high
> level, and report "sorry, not enough memory" and clean up appropriately (where
> "appropriately" would be different in different cases, e.g. TShark should just
> stop capturing/reading, report "sorry, not enough memory", and quit, while
> Wireshark should close the file and free up everything it can, and then pop up
> a message box saying "sorry, not enough memory" (which it won't be able to do
> until there *is* enough memory).
This problem was fixed in r39798. Adjusting synopsis appropriately.
Other than that, do we have any known memory leaks described in this bug, or is
it meant to be a generic "memory usage is too high" or "memory usage grows too
quickly" bug? I bask because I don't think we particularly need such a bug as
*shark's memory usage is a KnownProblem.
--
Configure bugmail: https://bugs.wireshark.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
You are watching all bug changes.