Hi John, The earlier shared c file was not fully correct so it's updated and the attached file was accepted by Coverity.
I managed to compile and upload a build to Coverity with this model file but I do not see any improvements yet. So it seems it's more complicated .... Regards, Tamas On Sun, 1 Mar 2026 at 21:31, Tamás Regős <[email protected]> wrote: > Hi John, > > I do not know how I can test this fully with certainty (yes, I can set up > a project for myself in Coverity in general) so I share it here too. I hope > it helps. > > > *Goal* > Create a Coverity model that distinguishes between manual management (when > allocator == NULL) and scoped management (when allocator is a valid > pointer). > > - When the allocator is NULL, treat the function like a standard > malloc. > - When there is a scope, "sink" the pointer into that scope so > Coverity understands the allocator will handle the cleanup. > > > > *Expected Results* > > Scenario: Manual > Allocator Passed: NULL > Coverity Behavior: Calls __coverity_alloc__. If no wmem_free(NULL, ptr) is > found, a RESOURCE_LEAK is raised. > > Scenario: Modern > Allocator Passed: Dissector > Coverity Behavior: pinfo->pool Calls wmem_alloc. Pointer is assigned to > pool->storage_sink. No RESOURCE_LEAK raised. > > Scenario: Epan Scope > Allocator Passed: wmem_epan_scope() > Coverity Behavior: Returns the singleton. Pointer is assigned to sink. No > RESOURCE_LEAK raised. > > Scenario: File Scope > Allocator Passed: wmem_file_scope() > Coverity Behavior: Returns the singleton. Pointer is assigned to sink. No > RESOURCE_LEAK raised. > > > *Examples* > > Scenario: Manual > Code Example: ptr = wmem_strdup(NULL, "test"); > Coverity Result: RESOURCE_LEAK raised > > Scenario: Manual > Code Example: ptr = wmem_strdup(NULL, "test"); > Coverity Result: No issue > > Scenario: Dissector Scope > Code Example: wmem_alloc(pinfo->pool, 10); > Coverity Result: No leak (escapes to pinfo->pool) > > Scenario: EPAN/File Scope > Code Example: wmem_strdup(wmem_file_scope(), "data"); > Coverity Result: No leak (escapes to singleton sink) > > > Regards, > Tamas > > On Sun, 1 Mar 2026 at 20:55, Tamás Regős <[email protected]> wrote: > >> 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] >>> >>
wmem_models.c
Description: Binary data
_______________________________________________ Wireshark-dev mailing list -- [email protected] To unsubscribe send an email to [email protected]
