Bug 452401

Summary: Intentional leaks are getting identified as memleaks, is there any way to avoid/disable that?
Product: [Developer tools] valgrind Reporter: sanjay.ku
Component: memcheckAssignee: Julian Seward <jseward>
Status: RESOLVED NOT A BUG    
Severity: major CC: pjfloyd
Priority: NOR    
Version First Reported In: 3.18.0   
Target Milestone: ---   
Platform: RedHat Enterprise Linux   
OS: Linux   
Latest Commit: Version Fixed/Implemented In:
Sentry Crash Report:

Description sanjay.ku 2022-04-08 13:02:34 UTC
SUMMARY
***
These are the memory allocations made for mgr to function properly and for specific purpose like handling of messages(ex applying config,handle respective messages) from other process. Also these were created during the instance creation and need to be hold till the lifetime of the instance. Hence this should not be treated as Memory leaks.

Is there any way to disable such leaks in valgrind which are intentional and hold the validity as lifetime?
Or is there any way to bypass these leaks while making valgrind image to avoid intentional leaks? 
***

Logs:
=========================
2022-Mar-09+15:37:15.213 card 1-cpu0: ==8736== 5,760 bytes in 1 blocks are definitely lost in loss record 1,917 of 2,171
 2022-Mar-09+15:37:15.213 card 1-cpu0: ==8736==    at 0x25C0bb87: calloc (in /usr/test/libexec/valgrind/vgpreload_memcheck-x86-linux.so)
2022-Mar-09+15:37:15.213 card 1-cpu0: ==8736==    by 0x8D78EC4: mgr_regi_msg_hdlers (acmg.c:1092)
 2022-Mar-09+15:37:15.213 card 1-cpu0: ==8736==    by 0x922D888: mgr_create_new_insce (acmg.c:1684)
 2022-Mar-09+15:37:15.213 card 1-cpu0: ==8736==    by 0x3405EFC: mgr_proc_init_config.part.417 (sesmg_conf.c:659)
 2022-Mar-09+15:37:15.213 card 1-cpu0: ==8736==    by 0x34001D8: mgr_proc_init_config (sesmg.c:13087)
 2022-Mar-09+15:37:15.213 card 1-cpu0: ==8736==    by 0x34041D8: mgr_hdl_req_init_conf (sesmg.c:130901)
 2022-Mar-09+15:37:15.213 card 1-cpu0: ==8736==    by 0xBE99B5B: sn_msg_arriving_hdle (api_evt.c:10222)
 2022-Mar-09+15:37:15.213 card 1-cpu0: ==8736==    by 0xBE7004E: sn_loop_run (evt_loop.c:945)
 2022-Mar-09+15:37:15.213 card 1-cpu0: ==8736==    by 0xBB7CCA9: main (main.c:664)

Leak Sumarry:
============================
2022-Mar-09+15:37:17.340 card 1-cpu0: ==8736== LEAK SUMMARY:
 2022-Mar-09+15:37:17.340 card 1-cpu0: ==8736==    definitely lost: 6,608 bytes in 3 blocks
 2022-Mar-09+15:37:17.340 card 1-cpu0: ==8736==    indirectly lost: 44 bytes in 1 blocks
 2022-Mar-09+15:37:17.340 card 1-cpu0: ==8736==      possibly lost: 10,611,700 bytes in 8 blocks
 2022-Mar-09+15:37:17.340 card 1-cpu0: ==8736==    still reachable: 220,392,468 bytes in 3,378 blocks
 2022-Mar-09+15:37:17.340 card 1-cpu0: ==8736==                       of which reachable via heuristic:
 2022-Mar-09+15:37:17.340 card 1-cpu0: ==8736==                         newarray           : 38,404 bytes in 1 blocks
 2022-Mar-09+15:37:17.340 card 1-cpu0: ==8736==         suppressed: 0 bytes in 0 blocks

STEPS TO REPRODUCE
1. 
2. 
3. 

OBSERVED RESULT


EXPECTED RESULT


SOFTWARE/OS VERSIONS
Windows: 
macOS: 
Linux/KDE Plasma: 
(available in About System)
KDE Plasma Version: 
KDE Frameworks Version: 
Qt Version: 

ADDITIONAL INFORMATION
Comment 1 Paul Floyd 2022-04-11 07:28:04 UTC
The usual way to do this is via a suppression file.

Run Valgrind first with --gen-suppressions=all
Then copy and paste the generated suppression into a file, giving it some label

Then run Valgrind with --suppressions=your_new_suppressions_file