Wireshark-bugs: [Wireshark-bugs] [Bug 2375] Wireshark memory leak with each file open and/or dis
https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=2375
--- Comment #3 from Jim Young <jyoung@xxxxxxx> 2009-10-10 20:40:58 PDT ---
Hello Bill,
Great detective work!
Hopefully my answers to your questions will help.
Answer to question #1...
I believe the version of Wireshark used on the Linux system I tested with would
have reported:
> Compiled with GTK+ 2.8.3, with GLib 2.8.1, with libpcap 0.9.2, with libz 1.2.3,
> with POSIX capabilities (Linux), without libpcre, without SMI, without ADNS,
> without Lua, with GnuTLS 1.2.5, with Gcrypt 1.2.1, without Kerberos, with
> PortAudio V19-devel, without AirPcap.
> NOTE: this build doesn't support the "matches" operator for Wireshark filter
> syntax.
>
> Running on Linux 2.6.13-15.18-default, with libpcap version 0.9.2.
>
> Built using gcc 4.0.2 20050901 (prerelease) (SUSE Linux).
Answer to question #2...
I am 99.9% certain that the traces I was using when I reported this problems
would have included ncp.
I generally don't use drag-n-drop to open trace files unless I have a lot of
trace files in one folder.
I recall running a multi-day trace of traffic to one specific user's Netware
workstation to try to get to the bottom of a very intermittant and illusive
work-station "stall" problem. I had dozens and dozens of traces files for this
problem. So I would have used drag-n-drop to quickly move between trace files.
This was your classic case of looking for a needle in a haystack. I recall
making lots of display filter changes as well.
FWIW: The user's issue was that her computer would at randomly become
non-responsive for some short amount of time (I think 15 to 30 seconds but
perhaps a little longer). She would go several days without seeing the problem
and then maybe have it occur several times within an hour or two. She
attributed the problem to the network because if she unplugged her ethernet
cable the problem would go away. So I captured her workstation traffic for
perhaps two or three days. Those tracefiles definitly included ncp packets
because it was the apperance of one specific type of ncp packet sent by her
workstation to an unused local IP address that led me to find a problem with
the gateway addresses that where published by our dhcp server to dhcp clients
on this specific subnet. The workstation stall looked to occur whenever her
workstation tried to send one type of ncp packet to a non-existant gateway
address. We corrected the dhcp profile to only publish the one and only true
gateway address for this segment. The dhcp profile fix made her stall problem
go away.
--
Configure bugmail: https://bugs.wireshark.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
