[Rustam Kovhaev <rkovhaev@xxxxxxxxx>]

Hi, Gilbert, David,
I'll send a patch/merge request in gitlab.
Thank you!

On Mon, Jun 30, 2025 at 05:32:09AM -0400, David Perry wrote:
> There are open issues for this already... sort of. #20431 reports that
> tshark will linearly but unboundedly consume memory when run with the -M
> option. #20432 is about CLI taps (not) freeing their memory properly, and
> wondering what the best approach is to remedy it.
> 
> 20432 asks a larger design question about whether tshark should draw tap
> output and/or reset tap state when the session is reset. But since that
> question is academic while our CLI taps don't manage their memory, I've been
> working at adding/fixing reset and finish routines to most of our CLI taps,
> and pinging #20432 in each such MR.
> 
> I haven't done anything with the more complicated ones, such as
> tap-iousers.c that you named. Hopefully the work on the simpler taps will be
> useful for someone with a better understanding of the remainder.
> 
> Links:
> <https://gitlab.com/wireshark/wireshark/-/issues/20431>
> <https://gitlab.com/wireshark/wireshark/-/work_items/20432>
> 
> David
> 
> On 2025-06-28 21:31, Gilbert Ramirez wrote:
> > Correct, we don't want to free the allocation directly in the init
> > function. Look at epan/tap.h for the documentation on
> > register_tap_listener. The 2nd argument is "tapdata", or, the instance
> > of the tap and all its state.
> > 
> > If you look at tap-rpcprogs.c, in rpcprogs_init(), you'll see a much
> > clearer example.
> > The reason tap-iousers.c looks strange is that "&iu->hash" is passed as
> > "tapdata".
> > 
> > *However*, the last argument to register_tap_listener() should be a
> > "tap_finish" function which would free the memory, and that is missing!
> > I see some other taps in ui/cli that also forget to add a tap_finish
> > callback. For example, tap-smbsids.c is also missing a tap_finish
> > callback.
> > 
> > I guess no one noticed because these taps are instantiated a handful of
> > times, at the most, during the running of tshark. So, it's a very minor
> > oversight.
> > 
> > Would you like to open an issue at
> > https://gitlab.com/wireshark/wireshark/-/issues/ to track this?
> > 
> > Gilbert
> > 
> > On Sat, Jun 14, 2025 at 11:52 AM Rustam Kovhaev via Wireshark-dev
> > <wireshark-dev@xxxxxxxxxxxxx> wrote:
> > 
> >     Hi,
> >     First of all, thank you for Wireshark! I am using it a lot, and I mean
> >     it, and I love it.
> >     Quick sanity check, we don't free g_new0() allocation in
> >     init_iousers(),
> >     do we?
> >     This is harmless, just something I noticed while reading the code.
> >     Thank you very much!