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