KnownBugs - OutOfMemory

Wireshark will terminate if it runs out of memory and there's currently no solution (but some workarounds) to this.

We know this is a serious problem, but we can't do a lot about it (at least with the manpower we have). We would have to use a different GUI/platform toolkit and throw away 2/3 of the current Wireshark GUI code to completely solve this 😦 . However, a lot can be done to improve this, although there's a lot of work involved.

Memory Usage

Wireshark uses memory to store packet meta data (e.g. conversation and fragmentation related data) and to display this info on the screen.

How much memory is actually used depends on:

In my experience (and with the capture files and Preference settings I'm usually working with), I need memory about ten times the actual capture file size. But again, this will largely depend on the things noted above.

The Performance page gives some hints how to reduce memory usage.

Why memory consumption is not a memory leak!

While dissecting packets, Wireshark needs a growing amount of memory for mainly two reasons:

Wireshark cannot throw away this information as it might be required later; Wireshark keeps this information in memory until the capture file is closed.

So the more packets you load, the more memory you will need.

Work Around(s)

If you encounter problems that Wireshark is running out of memory, you can do the following:

Other tools

If Wireshark is running out of memory, that probably means that you're letting it run for a very long time or you're analyzing very large capture files. You may find that another tool does what you want better than Wireshark. Use dumpcap for long term capturing, it's intended for this purpose, or see Tools for other tools which may be more suitable for the task.

Memory limitations on Microsoft Windows

The following is a summary of information from the MSDN: Large Memory Support and related pages.

Physical memory

Slightly simplified, the maximum physical memory windows supports:

Windows Version 32 bit 64 bit
XP Pro 4GB 128GB
Vista Business 4GB 128GB
Various Server Versions 4-128GB 4GB-1TB

Detailed information about the specific limits can be found at: Memory Limits for Windows Releases

More physical memory than the above limits will be ignored by windows.

Virtual memory

Wireshark can be compiled as either a 32- or 64-bit application on Windows. The maximum amount of virtual memory Wireshark uses depends on several things:

Traditionally, a single program on windows can use up to 2GB RAM (the rest is used for Windows internal purposes). Since Wireshark Git commit 9fb143d5 (first released in 0.99.5) Wireshark/Tshark is linked with the /LARGEADDRESSAWARE switch that enables usage of up to 3GB/4GB RAM as described above.

XXX - I couldn't find any information about the maximum total amount of virtual memory for ALL processes in a system.

Enable the /3GB switch

For various Windows Server versions, XP Pro and Vista, the usage of 3GB for a single process can be activated by a change in the boot.ini file:

Now you should be able to use up to 3GB virtual memory with Wireshark.

Details at: 4-Gigabyte RAM Tuning

Background on termination when out of memory

Memory allocation is done using glib's g_malloc()/g_free() implementation. Unlike the common malloc() function, g_malloc() will terminate the program if it's runnning out of memory.

Many of the GLib (and GTK+) facilities that Wireshark uses, such as GHashTables, use g_malloc() too. So even if Wireshark were to use a different memory allocator, that wouldn't help if it continued to use those facilities.

Some effort is currently done to eliminate the usage of g_malloc() from the dissector code. Removing this from the GTK+ code will be almost impossible. However, most of the major consumers of memory are not in the GUI, so if we eliminate the use of GLib facilities that use g_malloc() (and make sure that we check for memory allocator failures, or use a memory allocator that throws an exception on failure and catch the exception and clean up!), that'll probably help somewhat.

External links

Imported from on 2020-08-11 23:15:52 UTC