On 10/07/13 12:29, Javi Gallart wrote:
Hello
I am using a Lua script the extracts and writes to disk files from a
packet. When running in "realtime" everything goes smoothly but the
memory usage keeps growing until we have to restart everithing. So all
points to a memerory leak somehwere. We are tapping sigtran traffic.
Have you read this article? Chances are you're not looking at a leak at
all:
http://wiki.wireshark.org/KnownBugs/OutOfMemory
Runnning with Valgring as recommended here
(http://wiki.wireshark.org/Development/Tips) I obtained this:
Invalid read of size 4
at 0x65E1D18: mtp3_addr_to_str_buf (in
/usr/lib64/libwireshark.so.3.1.1)
by 0x619F303: address_to_str_buf (in /usr/lib64/libwireshark.so.3.1.1)
by 0x619F6A5: ??? (in /usr/lib64/libwireshark.so.3.1.1)
by 0x619DC64: ??? (in /usr/lib64/libwireshark.so.3.1.1)
by 0x61A3884: ??? (in /usr/lib64/libwireshark.so.3.1.1)
by 0x61A5C51: col_fill_in (in /usr/lib64/libwireshark.so.3.1.1)
by 0x1211F5: ??? (in /usr/sbin/tshark)
by 0x122A11: ??? (in /usr/sbin/tshark)
by 0x114CC4: ??? (in /usr/sbin/tshark)
by 0x9DA9B74: (below main) (in /usr/lib64/libc-2.17.so)
Address 0x13886f54 is 4 bytes inside a block of size 28 free'd
[...]
LEAK SUMMARY:
definitely lost: 2,586,839 bytes in 151,327 blocks
[...]
Should I assume that there is a leak in mtp3_addr_to_str_buf function?
No, that's a memory use after the memory in question was freed (very
different from a leak). That was fixed via
https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=8247; that fix is in
the 1.10.x stable versions but not earlier versions.
That Valgrind does show ~2 Mb of leaked memory though I think that's
pretty usual in the current stable branch--a lot of shutdown-related
memory leaks have been fixed in the current development version.
