Wireshark-dev: Re: [Wireshark-dev] memory allocation assertion failure reading 219MB file with
From: "ronnie sahlberg" <[email protected]>
Date: Fri, 25 Aug 2006 09:15:28 +1000
i think significant parts of the utilized memory is memory allocated by wireshark itself for things like reassembly  and state management of protocols.

since most se allocation is done from within a dissector
once more/most of this is converted to use emem allocators  we could maybe do something like :

1, set an upper limit on how much memory we allow to be allocated by the se allocator
2, when se_alloc is called and we have reached this limit,   just cause a new exception MemError
to cause dissection of the packet to be aborted but allow wireshark to continue.

this might actually work

On 8/25/06, Jeff Morriss <[email protected]> wrote:

Ravi Kondamuru wrote:
> Thanks for the wiki link.
> In the workarounds highlighed, I feel that point 3 (Split the capture
> file into several smaller ones) can be made more appealing by
> programatically limiting the amount of data (packets/ memory consumed/
> load time) wireshark already read/ used.
> Wireshark does something similar when a large file is selected in the
> "Select a capture file" dialog box when opening a file. After 3 secs
> (prefs: file_open_preview_timeout) of reading a file, it stops reading
> further and displays "more than xyz packets (preview timeout)".
> My point being, can the same approach be taken with large files during
> the actual display?
> An option will let the user make wireshark parse the subsequent or
> previous packets till a timeout happens again. An option will let users
> to make wireshark read the complete file before display. How much to
> read at a time can be determined as mentioned earlier on one of 1)
> number of packets read, 2) memory consumed so far or 3) amount of time
> spent reading.
> Please mail, if you guys think of any issues that might make this
> approach not worth pursuing.

I think the problem with this approach is that it's difficult to know
[at least in a cross-platform manner that works on all the platforms
Wireshark runs on] when you're going to run out of memory until you
actually have run out of memory (and malloc() fails).  As mentioned in
the Wiki, Wireshark and (more importantly as it's a bigger job to
change) some of the libraries Wireshark uses simply call abort() when
malloc() fails.


> On 8/22/06, *Jeff Morriss* <[email protected]
> <mailto: [email protected]>> wrote:
>     Guy Harris wrote:
>      > Ravi Kondamuru wrote:
>      >
>      >> My question:
>      >> Is there a known limit on the number of packets that wireshark
>     can deal
>      >> with in a single file?
>      >
>      > The number of packets that Wireshark (or, I suspect, any network
>      > analyzer) can deal with is limited; due to a number of factors,
>     the GUI
>      > widget used to implement the packet list display being one of
>     them (it
>      > allocates a string for the text value in every column, which eats
>     a lot
>      > of memory), Wireshark's limit might be lower than some other
>     analyzers.
>      >
>      > This is not a limit saying something such as "Wireshark can't
>     read more
>      > than 1,227,399 packets"; the point at which it'd run out of memory
>      > depends on the contents of the packets.
>     See this page for more info:
>     http://wiki.wireshark.org/KnownBugs/OutOfMemory
>     _______________________________________________
>     Wireshark-dev mailing list
>     [email protected] <mailto:[email protected]>
>     http://www.wireshark.org/mailman/listinfo/wireshark-dev
>     <http://www.wireshark.org/mailman/listinfo/wireshark-dev>
> ------------------------------------------------------------------------
> _______________________________________________
> Wireshark-dev mailing list
> [email protected]
> http://www.wireshark.org/mailman/listinfo/wireshark-dev
Wireshark-dev mailing list
[email protected]