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.constp
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:
On Thu, 07 Mar 2013 14:20:40 +0100, Mark Wielaard wrote:
> It is kind of funny that gcc generates better/fuller
> debuginfo with higher optimizations these days.
There is even -Og for debugging as the best of -O0 and -O2 but I do not have
much practical experience with it yet.
Jan
--
devel mail
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)
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==
On Thu, Mar 07, 2013 at 10:55:58AM +, 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__
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 +, Richard W.M. Jones wrote:
> > [...]
> > > > ==11843== 56 bytes in 1 blocks
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 +, Richard W.M. Jones wrote:
> [...]
> > > ==11843== 56 bytes in 1 blocks are definitely lost in loss record 6 of 6
> > > ==11843==at 0x4A06409
On Wed, 06 Mar 2013 16:13:47 +0100, Mark Wielaard wrote:
> On Wed, 2013-03-06 at 14:38 +, 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-linu
On Wed, 2013-03-06 at 14:38 +, 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
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_
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 put
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 fr
13 matches
Mail list logo
