https://bugs.kde.org/show_bug.cgi?id=455826
--- Comment #7 from Philippe Waroquiers <philippe.waroqui...@skynet.be> --- On Fri, 2022-06-24 at 10:06 +0000, shapath wrote: > 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. Depending on the code generated by the compiler and the moment at which a leak search is done, a pointer might still be present (or not) in one register. > > (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) As the struct component "name" is not aligned, the content of "char *name" is not considered as a pointer, and so the strdup-ed string is considered as definitely lost in your case. Philippe -- You are receiving this mail because: You are watching all bug changes.
