Wireshark-bugs: [Wireshark-bugs] [Bug 2375] Wireshark memory leak with each file open and/ or di
http://bugs.wireshark.org/bugzilla/show_bug.cgi?id=2375
--- Comment #1 from Jim Young <jyoung@xxxxxxx> 2008-03-20 04:12:09 GMT ---
I believe the memory growth problem I reported may be limited to the win32
platform.
After repeated testing on a freshly booted Linux system I was unable to confirm
any chronic large Wireshark memory leak with many drag-and-drops of the same
30MB trace file onto the a single running Wireshark instance.
FWIW:
I did both my initial and later Linux memory leak tests on a system with only
256MB of memory. On this system I used the "KDE System Guard" applet
(KSysGuard) to visually track "Physical Memory" and "Swap Memory" trends in a
manner similar to what I had done with the MS Task Manager on Windows.
Note: KSysGuard's Memory and Swap "used" and "free" values are virtually
identical to the memory values reported by the "top" utility.
Interestingly when this Linux system didn't need to use "Swap Memory" then
Wireshark's memory footprint remained effectively unchanged with 20
drag-and-drop operations of the 30MB trace file. But when this system needed
to use the swap file, then KSysGuard indicated that the Swap "used" value
increased from 3536KB to 15544KB with 15 drag-and-drop operations of the 30MB
trace file onto the running Wireshark instance. This works out to an average
increase in swap memory usage of approximately 800KB. But the increase was not
linear; there was a 4MB increase in swap between the second and third file
open, and a 2MB increase between the third and forth. There was several
successive drag-and-drop operations that resulted in virtually no change in
reported swap memory usage.
So at this point I can not reproduce the same relatively large memory growth
pattern on a Linux system that I can easily reproduce on a Windows system. I
This is probably why I had no luck using valgrind to expose the source of this
leak.
--
Configure bugmail: http://bugs.wireshark.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
