memory leak

[randolphcyg]

I'm having a memory leak when modifying the real-time traffic that ushark uses to parse fetched from the network device:

1. First, modify the pcap_open_offline function in cap_example.c to pcap_open_live to listen for the traffic of a network device.
2. Then run the program, use the atop -m command to observe the change of the memory occupation of the program, and find that the memory occupation is increasing.
3. When I gave the memory leak analysis report with valgrind --tool=memcheck --leak-check=yes --show-reachable=yes --trace-children=yes --log-file=leak.txt -v ./test gave the memory leak analysis report and found that there was no definitely lost.
4. When I put memcpy(ws_buffer_start_ptr(buf), sk->dissect.pkt, len); changed to memcpy(ws_buffer_start_ptr(buf), "", len); When testing, the memory leak problem disappeared, so it can be judged that it is a problem with BUF. When I tried to add the processing logic for bufws_buffer_free(&buf); There is no improvement either.
5. I don't know if it has anything to do with libpcap library, I hope to get your help, thank you!

[emanuele-f]

Hello, this is something to investigate. For sure there is an invalid read reported by valgrind:

==24505== Invalid read of size 8
==24505==    at 0x23DB80E: ushark_destroy (ushark.c:507)
==24505==    by 0x23DAB7D: main (pcap_example.c:40)
==24505==  Address 0xc0015d0 is 160 bytes inside a block of size 2,456 free'd
==24505==    at 0x851326F: free (vg_replace_malloc.c:872)
==24505==    by 0x35FD59D: wtap_close (in /home/emanuele/src/ushark/libushark/pcap_example)
==24505==    by 0x23DB809: ushark_destroy (ushark.c:505)
==24505==    by 0x23DAB7D: main (pcap_example.c:40)
==24505==  Block was alloc'd at
==24505==    at 0x8515A73: calloc (vg_replace_malloc.c:1328)
==24505==    by 0x85A8631: g_malloc0 (gmem.c:163)
==24505==    by 0x23DB5CE: ushark_new (ushark.c:456)
==24505==    by 0x23DAB4E: main (pcap_example.c:37)

Running valgrind --leak-check=full --show-leak-kinds=all show some leaks, these could be the ones responsible for your issue.

[randolphcyg]

Thanks, I have referred to the logic of wireshark, tshark, and rawshark source code to implement different versions of offline and online packet capture parsing logic.
But I tested with valgrind and found that the report showed no leaks, in fact there would be leaks.
By adding a printf statement to the code, it is determined that it is most likely to have something to do with the buffer transport. But it will not be modified yet, I will continue to follow up, hope to solve it as soon as possible.

[emanuele-f]

Invalid read size fixed in cf3c876.
Regarding the possible leak, I've run the pcap_example through different PCAP samples and I always get the same report, with 278 still reachable:

==3210== LEAK SUMMARY:
==3210==    definitely lost: 0 bytes in 0 blocks
==3210==    indirectly lost: 0 bytes in 0 blocks
==3210==      possibly lost: 0 bytes in 0 blocks
==3210==    still reachable: 60,055 bytes in 278 blocks
==3210==         suppressed: 0 bytes in 0 blocks

Inspecting the leaks, they are related to some state that wireshark does not clean up (e.g. ws_init_version_info and reassembly_table_init). Since the leaked size is all the same regardless of the PCAP samples size, it seems like no leaks occur in the packet processing. Your memcpy change above does not explain or fix possible leaks (but please note that it introduces an OOB read).

Please post links to your custom code, trying to minimizing the changes w.r.t. this repo example so that I can try to reproduce this.