Re: Memory consumption in tshark

[Evan Huus <eapache () gmail com>]

On Tue, Aug 27, 2013 at 5:01 PM, Joerg Mayer <jmayer () loplof de> wrote:

> On Tue, Aug 27, 2013 at 04:38:08PM -0400, Evan Huus wrote:
> > We already discard a great deal of state in (single-pass) tshark that we
> > keep around in Wireshark (or two-pass tshark). We do need to keep some,
> > though. It's only a bug if we're keeping more than we actually need, and
> > that's not determinable from the information we have here. Dario, if you
> > could get us a memory profile of tshark in this situation (through
> > valgrind's massif tool, for example) that would help us debug further.
> >
> > I dislike the idea of two-pass by default for exactly this reason: people
> > expect tshark to be relatively state-less. This is already not the case,
> > but it's a lot worse in two-pass mode. It might even make sense to add a
> > --state-less flag to tshark that disables all options which require
> state.
> > I don't know how feasible that would be however.
>
> IIRC, two-pass allows for most/all of the reassembly/request-response
> stuff,
> which we want to do sometimes. Any ideas why we have to keep some
> information
> indefinitely?

Two-pass requires us to keep *all* the state around through the first pass
so that it is available during the second pass (at which point it can be
discarded).  Even in single-pass mode, there is some state that we can't
always immediately discard. If I see a fragment of a TCP message then it
doesn't make sense to discard that until the other fragments have arrived
and been reassembled. If I see a request, I probably need to keep state
from that request until the response (which may never show up).

We already do reassembly and a lot of other stateful work in single-pass
mode. The only thing two-pass mode provides is the ability to "see the
future" (for example, saying: this request has a response 5 packets later).


> ciao
>       jörg
>
>
> --
> Joerg Mayer                                           <jmayer () loplof de>
> We are stuck with technology when what we really want is just stuff that
> works. Some say that should read Microsoft instead of technology.
> ___________________________________________________________________________
> 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-request () wireshark org
> ?subject=unsubscribe
___________________________________________________________________________
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-request () wireshark org?subject=unsubscribe