Hi Thierry,
On 08/20/2010 12:39 PM, Thierry Emmanuel wrote:
Hello,
As I wrote in some of my mails, I work on a project which made me to use
the epan as a dissecting library, independently from the rest of the
wireshark source.
I have some troubles with memory handling. I have huge memory leaks when
I decode multicast streams (because there are lots of packets to dissect
of course :) ).
I've seen memory leaks after extended usage too.
http://wiki.wireshark.org/KnownBugs/OutOfMemory has some information on
this and the main takeaways seem to be that 1. high memory consumption
could be normal, and 2. there is no easy solution to the memory
utilization problem.
However, just decoding ICMP traffic (echo requests and replies) over and
over seems to "leak" memory in my tests. I've never troubleshot this,
though, so I don't know who's at fault and whether that is truly a
memory leak or just normal memory "consumption".
This kind of use isn't common, nor documented, so I must have made some
errors in my implementation or even in the structure of my wrappers.
By "this kind of use isn't common" do you mean calling
call_dissector_only() instead of using epan_dissect_run()?
I don't have experience calling call_dissector_only() so I won't be able
to help here; sorry.
By looking at the valgrind output you are right in that a lot of memory
seems to be "leaking", though.
Could you capture traffic and run it both through tshark and your
application to see if they both see the same memory consumption/leakage?
Cheers,
Eloy Paris.-
netexpect.org
So I have some questions to the wireshark gurus :
Do you see some reason, for example in my code, that could cause such
memory leaks ?
I have supposed that the whole memory used to build the proto_tree
wasn't free'd when I called proto_tree_free, do you free its content by
another way ?
Is there a way to force dissectors and the rest of Wireshark code to
release this memory ?
You’ll find my code and the last lines of the valgrind output joined to
my message.
Best regards
