Wireshark-dev: Re: [Wireshark-dev] memory allocation assertion failure reading 219MB file with
From: Jeff Morriss <[email protected]>
Date: Thu, 24 Aug 2006 11:01:04 -0400

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
     > 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:


    Wireshark-dev mailing list
    [email protected] <mailto:[email protected]>


Wireshark-dev mailing list
[email protected]