https://bugs.kde.org/show_bug.cgi?id=483372
--- Comment #2 from Darnethal0z ---
(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.
