https://bugs.kde.org/show_bug.cgi?id=455826
--- Comment #5 from shapath <meeee...@gmail.com> --- (In reply to Philippe Waroquiers from comment #4) > (In reply to shapath from comment #3) > > > > Valgrind report:- > > ============== > > (gdb) monitor leak_check full reachable any > When compiling with gcc -g -O0 and doing the leak search, > I do not get any definitely or possibly leaked block. Leak search reports > 2 still reachable blocks. > > You can use the following to see why a block is still reachable: > (where 0x4a330a0 is the addess of the strdup-ed "hello" > (gdb) mo w 0x4a330a0 > ==8392== Searching for pointers to 0x4a330a0 > ==8392== tid 1 register R8 pointing at 0x4a330a0 > (gdb) > > > As you can see, in my case, the address of the just allocated name still > happens > to be in a register. > > When I force main to return, then name is reported as definitely leaked > (as the register pointing to name is likely used for something else) Tried the suggestion to compile with -O0. Also modified program to print the address for strdup-ed "hello" before the program hits the infinite while loop. i see it reported as a definite leak. I tried "mo w 0x52050a0" which does not return any reference register where 0x52050a0 is the address. (sjohri/coding)$ gcc -g -O0 valgrind.c -o val_exmple (sjohri/coding)$ valgrind --log-file=/var/tmp/_valgrind_%p --xml-file=/var/tmp/_valgrind_xml_%p ./val_exmple "The strdup-ed address is 0x52050a0" :(sjohri/coding)$ gdb val_exmple GNU gdb (GDB) Red Hat Enterprise Linux 7.6.1-120.0.1.el7 Copyright (C) 2013 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html> This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "x86_64-redhat-linux-gnu". For bug reporting instructions, please see: <http://www.gnu.org/software/gdb/bugs/>... Reading symbols from /home/sjohri/coding/val_exmple...done. (gdb) target remote | vgdb Remote debugging using | vgdb relaying data between gdb and process 86547 Reading symbols from /usr/libexec/valgrind/vgpreload_core-amd64-linux.so...done. Loaded symbols for /usr/libexec/valgrind/vgpreload_core-amd64-linux.so Reading symbols from /usr/libexec/valgrind/vgpreload_memcheck-amd64-linux.so...done. Loaded symbols for /usr/libexec/valgrind/vgpreload_memcheck-amd64-linux.so Reading symbols from /lib64/libc.so.6...(no debugging symbols found)...done. Loaded symbols for /lib64/libc.so.6 Reading symbols from /lib64/ld-linux-x86-64.so.2...(no debugging symbols found)...done. Loaded symbols for /lib64/ld-linux-x86-64.so.2 0x0000000004efc9e0 in __nanosleep_nocancel () from /lib64/libc.so.6 Missing separate debuginfos, use: debuginfo-install glibc-2.17-326.0.1.el7_9.x86_64 (gdb) monitor leak_check full reachable any ==86547== 6 bytes in 1 blocks are definitely lost in loss record 1 of 2 ==86547== at 0x4C29F73: malloc (vg_replace_malloc.c:309) ==86547== by 0x4EC3B89: strdup (in /usr/lib64/libc-2.17.so) ==86547== by 0x4006B2: my_malloc (valgrind.c:29) ==86547== by 0x40070E: main (valgrind.c:39) ==86547== ==86547== 26 bytes in 1 blocks are still reachable in loss record 2 of 2 ==86547== at 0x4C29F73: malloc (vg_replace_malloc.c:309) ==86547== by 0x4006F4: main (valgrind.c:38) ==86547== ==86547== LEAK SUMMARY: ==86547== definitely lost: 6 bytes in 1 blocks ==86547== indirectly lost: 0 bytes in 0 blocks ==86547== possibly lost: 0 bytes in 0 blocks ==86547== still reachable: 26 bytes in 1 blocks ==86547== suppressed: 0 bytes in 0 blocks ==86547== (gdb) mo w 0x52050a0 ==86547== Searching for pointers to 0x52050a0 (gdb) -- You are receiving this mail because: You are watching all bug changes.
