Hi,
I am looking for some valgrind users that want to try out the latest valgrind package in rawhide.
If you use valgrind please try out the new valgrind-3.8.1-10.fc19 version in rawhide. It is the first version that puts the debuginfo in a separate valgrind-debuginfo package (this saves ~35MB from the main packages). http://koji.fedoraproject.org/koji/buildinfo?buildID=399059
Upstream used to recommend against stripping debuginfo from the valgrind vg preload libraries because it produced less usable warning/error messages. But since a long time now valgrind intercepts are done in a different way and just having the dynsym symbols around should be enough.
Please let me know (or file a bug report) if using the new valgrind package from rawhide gives less useful warnings/errors (and whether installing valgrind-debuginfo solves any of such issues).
Thanks,
Mark
BTW. I also backported some issues that showed up with the new kernel and glibc to the f18 valgrind package, but obviously not the debuginfo separation. Testers for valgrind-3.8.1-9.fc18 currently in updates-testing also welcome. But this update should just contains benign bugfixes since it is targetted for stable. https://admin.fedoraproject.org/updates/FEDORA-2013-3322/valgrind-3.8.1-9.fc...
On Mon, Mar 04, 2013 at 02:15:30PM +0100, Mark Wielaard wrote:
Hi,
I am looking for some valgrind users that want to try out the latest valgrind package in rawhide.
If you use valgrind please try out the new valgrind-3.8.1-10.fc19 version in rawhide. It is the first version that puts the debuginfo in a separate valgrind-debuginfo package (this saves ~35MB from the main packages). http://koji.fedoraproject.org/koji/buildinfo?buildID=399059
Upstream used to recommend against stripping debuginfo from the valgrind vg preload libraries because it produced less usable warning/error messages. But since a long time now valgrind intercepts are done in a different way and just having the dynsym symbols around should be enough.
Please let me know (or file a bug report) if using the new valgrind package from rawhide gives less useful warnings/errors (and whether installing valgrind-debuginfo solves any of such issues).
I tested valgrind-3.8.1-10.fc19.x86_64 (without valgrind-debuginfo). It appears to work fine. There's no noticable difference between this version and earlier versions.
Rich.
BTW can you clear up a peculiarity I've noticed in valgrind in Rawhide?
The symbols reported in the stack traces seem to be mangled in a strange way, eg:
==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)
The symbol we're actually calling is 'setsockcreatecon'. It's not a macro. There is no public function called 'setprocattrcon' (although there is an internal function of that name and setsockcreatecon only calls this internal functions so there could be some inlining going on). And what's with the '.constprop.2' suffix?
In any case, this is a problem because in my valgrind suppressions file I have to list the mangled name, not the real name.
Test program is here if you want to try it:
https://bugzilla.redhat.com/show_bug.cgi?id=918572
Rich.
On Wed, 2013-03-06 at 14:38 +0000, Richard W.M. Jones wrote:
BTW can you clear up a peculiarity I've noticed in valgrind in Rawhide?
The symbols reported in the stack traces seem to be mangled in a strange way, eg:
==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)
The symbol we're actually calling is 'setsockcreatecon'. It's not a macro. There is no public function called 'setprocattrcon' (although there is an internal function of that name and setsockcreatecon only calls this internal functions so there could be some inlining going on). And what's with the '.constprop.2' suffix?
Right, there is something like inlining going on. Though not actual inlining, more like calling specialied variants of the function. Some GCC hacker might correct me if I get the details wrong. But I think this is just caused by (better) optimization of GCC 4.8 in rawhide. As far as I understand it GCC sees that setsockcreatecon (NULL) is really setprocattrcon with some constant arguments call. The src/procattr.c definition of all_selfattr_def(sockcreatecon, sockcreate) make it a little hard to see exactly, but obviously GCC knows. For example the pid argument will always be zero. Because of this GCC creates a specialized "constant propagation function" based on setprocattrcon called setprocattrcon.constprop.somenumber. And as far as I can see that is the actual function that the setsockcreatecon function PLT entry points to. (And this setprocattrcon.constprop.2 then calls a specialized constant propagation function version of setprocattrcon_raw.)
In any case, this is a problem because in my valgrind suppressions file I have to list the mangled name, not the real name.
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. Sorry.
Note that you can let valgrind create the suppression for you with --gen-suppressions=yes. And you can also use wildcards in suppressions like fun:setprocattrcon.constprop.*.
Cheers,
Mark
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.
Jan
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?
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).
Cheers,
Mark
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.
On Thu, Mar 07, 2013 at 10:55:58AM +0000, Richard W.M. Jones wrote:
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
Note: libselinux-debuginfo-2.1.13-6.fc19.x86_64 is installed.
Rich.
On Wed, 06 Mar 2013 15:38:54 +0100, 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)
The symbol we're actually calling is 'setsockcreatecon'. It's not a macro. There is no public function called 'setprocattrcon'
[...] On Thu, 07 Mar 2013 10:10:56 +0100, Mark Wielaard wrote:
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?
Yes:
(gdb) bt #0 __GI___strdup (s=0x6021e0 "unconfined_u:unconfined_r:svirt_socket_t:s0-s0:c0.c1023") at strdup.c:40 #1 0x00007ffff7bc27ca in setprocattrcon_raw (context=0x6021e0 "unconfined_u:unconfined_r:svirt_socket_t:s0-s0:c0.c1023", attr=attr@entry=0x7ffff7bd11f6 "sockcreate", pid=0) at procattr.c:241 #2 0x00007ffff7bc29b8 in setprocattrcon (context=<optimized out>, attr=attr@entry=0x7ffff7bd11f6 "sockcreate", pid=0) at procattr.c:274 #3 0x00007ffff7bc2ddc in setsockcreatecon (c=<optimized out>) at procattr.c:320 #4 0x0000000000400818 in main () at constprop.c:33 (gdb) info frame 3 Stack frame at 0x7fffffffe130: rip = 0x7ffff7bc2ddc in setsockcreatecon (procattr.c:320); saved rip 0x7ffff781ab75 tail call frame, caller of frame at 0x7fffffffe130 ^^^^^^^^^^^^^^^ source language c. Arglist at unknown address. Locals at unknown address, Previous frame's sp is 0x7fffffffe130
But one has to compile the main program with -O2 -g so that it has the needed call site debug information: gcc -Wall constprop.c -o constprop -lselinux -g -O2
<2><37e>: Abbrev Number: 21 (DW_TAG_GNU_call_site) <37f> DW_AT_low_pc : 0x400818 <387> DW_AT_abstract_origin: <0x515> <1><515>: Abbrev Number: 24 (DW_TAG_subprogram) <516> DW_AT_name : (indirect string, offset: 0x11): setsockcreatecon <520> DW_AT_declaration : 1
Jan
On Thu, 2013-03-07 at 13:42 +0100, Jan Kratochvil wrote:
On Wed, 06 Mar 2013 15:38:54 +0100, 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)
The symbol we're actually calling is 'setsockcreatecon'. It's not a macro. There is no public function called 'setprocattrcon'
[...] On Thu, 07 Mar 2013 10:10:56 +0100, Mark Wielaard wrote:
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?
Yes:
(gdb) bt #0 __GI___strdup (s=0x6021e0 "unconfined_u:unconfined_r:svirt_socket_t:s0-s0:c0.c1023") at strdup.c:40 #1 0x00007ffff7bc27ca in setprocattrcon_raw (context=0x6021e0 "unconfined_u:unconfined_r:svirt_socket_t:s0-s0:c0.c1023", attr=attr@entry=0x7ffff7bd11f6 "sockcreate", pid=0) at procattr.c:241 #2 0x00007ffff7bc29b8 in setprocattrcon (context=<optimized out>, attr=attr@entry=0x7ffff7bd11f6 "sockcreate", pid=0) at procattr.c:274 #3 0x00007ffff7bc2ddc in setsockcreatecon (c=<optimized out>) at procattr.c:320 #4 0x0000000000400818 in main () at constprop.c:33 (gdb) info frame 3 Stack frame at 0x7fffffffe130: rip = 0x7ffff7bc2ddc in setsockcreatecon (procattr.c:320); saved rip 0x7ffff781ab75 tail call frame, caller of frame at 0x7fffffffe130 ^^^^^^^^^^^^^^^ source language c. Arglist at unknown address. Locals at unknown address, Previous frame's sp is 0x7fffffffe130
But one has to compile the main program with -O2 -g so that it has the needed call site debug information: gcc -Wall constprop.c -o constprop -lselinux -g -O2
O, very nice! It is kind of funny that gcc generates better/fuller debuginfo with higher optimizations these days.
Currently valgrind doesn't handle DW_TAG_GNU_call_site at all. But if people install debuginfo anyway to get better backtraces and/or symbol resolution it might make sense to teach valgrind about it.
Thanks,
Mark
On Thu, Mar 07, 2013 at 02:20:40PM +0100, Mark Wielaard wrote:
On Thu, 2013-03-07 at 13:42 +0100, Jan Kratochvil wrote:
On Wed, 06 Mar 2013 15:38:54 +0100, 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)
The symbol we're actually calling is 'setsockcreatecon'. It's not a macro. There is no public function called 'setprocattrcon'
[...] On Thu, 07 Mar 2013 10:10:56 +0100, Mark Wielaard wrote:
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?
Yes:
(gdb) bt #0 __GI___strdup (s=0x6021e0 "unconfined_u:unconfined_r:svirt_socket_t:s0-s0:c0.c1023") at strdup.c:40 #1 0x00007ffff7bc27ca in setprocattrcon_raw (context=0x6021e0 "unconfined_u:unconfined_r:svirt_socket_t:s0-s0:c0.c1023", attr=attr@entry=0x7ffff7bd11f6 "sockcreate", pid=0) at procattr.c:241 #2 0x00007ffff7bc29b8 in setprocattrcon (context=<optimized out>, attr=attr@entry=0x7ffff7bd11f6 "sockcreate", pid=0) at procattr.c:274 #3 0x00007ffff7bc2ddc in setsockcreatecon (c=<optimized out>) at procattr.c:320 #4 0x0000000000400818 in main () at constprop.c:33 (gdb) info frame 3 Stack frame at 0x7fffffffe130: rip = 0x7ffff7bc2ddc in setsockcreatecon (procattr.c:320); saved rip 0x7ffff781ab75 tail call frame, caller of frame at 0x7fffffffe130 ^^^^^^^^^^^^^^^ source language c. Arglist at unknown address. Locals at unknown address, Previous frame's sp is 0x7fffffffe130
But one has to compile the main program with -O2 -g so that it has the needed call site debug information: gcc -Wall constprop.c -o constprop -lselinux -g -O2
O, very nice! It is kind of funny that gcc generates better/fuller debuginfo with higher optimizations these days.
Currently valgrind doesn't handle DW_TAG_GNU_call_site at all. But if people install debuginfo anyway to get better backtraces and/or symbol resolution it might make sense to teach valgrind about it.
I can also confirm that with -O2 the correct symbol is shown in the gdb stack trace on Rawhide.
Rich.
Mark Wielaard wrote:
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?
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).
To go from setprocattrcon.constprop.2 (the ELF symbol name) to setprocattrcon (the name in DWARF), you don't need the DWARF at all, just a s/.constprop.[0-9]+$//g. :-)
Kevin Kofler
-
Jan Kratochvil -
Kevin Kofler -
Mark Wielaard -
Richard W.M. Jones