ronnie sahlberg wrote: > 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.
se_ allocations are per capture file, right? So wouldn't Wireshark also have to stop dissecting further packets? And what would the limit be? Sure I've only got 512 Mb RAM in my laptop but I've got a server down the hall with 16 Gb RAM. Have a preference? Have a bunch of #ifdef's for each platform to find the [total or currently available] RAM? > On 8/25/06, *Jeff Morriss* <[EMAIL PROTECTED] > <mailto:[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. > > -J > > > On 8/22/06, *Jeff Morriss* <[EMAIL PROTECTED] > <mailto:[EMAIL PROTECTED]> > > <mailto: [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]> > <mailto:[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] <mailto:[email protected]> > > http://www.wireshark.org/mailman/listinfo/wireshark-dev > _______________________________________________ > Wireshark-dev mailing list > [email protected] <mailto:[email protected]> > 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] http://www.wireshark.org/mailman/listinfo/wireshark-dev
