memory leak about ushark HOT 3 OPEN

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.

from ushark.

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.

from ushark.

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.

from ushark.