How to let valgrind to report "where" a "definitely lost" happens

Is there a way to let valgrind to report "where" a "definitely lost" happens?

What I want is not "where it's allocated", but "where that poor piece of memory got leaked".

For example, this piece of code has a "definitely lost" leak when f() returns:

#include <stdlib.h>

void f () {
    void *ptr = malloc(42);
}

int main () {
    f();
    return 0;
}

But valgrind only reports the origin of allocation:

==9772== HEAP SUMMARY:
==9772==     in use at exit: 42 bytes in 1 blocks
==9772==   total heap usage: 1 allocs, 0 frees, 42 bytes allocated
==9772==
==9772== 42 bytes in 1 blocks are definitely lost in loss record 1 of 1
==9772==    at 0x4C2AB80: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==9772==    by 0x40053E: f (test.c:4)
==9772==    by 0x400552: main (test.c:8)
==9772==
==9772== LEAK SUMMARY:
==9772==    definitely lost: 42 bytes in 1 blocks
==9772==    indirectly lost: 0 bytes in 0 blocks
==9772==      possibly lost: 0 bytes in 0 blocks
==9772==    still reachable: 0 bytes in 0 blocks
==9772==         suppressed: 0 bytes in 0 blocks
==9772==
==9772== For counts of detected and suppressed errors, rerun with: -v
==9772== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 0 from 0)

I'm using --leak-check=full and --track-origins=yes.

Solution

What I want is not "where it's allocated", but "where that poor piece of memory got leaked".

No, Valgrind only reports where the memory was allocated, but not when how or why it was leaked. This behavior is documented in Memcheck manual:

If --leak-check=full is specified, Memcheck will give details for each definitely lost or possibly lost block, including where it was allocated. (Actually, it merges results for all blocks that have the same leak kind and sufficiently similar stack traces into a single "loss record". The --leak-resolution lets you control the meaning of "sufficiently similar".) It cannot tell you when or how or why the pointer to a leaked block was lost; you have to work that out for yourself.

Also --track-origins has nothing to do with memory leaks. It is used for tracking the origin of uninitialised values.