ANNOUNCEMENT: Live Wireshark University & Allegro Packets online APAC Wireshark Training Session
April 17th, 2024 | 14:30-16:00 SGT (UTC+8) | Online

Wireshark-users: [Wireshark-users] Possible memory leak using Lua script

From: Javi Gallart <jgallart@xxxxxxxxxxxxxxxx>
Date: Mon, 07 Oct 2013 18:29:58 +0200
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. 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
    at 0x4A074C4: free (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
    by 0x91349AE: g_free (in /usr/lib64/libglib-2.0.so.0.3600.3)
    by 0x61A7E44: ??? (in /usr/lib64/libwireshark.so.3.1.1)
    by 0x61AA3DA: epan_dissect_run_with_taps (in /usr/lib64/libwireshark.so.3.1.1)
    by 0x122938: ??? (in /usr/sbin/tshark)
    by 0x114CC4: ??? (in /usr/sbin/tshark)
    by 0x9DA9B74: (below main) (in /usr/lib64/libc-2.17.so)
HEAP SUMMARY:
     in use at exit: 22,711,899 bytes in 263,580 blocks
   total heap usage: 2,818,800 allocs, 2,555,220 frees, 279,098,967 bytes allocated
LEAK SUMMARY:
    definitely lost: 2,586,839 bytes in 151,327 blocks
    indirectly lost: 9,908 bytes in 311 blocks
      possibly lost: 15,749,998 bytes in 32,427 blocks
    still reachable: 4,365,154 bytes in 79,515 blocks
         suppressed: 0 bytes in 0 blocks
 Rerun with --leak-check=full to see details of leaked memory
For counts of detected and suppressed errors, rerun with: -v
 ERROR SUMMARY: 96950 errors from 1 contexts (suppressed: 2 from 2)

Should I assume that there is a leak in mtp3_addr_to_str_buf function?

Thanks

Javi