Hi John, Your feedback is valuable and this case is complex indeed.
In case the allocator is clearly defined as NULL (and there are some cases such as tvb_memdup(NULL, ...) ) then we shall have wmem_free(NULL, ...) followed later. If wmem_free() is missing, that should be reported by Coverity as a resource leak and we shall not ignore it. I am not a Coverity expert but I will try to understand more if there is a way to improve this specific resource leak scenario when allocator is clearly not NULL. Thank you. Regards, Tamas On Sun, 1 Mar 2026 at 20:31, John Thacker <[email protected]> wrote: > On Sun, Mar 1, 2026 at 8:11 AM Tamás Regős <[email protected]> wrote: > >> Hi Pascal, >> >> Was there any consideration or discussion about a Coverity model file for >> these scenarios? >> >> Regards, >> Tamas >> > > Hi Tamas, > > If someone could do that, it would be welcome. > > Complicating the matter somewhat is that the various wmem_() functions > would leak memory if the wmem_allocator_t* passed in as the first argument > is NULL. (This allocates with g_malloc, etc.) In practice pinfo->pool is > never NULL (epan_dissect_init and epan_dissect_reset guarantee this), but > if you examine many of the Coverity defect reports they take a branch > assuming that the allocator is NULL. It might be necessary to do something > like replace pinfo->pool with a macro that expands to simply pinfo->pool > not on Coverity but to something that guarantees a non-NULL on Coverity, > although that might not be sufficient. > > Simply ignoring all the resource leaks would be a problem in the cases > where those functions are called with NULL. > > Cheers, > John > _______________________________________________ > Wireshark-dev mailing list -- [email protected] > To unsubscribe send an email to [email protected] >
_______________________________________________ Wireshark-dev mailing list -- [email protected] To unsubscribe send an email to [email protected]
