i am working on a project: capture and dissect the network packets using libwireshark when i execute my code with valgrind.. i found this report 7,024 bytes in 143 blocks are definitely lost in loss record 25 of 41 ==21679== at 0x4A05809: malloc (vg_replace_malloc.c:149) ==21679== by 0x32D2E33BFA: g_malloc (in /lib64/libglib-2.0.so.0.1200.3) ==21679== by 0x32D2E45A7E: g_strdup (in /lib64/libglib-2.0.so.0.1200.3) ==21679== by 0x5BD2A2E: add_oid (oids.c:145) ==21679== by 0x5BD2BAA: oid_add_from_string (oids.c:178) ==21679== by 0x62935D3: proto_reg_handoff_pkixqualified (packet-pkixqualified-dis-tab.c:7) ==21679== by 0x6339509: register_all_protocol_handoffs (register.c:1593) ==21679== by 0x5BEBFD1: proto_init (proto.c:416) ==21679== by 0x5BCC92F: epan_init (epan.c:104) ==21679== by 0x401FF9: init_libwireshark (trace.c:124) ==21679== by 0x402AAD: main (trace.c:518) is this the problem with libwireshark only ?? how to get rid of this problem. any help!? thanks! asked 25 Feb '12, 03:03  Sanny_D |
One Answer:
First: Please note that valgrind may become confused due to various memory optimizations used in libwireshark and Glib. To use valgrind with Glib based programs please see : (A Google search finds other discussions on this topic). Also: from the Wireshark sources: epan/emem.c Second: At least some of the cases are because Wireshark does certain memory allocations during initialization which are for the lifetime of the program and which are never freed. Fixing these hasn't been a priority although I believe there have been efforts from time to time. To get "clean" valgind output, the simplest solution may be to configure valgrind to ignore certain of these memory leaks. Third: Other cases may very well be memory leaks which are more "real": e.g., memory allocated during dissection of a frame which is not freed properly when the dissection is complete. We gladly accept patches to fix specific instances of memory leaks. :) :) answered 25 Feb '12, 06:17  Bill Meier ♦♦ edited 27 Feb '12, 06:21 showing 5 of 6 show 1 more comments |
And it's not clear it's worth fixing the cases where Wireshark does certain memory allocations during initialization which are for the lifetime of the program and which are never freed - it's faster to free that memory by simply terminating the process with exit() or a return from main() than to manually free it before exiting.
yes. but i want to run the application for a long time on server side, so freeing with exit() or return from main() wont serve the purpose.
is any other way to remove this unwanted leaks, like cleanup routines.
thanks!
There's no way to remove memory allocations that valgrind misidentifies as leaks; there might, as per the links Bill suggests, be ways to get valgrind to stop falsely claiming that they're leaks, so that it identifies only real leaks. From looking at add_oid(), what valgrind is reporting there is unlikely to be a leak unless add_oid() isn't properly updating the tree and therefore losing the stuff it allocates.
And, no, there's no way to remove allocations of stuff that's intended to be allocated during the entire Wireshark run.
this is the report after turning off the glib optimization.. now what could be wrong?
What's wrong is that
1) you have Diameter dictionaries
and
2) either turning off the glib optimization isn't sufficient to keep valgrind from being confused or somehow the array isn't getting freed (it's probably the build_dict.hf array if this is a recent version of Wireshark, and that array is freed - but its content isn't freed because it's been registered as a set of fields - so the answer is probably "turning off the glib optimization isn't sufficient to keep valgrind from being confused").
Note well: the code in various dissectors (in libwireshark) accumulates state (using memory) as frames are dissected.
So, expecting to "run the application for a long time on server side" without memory usage increasing (which seems the implication of your questions) is a non-starter.
Am I missing something (or incorrect about how you are using libwireshark ?)