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 -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel
