https://bugs.kde.org/show_bug.cgi?id=452401

            Bug ID: 452401
           Summary: Intentional leaks are getting identified as memleaks,
                    is there any way to avoid/disable that?
           Product: valgrind
           Version: 3.18.0
          Platform: RedHat RPMs
                OS: Linux
            Status: REPORTED
          Severity: major
          Priority: NOR
         Component: memcheck
          Assignee: jsew...@acm.org
          Reporter: sanjay...@hcl.com
  Target Milestone: ---

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

-- 
You are receiving this mail because:
You are watching all bug changes.

Reply via email to