Comment # 2
on bug 11002
from Anders Broman
(In reply to sworddragon2 from comment #0)
> Build Information:
> wireshark 1.12.1 (Git Rev Unknown from unknown)
>
> Copyright 1998-2014 Gerald Combs <[email protected]> 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 (64-bit) with GTK+ 3.14.7, with Cairo 1.14.0, with Pango 1.36.8,
> with
> GLib 2.43.3, with libpcap, with libz 1.2.8, with POSIX capabilities (Linux),
> with libnl 3, with SMI 0.4.8, with c-ares 1.10.0, with Lua 5.2, without
> Python,
> with GnuTLS 3.3.8, with Gcrypt 1.6.2, with MIT Kerberos, with GeoIP, with
> PortAudio V19-devel (built Feb 25 2014 21:09:53), without AirPcap.
>
> Running on Linux 3.18.0-14-generic, with locale C, with libpcap version
> 1.6.2,
> with libz 1.2.8, GnuTLS 3.3.8, Gcrypt 1.6.2.
> AMD Phenom(tm) II X6 1045T Processor
>
> Built using gcc 4.9.2.
> --
> I'm noticing that the memory usage does increase fast if many packets are
> captured (on my test I'm currently over 1 GiB of memory usage) but if I'm
> restarting a live capture the memory of the old capture will not be freed.
Wireshark has it's own memory managing scheme to increase speed (emem -> wmem)
the "real" memory allocated by emem/wmem will not be returned to the OS when a
capture file is closed so Wireshark does not need to allocate the memorry again
for emem/wmem use. The memory is "free" for Wireshark (re)use.
But there is also (g)malloced memory used, so it's possible that there is a bug
where memory isn't released. But it might be hard to diagnose. How many packets
are in your traces? Michal Labedzkis questions are relevant too.
You are receiving this mail because:
- You are watching all bug changes.
