On Thu, Mar 07, 2013 at 10:10:56AM +0100, Mark Wielaard wrote: > On Thu, 2013-03-07 at 09:42 +0100, Jan Kratochvil wrote: > > On Wed, 06 Mar 2013 16:13:47 +0100, Mark Wielaard wrote: > > > On Wed, 2013-03-06 at 14:38 +0000, Richard W.M. Jones wrote: > > [...] > > > > ==11843== 56 bytes in 1 blocks are definitely lost in loss record 6 of 6 > > > > ==11843== at 0x4A06409: malloc (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so) > > > > ==11843== by 0x38EAC861F9: strdup (strdup.c:42) > > > > ==11843== by 0x38EC8097C9: setprocattrcon_raw.constprop.3 (procattr.c:241) > > > > ==11843== by 0x38EC8099B7: setprocattrcon.constprop.2 (procattr.c:274) > > > > ==11843== by 0x400955: main (in /tmp/test) > > [...] > > > It looks like you will have to use the setprocattrcon[.constprop] > > > function name in your suppression file. I am not exactly sure how the > > > linker ends up pointing directly to that one for setsockcreatecon (), > > > but it apparently is. And so valgrind will only know it by that name. > > > > Symbol table '.symtab' contains 770 entries: > > Num: Value Size Type Bind Vis Ndx Name > > 70: 0000000000009990 62 FUNC LOCAL DEFAULT 11 setprocattrcon.constprop.2 > > > > Contents of the .debug_info section: > > <1><62c6>: Abbrev Number: 58 (DW_TAG_subprogram) > > <62c7> DW_AT_name : (indirect string, offset: 0x3eb4): setprocattrcon > > <62d2> DW_AT_inline : 1 (inlined) > > <1><6791>: Abbrev Number: 40 (DW_TAG_subprogram) > > <6792> DW_AT_abstract_origin: <0x62c6> > > <6794> DW_AT_low_pc : 0x9990 > > <679c> DW_AT_high_pc : 62 > > > > Valgrind apparently used the ELF symbol name. But in DWARF there is the real > > function name (and it is even marked as 'inlined' - although it is a standalone > > function). > > > > GDB also knows the real name from DWARF: > > > > (gdb) disas 'setprocattrcon.constprop.2' > > Dump of assembler code for function setprocattrcon: > > 0x0000000000009990 <+0>: push %rbx > > [...] > > 0x00000000000099cd <+61>: retq > > End of assembler dump. > > > > So it is possible to fix it in Valgrind. > > Aha, thanks. Yes using DWARF might help getting more user > friendly/recognizable names. > > Though note that the name we were really looking for was > setsockcreatecon, since that is what was called from main. I think that > one is doing a tail-call to setprocattrcon.constprop.2 so might not > easily be available in the backtrace. If you compile and run Richard's > reproducer from https://bugzilla.redhat.com/show_bug.cgi?id=918572 and > break at the strdup call, can you get a backtrace from gdb with > setsockcreatecon in it? The answer seems to be no. This is on a very up to date Rawhide: Breakpoint 2, __GI___strdup ( s=0x6021e0 "unconfined_u:unconfined_r:svirt_socket_t:s0-s0:c0.c1023") at strdup.c:40 40 { (gdb) bt #0 __GI___strdup ( s=0x6021e0 "unconfined_u:unconfined_r:svirt_socket_t:s0-s0:c0.c1023") at strdup.c:40 #1 0x00000038ec8097ca in setprocattrcon_raw ( context=0x6021e0 "unconfined_u:unconfined_r:svirt_socket_t:s0-s0:c0.c1023", attr=attr@entry=0x38ec8181f6 "sockcreate", pid=0) at procattr.c:241 #2 0x00000038ec8099b8 in setprocattrcon (context=<optimized out>, attr=0x38ec8181f6 "sockcreate", pid=0) at procattr.c:274 #3 0x0000000000400956 in main () at test.c:33 > Also using DWARF .debug_info will only work if it is available. By > default valgrind doesn't require DWARF, it uses only the symbol table. I > can look in extending valgrind to use the DWARF info when available for > matching suppressions, but that might mean a suppression only works when > the debuginfo is installed (and it might make valgrind even slower). Actually we found that our suppressions only work properly when we're careful to install debuginfo packages. Otherwise some of the patterns don't match and we get false positives. Here's our suppressions file FWIW: https://github.com/libguestfs/libguestfs/blob/master/valgrind-suppressions Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones virt-p2v converts physical machines to virtual machines. Boot with a live CD or over the network (PXE) and turn machines into KVM guests. http://libguestfs.org/virt-v2v -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel