Testing valgrind in rawhide (separate valgrind-debuginfo package)

[Richard W.M. Jones]

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 at entry=0x7ffff7bd11f6 "sockcreate", pid=0) at procattr.c:241
> > #2  0x00007ffff7bc29b8 in setprocattrcon (context=<optimized out>, attr=attr at 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.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
virt-top is 'top' for virtual machines.  Tiny program with many
powerful monitoring features, net stats, disk stats, logging, etc.
http://people.redhat.com/~rjones/virt-top