Wireshark · Wireshark-bugs: [Wireshark-bugs] [Bug 2375] New: Wireshark memory leak with each file open and/ or display filter ch

[bugzilla-daemon@xxxxxxxxxxxxx]

http://bugs.wireshark.org/bugzilla/show_bug.cgi?id=2375

           Summary: Wireshark memory leak with each file open and/or display
                    filter change
           Product: Wireshark
           Version: 1.0.0
          Platform: PC
        OS/Version: Windows XP
            Status: NEW
          Severity: Normal
          Priority: Low
         Component: Wireshark
        AssignedTo: wireshark-bugs@xxxxxxxxxxxxx
        ReportedBy: jyoung@xxxxxxx


Build Information:
Version 1.0.0pre1 (SVN Rev unknown)

Copyright 1998-2008 Gerald Combs <gerald@xxxxxxxxxxxxx> and contributors.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

Compiled with GTK+ 2.12.8, with GLib 2.14.6, with WinPcap (version unknown),
with libz 1.2.3, without POSIX capabilities, with libpcre 7.0, with SMI 0.4.5,
with ADNS, with Lua 5.1, with GnuTLS 1.6.1, with Gcrypt 1.2.3, with MIT
Kerberos, with PortAudio V19-devel, with AirPcap.

Running on Windows XP Service Pack 1, build 2600, with WinPcap version 4.0.2
(packet.dll version 4.0.0.1040), based on libpcap version 0.9.5, without
AirPcap.

Built using Microsoft Visual C++ 6.0 build 8804

Wireshark is Open Source Software released under the GNU General Public
License.

Check the man page and http://www.wireshark.org for more information.
--
Hello,

Several common usage scenarios can result in Wireshark's runtime memory
footprint to grow to a point where Wireshark and/or Windows will pop up a
message dialog to report that it has run out of memory.  

These usage scenarios include:

   Opening many different trace files (or reopening the same trace file) within
the same instance of Wireshark

   Applying many different display filters to an open trace file

Wireshark's runtime dynamic memory requirements appears to grow with each new
trace file opened and/or with the application and then clearing of display
filters.

Please note that this is NOT a new behavior.  Older release versions of
Wireshark exhibit this same behavior.  But certain features (specifically the
use of the new "custom columns" feature) appear to exaggerate this memory
growth effect.

With smaller trace files this long term memory growth is often NOT a real
problem.  But if you have a sufficiently large enough trace file (for example
30MB) and a relatively memory constrained system (for example 512MB) then it is
relatively easy to experience the effects of the Wireshark memory leak.

On a MS Windows system a rough estimate of the runtime Memory usage of
Wireshark can most easily be seen by watching the "PF Usage" and "Page File
Usage History" on the "Performance" tab of the "Windows Task Manager"
application.  The maximum "PF Usage" (page-file) value is generally twice the
value of the Physical Memory of the system.  If one has a 512Mb system then the
PF Usage can grow to maximum of about 1GB.  If one has a 1GB of memory, then
the page file can grow to 2GB.  

This problem can be most easily seen by first starting the Windows Task
Manager, then starting Wireshark, and then using drag-and-drop (DND) drag a
relatively large (but not too large) trace file (perhaps 30MB) onto the running
Wireshark application.  With the first opening of the trace file, Wireshark's
runtime footprint will grow by some amount (I estimate this initial memory
growth to be 4 to 8 times the time of trace file, with my 30MB trace file, the
initial PF Usage grew by about 120MB).  Then using the dnd method drop the same
file onto the open Wireshark application.  This will cause the trace file to be
reloaded.  Repeat the dnd method for as many times as you wish.  The memory
growth trend can be seen in both absolute terms via "PF Usage" metric, and its
trend visually via the "Page File Usage History" graph.  In my case the "PF
Usage" would grow by about 12MB with each DND operation.

If you are watching the "PF Usage" metric, you may notice an initial drop in
the reported value when the trace file is re-released onto the running
Wireshark application, but as the trace file is re-loaded the "PF Usage" value
will increase and then stabilize to a point higher than where it started.    

A similar memory growing effect can be seen (but not quite so dramatically) by
simply applying, changing and/or clearing of display filters.  In our specific
usage case, we were trying to debug some enterprise DHCP issues.  We have a
series of 30MB trace files each containing perhaps 150000 to 200000 frames
(captured using tshark (actually tetheral) on another system with the capture
filter of "-f 'port 67 or port 68 or icmp'").  

Within each of our trace files about half of the frames match the display
filter "icmp"; the other half match the filter of "!icmp".   Most of the frames
match the filter "bootp".  We often applied and cleared display filters such as
"bootp.hw.mac_addr==11:bb:cc:dd:ee:ff".  With the various display filters
applied the "PF Usage" will generally seen to be lower then before the
application of any display filters.  But when the display filters are cleared
the "PF Usage" will tend to stabilize at higher value then where it started.

In my case I also had created a custom column of "bootp.hw.mac_addr".  As
expected Wireshark's memory growth when initially loading a trace file is
larger if a custom column is defined then if no custom column is defined.  But
removing the custom column did NOT stop the long term trend of continued memory
growth.

I've experienced what I believe are similar long term memory growth problems
while running Wireshark on my Linux machines.  My simple workaround is to split
the larger trace files into smaller pieces (by using editcap) and/or more
frequent closing and restarting of Wireshark itself (to avoid it from running
the system our of memory).

I made an initial stab at using valgrind's memcheck on a Linux machine to see
if I could identify any obvious memory leak.  Unfortunately without adding any
of valgrind's instrumentation features into Wireshark's source code I didn't
spot any obvious sources of the bigger memory leak I was expecting.


-- 
Configure bugmail: http://bugs.wireshark.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.