https://bugs.kde.org/show_bug.cgi?id=483372
--- Comment #2 from Darnethal0z <nsldvndvjdv154sf5v4...@proton.me> --- (In reply to Tom Hughes from comment #1) > It has been detected - that's what the leak report is. > > The call to another_function changed the value of var_one causing the > original value to be leaked, and that leak was correctly reported by > valgrind. > > The free call then frees the block which var_one now points to, which is the > second allocated done by another_function, so there is no problem to report > with that block. Thank you for your quick answer. Indeed, i tried with another call to another_function with a different value, and i can see now the 2 previous allocations stacking up : ==16181== Memcheck, a memory error detector ==16181== Copyright (C) 2002-2022, and GNU GPL'd, by Julian Seward et al. ==16181== Using Valgrind-3.22.0 and LibVEX; rerun with -h for copyright info ==16181== Command: ./main ==16181== ==16181== ==16181== HEAP SUMMARY: ==16181== in use at exit: 15 bytes in 2 blocks ==16181== total heap usage: 3 allocs, 1 frees, 55 bytes allocated ==16181== ==16181== 5 bytes in 1 blocks are definitely lost in loss record 1 of 2 ==16181== at 0x4849E60: calloc (vg_replace_malloc.c:1595) ==16181== by 0x4011DA: main (in main) ==16181== ==16181== 10 bytes in 1 blocks are definitely lost in loss record 2 of 2 ==16181== at 0x4849E60: calloc (vg_replace_malloc.c:1595) ==16181== by 0x401160: another_function (in main) ==16181== by 0x401204: main (in main) ==16181== ==16181== LEAK SUMMARY: ==16181== definitely lost: 15 bytes in 2 blocks ==16181== indirectly lost: 0 bytes in 0 blocks ==16181== possibly lost: 0 bytes in 0 blocks ==16181== still reachable: 0 bytes in 0 blocks ==16181== suppressed: 0 bytes in 0 blocks ==16181== ==16181== For lists of detected and suppressed errors, rerun with: -s ==16181== ERROR SUMMARY: 2 errors from 2 contexts (suppressed: 0 from 0) -- You are receiving this mail because: You are watching all bug changes.
