valgrind-users — General discussion list for Valgrind users

Re: [Valgrind-users] ulimit under valgrind

[Tom H. <to...@co...>]

On 06/10/14 16:22, Tom Hughes wrote:
> On 06/10/14 16:08, Skarakis, Konstantinos wrote:
>
>> I am having trouble running programs that need to use "ulimit" under valgrind. For instance, here is a simple script that changes the limit of open files to 100000. All commands below are executed as root:
>>
>>> cat foo
>> #!/bin/sh
>> ulimit -n 100000
>>
>> I can run it fine on its own.
>>
>>> ./foo
>>> echo $?
>> 0
>>
>> But under valgrind I get blocked with "Operation not permitted":
>
> Because valgrind needs to reserve a few file descriptors for it's own
> use it effectively reduces the hard limit slightly, so you won't be able
> to raise your own soft limit above that reduced hard limit.

Actually it's worse than that, we allocate the 10 reserved descriptors 
immediately above the soft limit (assuming there is space) and 
effectively convert the initial soft limit to a hard limit.

Tom

-- 
Tom Hughes (to...@co...)
http://compton.nu/

Re: [Valgrind-users] ulimit under valgrind

[Tom H. <to...@co...>]

On 06/10/14 16:08, Skarakis, Konstantinos wrote:

> I am having trouble running programs that need to use "ulimit" under valgrind. For instance, here is a simple script that changes the limit of open files to 100000. All commands below are executed as root:
>
>> cat foo
> #!/bin/sh
> ulimit -n 100000
>
> I can run it fine on its own.
>
>> ./foo
>> echo $?
> 0
>
> But under valgrind I get blocked with "Operation not permitted":

Because valgrind needs to reserve a few file descriptors for it's own 
use it effectively reduces the hard limit slightly, so you won't be able 
to raise your own soft limit above that reduced hard limit.

If you query the hard limit with getrlimit and then increase your soft 
limit to that then you should find it works.

Tom

-- 
Tom Hughes (to...@co...)
http://compton.nu/

[Valgrind-users] ulimit under valgrind

[Skarakis, K. <kon...@un...>]

Hello,

I am having trouble running programs that need to use "ulimit" under valgrind. For instance, here is a simple script that changes the limit of open files to 100000. All commands below are executed as root:

> cat foo
#!/bin/sh
ulimit -n 100000

I can run it fine on its own.

> ./foo
> echo $?
0

But under valgrind I get blocked with "Operation not permitted":

> valgrind ./foo
==729== Memcheck, a memory error detector
==729== Copyright (C) 2002-2011, and GNU GPL'd, by Julian Seward et al.
==729== Using Valgrind-3.7.0 and LibVEX; rerun with -h for copyright info
==729== Command: ./foo
==729== 
./foo: line 2: ulimit: open files: cannot modify limit: Operation not permitted
==729== 
==729== HEAP SUMMARY:
==729==     in use at exit: 22,355 bytes in 579 blocks
==729==   total heap usage: 689 allocs, 110 frees, 34,516 bytes allocated
==729== 
==729== LEAK SUMMARY:
==729==    definitely lost: 0 bytes in 0 blocks
==729==    indirectly lost: 0 bytes in 0 blocks
==729==      possibly lost: 0 bytes in 0 blocks
==729==    still reachable: 22,355 bytes in 579 blocks
==729==         suppressed: 0 bytes in 0 blocks
==729== Rerun with --leak-check=full to see details of leaked memory
==729== 
==729== For counts of detected and suppressed errors, rerun with: -v
==729== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 4 from 4)

Right now I have no entries in /etc/security/limits.conf, however it looks like the file is not even accessed:

> strace -s 100 -f /usr/bin/valgrind ./foo > trace 2>&1
> grep limits.conf trace
> echo $?
1

Any hints will be much appreciated.

My platform is 64-bit Linux.


Thank you,
Costas


PS: Here is part of the trace I took above. Maybe it is obvious to someone what goes wrong:

read(255, "#!/bin/sh\nulimit -n 100000\n", 27) = 27
rt_sigprocmask(SIG_SETMASK, ~[ILL TRAP BUS FPE KILL SEGV STOP], NULL, 8) = 0
gettid()                                = 784
read(1027, "G", 1)                      = 1
rt_sigprocmask(SIG_SETMASK, ~[], ~[ILL TRAP BUS FPE KILL SEGV STOP], 8) = 0
rt_sigtimedwait(~[], 0x4029a1d00)       = -1 EAGAIN (Resource temporarily unavailable)
rt_sigprocmask(SIG_SETMASK, ~[ILL TRAP BUS FPE KILL SEGV STOP], NULL, 8) = 0
getrlimit(RLIMIT_NOFILE, {rlim_cur=1034, rlim_max=8*1024}) = 0
getrlimit(RLIMIT_NOFILE, {rlim_cur=1034, rlim_max=8*1024}) = 0
fstat(2, {st_mode=S_IFREG|0644, st_size=129020, ...}) = 0
mmap(0x4028000, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x4028000
gettid()                                = 784
write(1028, "H", 1)                     = 1
rt_sigprocmask(SIG_SETMASK, [], ~[ILL TRAP BUS FPE KILL SEGV STOP], 8) = 0
write(2, "./foo: line 2: ulimit: open files: cannot modify limit: Operation not permitted\n", 80./foo: line 2: ulimit: open files: cannot modify limit: Operation not permitted) = 80

Re: [Valgrind-users] [lxc-users] Using valgrind with lxc

[Vallevand, M. K <Mar...@UN...>]

From my test program, which is trying to recreate the issue we see when running valgrind against our application.
Our application, running on Ubuntu 12.04 LTS, is a complicated control program that is having a memory leak or corruption.
The program manages multiple containers which are running a mature program that doesn't need any valgrinding.  The
program does a fork() and in the child process the lxc library is called to start the mature program in a container 
using lxc_start().  My test program is a very simple thing that just does an lxc_start() or __lxc_start() against an 
existing container.  (The __lxc_start() and some supporting code were copied into my test program and compiled there.
It was simpler.  But, it's still __lxc_start(). )


Regards.
Mark K Vallevand

"If there are no dogs in Heaven, then when I die I want to go where they went." 
-Will Rogers

THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY MATERIAL and is thus for use only by the intended recipient. If you received this in error, please contact the sender and delete the e-mail and its attachments from all computers.


-----Original Message-----
From: lxc-users [mailto:lxc...@li...] On Behalf Of Serge Hallyn
Sent: Wednesday, October 01, 2014 04:59 PM
To: LXC users mailing-list
Cc: val...@li...
Subject: Re: [lxc-users] Using valgrind with lxc

You called __lxc_start() from where, how?

Quoting Vallevand, Mark K (Mar...@UN...):
> I did this by calling __lxc_start().  So, lxc_check_inherited() didn't get called.  That was this:
> > If I call __lxc_start() rather than lxc_start(), I see this:
> > vdr1: sync wake failure : Broken pipe
> > vdr1: failed to spawn 'vdr1'
> > And, just before that there is some complaining from valgrind:
> > ==25086== Syscall param clone(child_tidptr) contains uninitialised byte(s)

lxc uses the libc clone wrappers and does not pass in a tidptr...

> > ==25086==    at 0x56622E1: clone (clone.S:84)
> > ==25086==    by 0x4E3BD38: __lxc_start (in /usr/lib/lxc/liblxc.so.0.7.5)
> > ==25086==    by 0x4014C9: vgVdrStartClone (vgVdrTest.c:88)
> > ==25086==    by 0x400F0A: main (vgVdrTest.c:337)
> > ==25086==
> > ==1== Syscall param wait4(status) points to unaddressable byte(s)
> > ==1==    at 0x53607C4: wait (wait.c:32)
> > ==1==    by 0x4E3A400: ??? (in /usr/lib/lxc/liblxc.so.0.7.5)
> > ==1==    by 0x566231C: clone (clone.S:112)
> > ==1==  Address 0xffffffffffffffd4 is not stack'd, malloc'd or (recently) free'd

Would help to see file:line in the lxc code (as would using
a newer lxc :)

> > ==1== Invalid write of size 4
> > ==1==    at 0x4E3A4FF: ??? (in /usr/lib/lxc/liblxc.so.0.7.5)
> > ==1==    by 0x566231C: clone (clone.S:112)
> > ==1==  Address 0xffffffffffffffc0 is not stack'd, malloc'd or (recently) free'd
> > ==1==
> > ==1==
> > ==1== Process terminating with default action of signal 11 (SIGSEGV)
> > ==1==  Access not within mapped region at address 0xFFFFFFFFFFFFFFC0
> > ==1==    at 0x4E3A4FF: ??? (in /usr/lib/lxc/liblxc.so.0.7.5)
> > ==1==    by 0x566231C: clone (clone.S:112)
> 
> 
> Regards.
> Mark K Vallevand
> 
> "If there are no dogs in Heaven, then when I die I want to go where they went." 
> -Will Rogers
> 
> THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY MATERIAL and is thus for use only by the intended recipient. If you received this in error, please contact the sender and delete the e-mail and its attachments from all computers.
> 
> 
> -----Original Message-----
> From: lxc-users [mailto:lxc...@li...] On Behalf Of Serge Hallyn
> Sent: Wednesday, October 01, 2014 04:18 PM
> To: LXC users mailing-list
> Cc: val...@li...
> Subject: Re: [lxc-users] Using valgrind with lxc
> 
> Hi,
> 
> For the sake of testing I'd go ahead and just 'return 0' at the
> top of lxc_check_inherited.
> 
> We can talk about adding an option to do this, i.e.
> lxc.close_all_fds = -1 maybe.  It's a very rare case where
> that should be done, though.
> 
> -serge
> 
> Quoting Vallevand, Mark K (Mar...@UN...):
> > Valgrind meet containers.
> > Containers meet valgrind.
> > 
> > I've found what lxc doesn't like when running valgrind.
> > 
> > The lxc_start() checks to see if there are extra file descriptors open and won't call __lxc_start().
> > vdr1: inherited fd 1024 on /home/vallevand/trunk_s4m/s4m-appliance/src/vdrd/vgVdrTest
> > vdr1: inherited fd 1025 on /tmp/valgrind_proc_24989_cmdline_4fbfb9a5 (deleted)VdrTest
> > vdr1: inherited fd 1026 on /dev/pts/1ind_proc_24989_cmdline_4fbfb9a5 (deleted)VdrTest
> > vdr1: inherited fd 1027 on pipe:[768863]_proc_24989_cmdline_4fbfb9a5 (deleted)VdrTest
> > vdr1: inherited fd 1028 on pipe:[768863]_proc_24989_cmdline_4fbfb9a5 (deleted)VdrTest
> > 
> > Vdr1 is the name of my container.  All those open files in the child process are related to valgrind.
> > 
> > If I call __lxc_start() rather than lxc_start(), I see this:
> > vdr1: sync wake failure : Broken pipe
> > vdr1: failed to spawn 'vdr1'
> > And, just before that there is some complaining from valgrind:
> > ==25086== Syscall param clone(child_tidptr) contains uninitialised byte(s)
> > ==25086==    at 0x56622E1: clone (clone.S:84)
> > ==25086==    by 0x4E3BD38: __lxc_start (in /usr/lib/lxc/liblxc.so.0.7.5)
> > ==25086==    by 0x4014C9: vgVdrStartClone (vgVdrTest.c:88)
> > ==25086==    by 0x400F0A: main (vgVdrTest.c:337)
> > ==25086==
> > ==1== Syscall param wait4(status) points to unaddressable byte(s)
> > ==1==    at 0x53607C4: wait (wait.c:32)
> > ==1==    by 0x4E3A400: ??? (in /usr/lib/lxc/liblxc.so.0.7.5)
> > ==1==    by 0x566231C: clone (clone.S:112)
> > ==1==  Address 0xffffffffffffffd4 is not stack'd, malloc'd or (recently) free'd
> > ==1==
> > ==1== Invalid write of size 4
> > ==1==    at 0x4E3A4FF: ??? (in /usr/lib/lxc/liblxc.so.0.7.5)
> > ==1==    by 0x566231C: clone (clone.S:112)
> > ==1==  Address 0xffffffffffffffc0 is not stack'd, malloc'd or (recently) free'd
> > ==1==
> > ==1==
> > ==1== Process terminating with default action of signal 11 (SIGSEGV)
> > ==1==  Access not within mapped region at address 0xFFFFFFFFFFFFFFC0
> > ==1==    at 0x4E3A4FF: ??? (in /usr/lib/lxc/liblxc.so.0.7.5)
> > ==1==    by 0x566231C: clone (clone.S:112)
> > 
> > Our program is designed to close all open file descriptors in the child process before calling lxc_start().  That code can try to close all file descriptors to make sure something doesn't sneak through.  However, closing the file descriptors associated with valgrind does not work.  I get errno=0 Bad File Descriptor.  Valgrind really has them held open.  I am running as root in all these tests.
> > 
> > I've also reproduced the problem using the 'lxc-' programs.  If you do something like 'lxc-create -n XXX' and then something like 'valgrind lxc-start -n XXX -- ls' you'll see it.  Well, the flavor of the error with open file descriptors.
> > 
> > My hopes aren't high, but any ideas are very welcome.
> > 
> > Regards.
> > Mark K Vallevand
> > "If there are no dogs in Heaven, then when I die I want to go where they went."
> > -Will Rogers
> > 
> > THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY MATERIAL and is thus for use only by the intended recipient. If you received this in error, please contact the sender and delete the e-mail and its attachments from all computers.
> > From: lxc-users [mailto:lxc...@li...] On Behalf Of Vallevand, Mark K
> > Sent: Thursday, September 25, 2014 09:19 AM
> > To: lxc...@li...
> > Subject: [lxc-users] Using valgrind with lxc
> > 
> > In our program, we do a fork() and in the child process the lxc library is called to start a program in a container using lxc_start().
> > 
> > We don't care about valgrind in the child process.  You can disable valgrind messages from child processes, but you cannot detach valgrind unless you exec() a new binary on top.  However, valgrind and lxc do not play nicely, at least with the versions in Ubuntu 12.04 LTS.   I'm getting an error back from lxc_start().  I'm having trouble getting logs to see why its failing, so I don't know exactly what's failing, yet.
> > 
> > But, I'm looking for any ideas for getting valgrind to work with programs that use lxc_start().
> > Any suggestions will be welcome.  And, thanks!
> > 
> > 
> > Regards.
> > Mark K Vallevand
> > "If there are no dogs in Heaven, then when I die I want to go where they went."
> > -Will Rogers
> > 
> > THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY MATERIAL and is thus for use only by the intended recipient. If you received this in error, please contact the sender and delete the e-mail and its attachments from all computers.
> 
> > _______________________________________________
> > lxc-users mailing list
> > lxc...@li...
> > http://lists.linuxcontainers.org/listinfo/lxc-users
> 
> _______________________________________________
> lxc-users mailing list
> lxc...@li...
> http://lists.linuxcontainers.org/listinfo/lxc-users
> _______________________________________________
> lxc-users mailing list
> lxc...@li...
> http://lists.linuxcontainers.org/listinfo/lxc-users
_______________________________________________
lxc-users mailing list
lxc...@li...
http://lists.linuxcontainers.org/listinfo/lxc-users

[Valgrind-users] Compile valgrind with MPI support (intel)

[Thomas M. <tho...@gm...>]

Hello!

I have come across a problem compiling valgrind with MPI support
(using the intel mpicc). The configure script hangs at the line:

checking primary target for usable MPI2-compliant C compiler and mpi.h...

I can see several mpicc processes running. When I hit CTRL+C to check
the config.log, I see the command:

configure:10780: /path/to/mpicc -o conftest -g -O
-fno-omit-frame-pointer -Wall -fpic -m64  -fpic -shared -m64
conftest.c  >&  5

I saved the conftest.c and issued the command:

/path/to/mpicc -o conftest -g -O -fno-omit-frame-pointer -Wall -fpic
-m64  -fpic -shared -m64 conftest.c

The compiler issues a warning:

conftest.c(96): remark #111: statement is unreachable
    return 0;
    ^

but produces the binary conftest nevertheless. However, when I execute
it I get a segfault.

When I compile it with /path/to/mpicc -o conftest -g -O
-fno-omit-frame-pointer -Wall -fpic -m64  -fpic -shared-intel -m64
conftest.c

i.e. "-shared-intel" instead of plain "-shared", I do not get the
segfault upon execution.

So I tried to change the LDFLAGS_MPI in configure to
LDFLAGS_MPI="-fpic -shared-intel". But that did not help in getting
past the  "primary target test".

Now my question is: how can I get valgrind to compile with MPI support (intel)?

Thank you,

Thomas

Re: [Valgrind-users] [lxc-users] Using valgrind with lxc

[Vallevand, M. K <Mar...@UN...>]

I did this by calling __lxc_start().  So, lxc_check_inherited() didn't get called.  That was this:
> If I call __lxc_start() rather than lxc_start(), I see this:
> vdr1: sync wake failure : Broken pipe
> vdr1: failed to spawn 'vdr1'
> And, just before that there is some complaining from valgrind:
> ==25086== Syscall param clone(child_tidptr) contains uninitialised byte(s)
> ==25086==    at 0x56622E1: clone (clone.S:84)
> ==25086==    by 0x4E3BD38: __lxc_start (in /usr/lib/lxc/liblxc.so.0.7.5)
> ==25086==    by 0x4014C9: vgVdrStartClone (vgVdrTest.c:88)
> ==25086==    by 0x400F0A: main (vgVdrTest.c:337)
> ==25086==
> ==1== Syscall param wait4(status) points to unaddressable byte(s)
> ==1==    at 0x53607C4: wait (wait.c:32)
> ==1==    by 0x4E3A400: ??? (in /usr/lib/lxc/liblxc.so.0.7.5)
> ==1==    by 0x566231C: clone (clone.S:112)
> ==1==  Address 0xffffffffffffffd4 is not stack'd, malloc'd or (recently) free'd
> ==1==
> ==1== Invalid write of size 4
> ==1==    at 0x4E3A4FF: ??? (in /usr/lib/lxc/liblxc.so.0.7.5)
> ==1==    by 0x566231C: clone (clone.S:112)
> ==1==  Address 0xffffffffffffffc0 is not stack'd, malloc'd or (recently) free'd
> ==1==
> ==1==
> ==1== Process terminating with default action of signal 11 (SIGSEGV)
> ==1==  Access not within mapped region at address 0xFFFFFFFFFFFFFFC0
> ==1==    at 0x4E3A4FF: ??? (in /usr/lib/lxc/liblxc.so.0.7.5)
> ==1==    by 0x566231C: clone (clone.S:112)


Regards.
Mark K Vallevand

"If there are no dogs in Heaven, then when I die I want to go where they went." 
-Will Rogers

THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY MATERIAL and is thus for use only by the intended recipient. If you received this in error, please contact the sender and delete the e-mail and its attachments from all computers.


-----Original Message-----
From: lxc-users [mailto:lxc...@li...] On Behalf Of Serge Hallyn
Sent: Wednesday, October 01, 2014 04:18 PM
To: LXC users mailing-list
Cc: val...@li...
Subject: Re: [lxc-users] Using valgrind with lxc

Hi,

For the sake of testing I'd go ahead and just 'return 0' at the
top of lxc_check_inherited.

We can talk about adding an option to do this, i.e.
lxc.close_all_fds = -1 maybe.  It's a very rare case where
that should be done, though.

-serge

Quoting Vallevand, Mark K (Mar...@UN...):
> Valgrind meet containers.
> Containers meet valgrind.
> 
> I've found what lxc doesn't like when running valgrind.
> 
> The lxc_start() checks to see if there are extra file descriptors open and won't call __lxc_start().
> vdr1: inherited fd 1024 on /home/vallevand/trunk_s4m/s4m-appliance/src/vdrd/vgVdrTest
> vdr1: inherited fd 1025 on /tmp/valgrind_proc_24989_cmdline_4fbfb9a5 (deleted)VdrTest
> vdr1: inherited fd 1026 on /dev/pts/1ind_proc_24989_cmdline_4fbfb9a5 (deleted)VdrTest
> vdr1: inherited fd 1027 on pipe:[768863]_proc_24989_cmdline_4fbfb9a5 (deleted)VdrTest
> vdr1: inherited fd 1028 on pipe:[768863]_proc_24989_cmdline_4fbfb9a5 (deleted)VdrTest
> 
> Vdr1 is the name of my container.  All those open files in the child process are related to valgrind.
> 
> If I call __lxc_start() rather than lxc_start(), I see this:
> vdr1: sync wake failure : Broken pipe
> vdr1: failed to spawn 'vdr1'
> And, just before that there is some complaining from valgrind:
> ==25086== Syscall param clone(child_tidptr) contains uninitialised byte(s)
> ==25086==    at 0x56622E1: clone (clone.S:84)
> ==25086==    by 0x4E3BD38: __lxc_start (in /usr/lib/lxc/liblxc.so.0.7.5)
> ==25086==    by 0x4014C9: vgVdrStartClone (vgVdrTest.c:88)
> ==25086==    by 0x400F0A: main (vgVdrTest.c:337)
> ==25086==
> ==1== Syscall param wait4(status) points to unaddressable byte(s)
> ==1==    at 0x53607C4: wait (wait.c:32)
> ==1==    by 0x4E3A400: ??? (in /usr/lib/lxc/liblxc.so.0.7.5)
> ==1==    by 0x566231C: clone (clone.S:112)
> ==1==  Address 0xffffffffffffffd4 is not stack'd, malloc'd or (recently) free'd
> ==1==
> ==1== Invalid write of size 4
> ==1==    at 0x4E3A4FF: ??? (in /usr/lib/lxc/liblxc.so.0.7.5)
> ==1==    by 0x566231C: clone (clone.S:112)
> ==1==  Address 0xffffffffffffffc0 is not stack'd, malloc'd or (recently) free'd
> ==1==
> ==1==
> ==1== Process terminating with default action of signal 11 (SIGSEGV)
> ==1==  Access not within mapped region at address 0xFFFFFFFFFFFFFFC0
> ==1==    at 0x4E3A4FF: ??? (in /usr/lib/lxc/liblxc.so.0.7.5)
> ==1==    by 0x566231C: clone (clone.S:112)
> 
> Our program is designed to close all open file descriptors in the child process before calling lxc_start().  That code can try to close all file descriptors to make sure something doesn't sneak through.  However, closing the file descriptors associated with valgrind does not work.  I get errno=0 Bad File Descriptor.  Valgrind really has them held open.  I am running as root in all these tests.
> 
> I've also reproduced the problem using the 'lxc-' programs.  If you do something like 'lxc-create -n XXX' and then something like 'valgrind lxc-start -n XXX -- ls' you'll see it.  Well, the flavor of the error with open file descriptors.
> 
> My hopes aren't high, but any ideas are very welcome.
> 
> Regards.
> Mark K Vallevand
> "If there are no dogs in Heaven, then when I die I want to go where they went."
> -Will Rogers
> 
> THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY MATERIAL and is thus for use only by the intended recipient. If you received this in error, please contact the sender and delete the e-mail and its attachments from all computers.
> From: lxc-users [mailto:lxc...@li...] On Behalf Of Vallevand, Mark K
> Sent: Thursday, September 25, 2014 09:19 AM
> To: lxc...@li...
> Subject: [lxc-users] Using valgrind with lxc
> 
> In our program, we do a fork() and in the child process the lxc library is called to start a program in a container using lxc_start().
> 
> We don't care about valgrind in the child process.  You can disable valgrind messages from child processes, but you cannot detach valgrind unless you exec() a new binary on top.  However, valgrind and lxc do not play nicely, at least with the versions in Ubuntu 12.04 LTS.   I'm getting an error back from lxc_start().  I'm having trouble getting logs to see why its failing, so I don't know exactly what's failing, yet.
> 
> But, I'm looking for any ideas for getting valgrind to work with programs that use lxc_start().
> Any suggestions will be welcome.  And, thanks!
> 
> 
> Regards.
> Mark K Vallevand
> "If there are no dogs in Heaven, then when I die I want to go where they went."
> -Will Rogers
> 
> THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY MATERIAL and is thus for use only by the intended recipient. If you received this in error, please contact the sender and delete the e-mail and its attachments from all computers.

> _______________________________________________
> lxc-users mailing list
> lxc...@li...
> http://lists.linuxcontainers.org/listinfo/lxc-users

_______________________________________________
lxc-users mailing list
lxc...@li...
http://lists.linuxcontainers.org/listinfo/lxc-users

Re: [Valgrind-users] Using valgrind with lxc

[John R. <jr...@Bi...>]

> Valgrind meet containers.
> 
> Containers meet valgrind.

Unless the container implementation has a way to "whitelist" some open fd
then the container mechanism is to blame for not providing functionality
that is reasonably required for debugging.

If the container mechanism does have such a "fd whitelist" then *you* should
figure out how valgrind can use it, and submit the patches (or documentation,
strategy, etc.) to valgrind.

Either way, please visit  https://bugs.kde.org/enter_bug.cgi?product=valgrind
and enter a report so that the issue does not get lost.  Specify which
container environment, etc.  Give enough details so that somebody else
can reproduce your observations starting "from scratch".

Then in the short run, the container mechanism probably has the attitude
"I provide an encapsulated, protected environment for running ["mature"] programs",
so you should run valgrind in an environment that is more friendly
to debugging.  [Get another x86_64 computer and run Linux on it.]

Re: [Valgrind-users] Using valgrind with lxc

[Tom H. <to...@co...>]

On 29/09/14 15:41, Vallevand, Mark K wrote:

> Our program is designed to close all open file descriptors in the child
> process before calling lxc_start().  That code can try to close all file
> descriptors to make sure something doesn’t sneak through.  However,
> closing the file descriptors associated with valgrind does not work.  I
> get errno=0 Bad File Descriptor.  Valgrind really has them held open.  I
> am running as root in all these tests.

Yes, we refuse to let them be closed because that would, for example, 
break logging as it would close our log stream.

We do however also lie when asked with getrlimit how many file 
descriptors there are, so lxc is obviously just guessing some high upper 
limit rather than actually asking what the limit is.

Tom

-- 
Tom Hughes (to...@co...)
http://compton.nu/

Re: [Valgrind-users] Using valgrind with lxc

[Vallevand, M. K <Mar...@UN...>]

Valgrind meet containers.
Containers meet valgrind.

I've found what lxc doesn't like when running valgrind.

The lxc_start() checks to see if there are extra file descriptors open and won't call __lxc_start().
vdr1: inherited fd 1024 on /home/vallevand/trunk_s4m/s4m-appliance/src/vdrd/vgVdrTest
vdr1: inherited fd 1025 on /tmp/valgrind_proc_24989_cmdline_4fbfb9a5 (deleted)VdrTest
vdr1: inherited fd 1026 on /dev/pts/1ind_proc_24989_cmdline_4fbfb9a5 (deleted)VdrTest
vdr1: inherited fd 1027 on pipe:[768863]_proc_24989_cmdline_4fbfb9a5 (deleted)VdrTest
vdr1: inherited fd 1028 on pipe:[768863]_proc_24989_cmdline_4fbfb9a5 (deleted)VdrTest

Vdr1 is the name of my container.  All those open files in the child process are related to valgrind.

If I call __lxc_start() rather than lxc_start(), I see this:
vdr1: sync wake failure : Broken pipe
vdr1: failed to spawn 'vdr1'
And, just before that there is some complaining from valgrind:
==25086== Syscall param clone(child_tidptr) contains uninitialised byte(s)
==25086==    at 0x56622E1: clone (clone.S:84)
==25086==    by 0x4E3BD38: __lxc_start (in /usr/lib/lxc/liblxc.so.0.7.5)
==25086==    by 0x4014C9: vgVdrStartClone (vgVdrTest.c:88)
==25086==    by 0x400F0A: main (vgVdrTest.c:337)
==25086==
==1== Syscall param wait4(status) points to unaddressable byte(s)
==1==    at 0x53607C4: wait (wait.c:32)
==1==    by 0x4E3A400: ??? (in /usr/lib/lxc/liblxc.so.0.7.5)
==1==    by 0x566231C: clone (clone.S:112)
==1==  Address 0xffffffffffffffd4 is not stack'd, malloc'd or (recently) free'd
==1==
==1== Invalid write of size 4
==1==    at 0x4E3A4FF: ??? (in /usr/lib/lxc/liblxc.so.0.7.5)
==1==    by 0x566231C: clone (clone.S:112)
==1==  Address 0xffffffffffffffc0 is not stack'd, malloc'd or (recently) free'd
==1==
==1==
==1== Process terminating with default action of signal 11 (SIGSEGV)
==1==  Access not within mapped region at address 0xFFFFFFFFFFFFFFC0
==1==    at 0x4E3A4FF: ??? (in /usr/lib/lxc/liblxc.so.0.7.5)
==1==    by 0x566231C: clone (clone.S:112)

Our program is designed to close all open file descriptors in the child process before calling lxc_start().  That code can try to close all file descriptors to make sure something doesn't sneak through.  However, closing the file descriptors associated with valgrind does not work.  I get errno=0 Bad File Descriptor.  Valgrind really has them held open.  I am running as root in all these tests.

I've also reproduced the problem using the 'lxc-' programs.  If you do something like 'lxc-create -n XXX' and then something like 'valgrind lxc-start -n XXX -- ls' you'll see it.  Well, the flavor of the error with open file descriptors.

My hopes aren't high, but any ideas are very welcome.

Regards.
Mark K Vallevand
"If there are no dogs in Heaven, then when I die I want to go where they went."
-Will Rogers

THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY MATERIAL and is thus for use only by the intended recipient. If you received this in error, please contact the sender and delete the e-mail and its attachments from all computers.
From: lxc-users [mailto:lxc...@li...] On Behalf Of Vallevand, Mark K
Sent: Thursday, September 25, 2014 09:19 AM
To: lxc...@li...
Subject: [lxc-users] Using valgrind with lxc

In our program, we do a fork() and in the child process the lxc library is called to start a program in a container using lxc_start().

We don't care about valgrind in the child process.  You can disable valgrind messages from child processes, but you cannot detach valgrind unless you exec() a new binary on top.  However, valgrind and lxc do not play nicely, at least with the versions in Ubuntu 12.04 LTS.   I'm getting an error back from lxc_start().  I'm having trouble getting logs to see why its failing, so I don't know exactly what's failing, yet.

But, I'm looking for any ideas for getting valgrind to work with programs that use lxc_start().
Any suggestions will be welcome.  And, thanks!


Regards.
Mark K Vallevand
"If there are no dogs in Heaven, then when I die I want to go where they went."
-Will Rogers

THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY MATERIAL and is thus for use only by the intended recipient. If you received this in error, please contact the sender and delete the e-mail and its attachments from all computers.

Re: [Valgrind-users] Valgrind 3.10.0 support for ICC

[Florian K. <fl...@ei...>]

On 27.09.2014 01:59, Gregory Czajkowski wrote:
> My experiences building with ICC..

I recommend you open a bugzilla for this if you want this to go
anywhere. Here: https://bugs.kde.org/enter_bug.cgi?product=valgrind

We do not have icc at our disposal for testing. So patches would be
needed as well.

   Florian

[Valgrind-users] Valgrind 3.10.0 support for ICC

[Gregory C. <gcf...@gm...>]

My experiences building with ICC..

#1 it failed out of the box with

checking for a supported version of gcc... no (13.1.3)
configure: error: please use gcc >= 3.0 or clang >= 2.9

I had to make some hacks in ./configure to support ICC

     notclang-13.*)
    { $as_echo "$as_me:${as_lineno-$LINENO}: result: ok (${gcc_version})"
>&5
$as_echo "ok (${gcc_version})" >&6; }
    ;;
notclang-14.*)
    { $as_echo "$as_me:${as_lineno-$LINENO}: result: ok (${gcc_version})"
>&5
$as_echo "ok (${gcc_version})" >&6; }
    ;;
notclang-14.*)
    { $as_echo "$as_me:${as_lineno-$LINENO}: result: ok (${gcc_version})"
>&5
$as_echo "ok (${gcc_version})" >&6; }
    ;;

#2 ICC needs additional libs linked in, but passing them in through LDFLAGS
was not working, as the link_tool_exe_linux wouldn't accept -L or
-Wl,-rpath for -l libs. Had to shoehorn static libs using make LIBS=libX.a

#3 Patrick's patch for missing PTRACE_GETSIGINFO was also applied since
building on SLES10/11

Final build command is
env CXX=/usr/pkgs/icc/13.1.3e/bin/icpc CC=/usr/pkgs/icc/13.1.3e/bin/icc
CFLAGS="-O3 -xHOST" ./configure && make clean && make
LIBS="/usr/pkgs/icc/13.1.3e/lib/intel64/libirc.a"  && make install

Will send feedback on how it runs. Best of luck on the release!

Re: [Valgrind-users] Unique log filename

[Eliot M. <mo...@cs...>]

On 9/26/2014 12:38 PM, Julian Seward wrote:
> On 09/25/2014 12:52 PM, Eliot Moss wrote:
>> I started updating the valgrind documentation to add description
>> of this new feature, and expect to submit a patch soon for
>> developer approval.
>
> https://bugs.kde.org/show_bug.cgi?id=339405
> is the bug, yes?

Yes, that's the "bug" notice with the patch to add this feature.

Regards -- Eliot

Re: [Valgrind-users] Wrapping function for strcpy

[Myoungkyu S. <mks...@gm...>]

Please see the followings. After posting my question at that moment, I
realized that I should specify the shared library name, because it's in
libc as you said. However, it didn't work using VG_Z_LIBC_SONAME.

Best regards,
Myoungkyu


====================================================================

mksong@mksong:testwrap$ valgrind --trace-redir=yes -v ./w_main
==5111== Memcheck, a memory error detector
==5111== Copyright (C) 2002-2013, and GNU GPL'd, by Julian Seward et al.
==5111== Using Valgrind-3.10.0 and LibVEX; rerun with -h for copyright info
==5111== Command: ./w_main
==5111==
--5111-- Valgrind options:
--5111--    --trace-redir=yes
--5111--    -v
--5111-- Contents of /proc/version:
--5111--   Linux version 3.13.0-35-generic (buildd@roseapple) (gcc version
4.8.2 (Ubuntu 4.8.2-19ubuntu1) ) #62-Ubuntu SMP Fri Aug 15 01:58:01 UTC 2014
--5111-- Arch and hwcaps: X86, LittleEndian, x86-mmxext-sse1-sse2
--5111-- Page sizes: currently 4096, max supported 4096
--5111-- Valgrind library directory: /usr/local/lib/valgrind
--5111-- <<
--5111--    ------ REDIR STATE after VG_(redir_initialise) ------
--5111--    TOPSPECS of soname (hardwired)
--5111--      ld-linux.so.2             strlen                         R->
(0000.0) 0x380696b2
--5111--      ld-linux.so.2             index                          R->
(0000.0) 0x3806968d
--5111--    ------ ACTIVE ------
--5111-- >>
--5111-- Reading syms from /lib/i386-linux-gnu/ld-2.19.so
--5111--    svma 0x0000000860, avma 0x0004000860
--5111--   Considering /lib/i386-linux-gnu/ld-2.19.so ..
--5111--   .. CRC mismatch (computed 19686c0d wanted 131a893d)
--5111--   Considering /usr/lib/debug/lib/i386-linux-gnu/ld-2.19.so ..
--5111--   .. CRC is valid
--5111-- <<
--5111--    ------ REDIR STATE after VG_(redir_notify_new_DebugInfo) ------
--5111--    TOPSPECS of soname ld-linux.so.2 filename /lib/i386-linux-gnu/
ld-2.19.so
--5111--    TOPSPECS of soname (hardwired)
--5111--      ld-linux.so.2             strlen                         R->
(0000.0) 0x380696b2
--5111--      ld-linux.so.2             index                          R->
(0000.0) 0x3806968d
--5111--    ------ ACTIVE ------
--5111--     0x04017ce0 (index               ) R-> (0000.0) 0x3806968d ???
--5111--     0x04017ed0 (strlen              ) R-> (0000.0) 0x380696b2 ???
--5111-- >>
--5111-- Reading syms from
/home/mksong/workspace/.../valgrind_ubuntu14.04/valgrind-3.10.0/testwrap/w_main
--5111--    svma 0x00080483a0, avma 0x00080483a0

valgrind: m_demangle/demangle.c:231 (vgPlain_maybe_Z_demangle): the
'impossible' happened.
valgrind: symbol with a 'VG_Z_' prefix: _vgw00000ZU_VG_Z_LIBC_SONAME_strcpy.
see pub_tool_redir.h for an explanation.

host stacktrace:
==5111==    at 0x3804E604: ??? (in
/usr/local/lib/valgrind/memcheck-x86-linux)

sched status:
  running_tid=0


Note: see also the FAQ in the source distribution.
It contains workarounds to several common problems.
In particular, if Valgrind aborted or crashed after
identifying problems in your program, there's a good chance
that fixing those problems will prevent Valgrind aborting or
crashing, especially if it happened in m_mallocfree.c.

If that doesn't help, please report this bug to: www.valgrind.org

In the bug report, send all the above text, the valgrind
version, and what OS and version you are using.  Thanks.

====================================================================

On Fri, Sep 26, 2014 at 11:22 AM, Julian Seward <js...@ac...> wrote:

> On 09/23/2014 03:31 AM, Myoungkyu Song wrote:
> > I have a question, which maybe was discussed.  I would like to implement
> a
> > wrapper function for standard API such as "strcpy".  However, I failed to
> > do.  When I tested a user-defined function like "hello(char *, char *)"
> > below, I successfully wrapped it, accessing to arguments and a return
> > value.
>
> The problem is here
>
> > char* I_WRAP_SONAME_FNNAME_ZU(NONE,strcpy) ( char *dest, const char *src
> )
>
> By using "(NONE,strcpy)" you are requesting to wrap the function strcpy in
> the main executable (that's what "NONE") means.  But strcpy lives in
> libc.so.  Really you need to use VG_Z_LIBC_SONAME (with a suitable
> definition for VG_Z_LIBC_SONAME) to make it work.  Unfortunately the
> definition of VG_Z_LIBC_SONAME is system-dependent.
>
> You should be able to find all the examples you need in
> shared/vg_replace_strmem.c
>
> Note also, using -v is very helpful for debugging wrapping/intercept
> problems.  If you need complete details, also try --trace-redir=yes.
>
> J
>
>
>
>

Re: [Valgrind-users] Unique log filename

[Julian S. <js...@ac...>]

On 09/25/2014 12:52 PM, Eliot Moss wrote:
> I started updating the valgrind documentation to add description
> of this new feature, and expect to submit a patch soon for
> developer approval.

https://bugs.kde.org/show_bug.cgi?id=339405
is the bug, yes?

J

Re: [Valgrind-users] Problems with valgrind after a fork() and starting a container

[Julian S. <js...@ac...>]

Yes, if you get some details on how/why it fails, that would
be good.  Also, filing a bug in bugzilla
(see http://www.valgrind.org/support/bug_reports.html)
will ensure your bug report doesn't get lost later on.

J



On 09/25/2014 02:58 PM, Vallevand, Mark K wrote:
> I tried that option.  Doesn’t help.
> I was afraid that it would be what Tom said.  [Theatrical sigh]
> I have a couple of choices, I guess.  Find out why valgrind and lxc aren’t working together and fix that.  Or, do some kind of exec() outside of lxc.
> The lxc_start() that is being called is a kind of exec(), I guess.  It creates a new set of namespaces and does a clone() and exec() in them.  That is where is it failing.  I’m trying to get a log file with more details.  There might be a chance to figure this out.
> 
> Regards.
> Mark K Vallevand
> "If there are no dogs in Heaven, then when I die I want to go where they went."
> -Will Rogers
> 
> THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY MATERIAL and is thus for use only by the intended recipient. If you received this in error, please contact the sender and delete the e-mail and its attachments from all computers.
> From: Alan Copy [mailto:ala...@gm...]
> Sent: Thursday, September 25, 2014 06:51 AM
> To: Tom Hughes
> Cc: Vallevand, Mark K; val...@li...
> Subject: Re: [Valgrind-users] Problems with valgrind after a fork() and starting a container
> 
> hi,
> 
> Tom is right you can detach if you don't use exec but i think you can silent child output using --child-silent-after-fork=no
> Alan
> 
> 2014-09-24 23:45 GMT+02:00 Tom Hughes <to...@co...<mailto:to...@co...>>:
> On 24/09/14 22:04, Vallevand, Mark K wrote:
> 
>> We don’t care about valgrind in the child process.  We need to get the
>> child to detach from valgrind before it calls the lxc library.
>>
>> So, how can this be done?
> 
> It can't - valgrind is a fundamental part of the process and the only
> way to get rid of it is to exec into a different binary.
> 
> Tom
> 
> --
> Tom Hughes (to...@co...<mailto:to...@co...>)
> http://compton.nu/
> 
> ------------------------------------------------------------------------------
> Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer
> Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports
> Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper
> Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer
> http://pubads.g.doubleclick.net/gampad/clk?id=154622311&iu=/4140/ostg.clktrk
> _______________________________________________
> Valgrind-users mailing list
> Val...@li...<mailto:Val...@li...>
> https://lists.sourceforge.net/lists/listinfo/valgrind-users
> 
> 
> 
> ------------------------------------------------------------------------------
> Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer
> Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports
> Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper
> Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer
> http://pubads.g.doubleclick.net/gampad/clk?id=154622311&iu=/4140/ostg.clktrk
> 
> 
> 
> _______________________________________________
> Valgrind-users mailing list
> Val...@li...
> https://lists.sourceforge.net/lists/listinfo/valgrind-users
> 

Re: [Valgrind-users] valgrind run error , help me, thx

[Julian S. <js...@ac...>]

That's a bit strange.  Can you please try with the recently released
3.10.0 version, and see if you still have the problem?

Thanks.

J


On 09/25/2014 01:41 PM, lchquan wrote:
> # /opt/vg/bin/valgrind ls
> ==5290== Memcheck, a memory error detector
> ==5290== Copyright (C) 2002-2013, and GNU GPL'd, by Julian Seward et al.
> ==5290== Using Valgrind-3.9.0 and LibVEX; rerun with -h for copyright info
> ==5290== Command: ls
> ==5290== 
> ==5290== 
> ==5290== Process terminating with default action of signal 4 (SIGILL)
> ==5290==  Illegal opcode at address 0x3808AE70
> ==5290==    at 0x4000E50: _start (in /lib/ld-uClibc-0.9.32.1.so)
>  valgrind: m_scheduler/scheduler.c:957 (run_thread_for_a_while): Assertion 'done_this_time >= 0' failed.
> ==5290==    at 0x38039528: report_and_quit (m_libcassert.c:260)
> ==5290==    by 0xE08F4003: ???
>  sched status:
>   running_tid=1
>  Thread 1: status = VgTs_Runnable
> ==5290==    at 0x4000E50: _start (in /lib/ld-uClibc-0.9.32.1.so)
>  
> Note: see also the FAQ in the source distribution.
> It contains workarounds to several common problems.
> In particular, if Valgrind aborted or crashed after
> identifying problems in your program, there's a good chance
> that fixing those problems will prevent Valgrind aborting or
> crashing, especially if it happened in m_mallocfree.c.
>  If that doesn't help, please report this bug to: www.valgrind.org
>  In the bug report, send all the above text, the valgrind
> version, and what OS and version you are using.  Thanks.
>  # cat /proc/cpu
> /proc/cpu/     /proc/cpuinfo
> # cat /proc/cpuinfo 
> Processor       : ARMv7 Processor rev 1 (v7l)
> processor       : 0
> BogoMIPS        : 1987.37
>  processor       : 1
> BogoMIPS        : 1993.93
>  Features        : swp half thumb fastmult edsp tls 
> CPU implementer : 0x41
> CPU architecture: 7
> CPU variant     : 0x4
> CPU part        : 0xc09
> CPU revision    : 1
>  Hardware        : hi3535
> Revision        : 0000
> Serial          : 0000000000000000
>  # uname -a  
> Linux (none) 3.4.35_hi3535 #4 SMP Tue Jul 22 11:14:11 CST 2014 armv7l GNU/Linux
>  # /opt/vg/bin/valgrind --version
> valgrind-3.9.0
> 
>  what's wrong with me?
> 
> 
> 
> ------------------------------------------------------------------------------
> Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer
> Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports
> Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper
> Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer
> http://pubads.g.doubleclick.net/gampad/clk?id=154622311&iu=/4140/ostg.clktrk
> 
> 
> 
> _______________________________________________
> Valgrind-users mailing list
> Val...@li...
> https://lists.sourceforge.net/lists/listinfo/valgrind-users
> 

Re: [Valgrind-users] Valgrind and glibc's CPU detection

[Julian S. <js...@ac...>]

You need to say what CPU this is on.  For x86_64 I think this is
impossible, because all x86_64 processors support at least SSE2.

For x86 (32 bit) this might just be possible.  In VEX/priv/guest_x86_toIR.c,
find the code that handles CPUID

      case 0xA2: { /* CPUID */

and change it so that it uses this case

         if (archinfo->hwcaps == 0/*no SSE*/) {
            fName = "x86g_dirtyhelper_CPUID_sse0";
            fAddr = &x86g_dirtyhelper_CPUID_sse0;
         } else

J


On 09/23/2014 11:44 AM, Konstantin Tokarev wrote:
> Hi all,
> 
> I'd like to prevent glibc from using any SIMD-optimized functions when running 
> application under Valgrind on Linux. Is it possible to do now?
> AFAIU, glibc uses runtime CPU detection, and Valgrind runs code on emulated CPU.
> 

Re: [Valgrind-users] valgrind-3.10 does not link on

[Julian S. <js...@ac...>]

Er, this isn't good.  Can you file a bug report
as described at http://www.valgrind.org/support/bug_reports.html
so that this gets tracked properly?  If it just remains on the mailing
list it is likely to get forgotten.

Thanks.

J


On 09/18/2014 10:09 AM, Matthias Apitz wrote:
> 
> Hello,
> 
> This is on a Linux host running:
> 
> valgrind-3.10.0> uname -a
> Linux SRAP03DXOH 2.6.5-7.191-bigsmp #1 SMP Tue Jun 28 14:58:56 UTC 2005 i686 athlon i386 GNU/Linux
> 
> valgrind-3.10.0> CFLAGS="-DPTRACE_GETSIGINFO=0x4202" export CFLAGS
> valgrind-3.10.0> ./configure
> valgrind-3.10.0> gmake
> ...
> 
> mv -f .deps/memcheck_x86_linux-mc_errors.Tpo .deps/memcheck_x86_linux-mc_errors.Po
> ../coregrind/link_tool_exe_linux 0x38000000 gcc  -Wno-long-long -DPTRACE_GETSIGINFO=0x4202   -o memcheck-x86-linux -m32 -mpreferred-stack-boundary=2 -O2 -g -Wall -Wmissing-prototypes -Wshadow -Wpointer-arith -Wstrict-prototypes -Wmissing-declarations -Wno-format-zero-length -fno-strict-aliasing -fno-builtin -fomit-frame-pointer -O2 -static -nodefaultlibs -nostartfiles -u _start  -m32 memcheck_x86_linux-mc_leakcheck.o memcheck_x86_linux-mc_malloc_wrappers.o memcheck_x86_linux-mc_main.o memcheck_x86_linux-mc_translate.o memcheck_x86_linux-mc_machine.o memcheck_x86_linux-mc_errors.o ../coregrind/libcoregrind-x86-linux.a ../VEX/libvex-x86-linux.a -lgcc 
> ../coregrind/libcoregrind-x86-linux.a(libcoregrind_x86_linux_a-syswrap-linux.o)(.text+0x14bba): In function `vgSysWrap_linux_sys_ioctl_after':
> m_syswrap/syswrap-linux.c:8476: undefined reference to `__builtin_popcountll'
> ../coregrind/libcoregrind-x86-linux.a(libcoregrind_x86_linux_a-syswrap-linux.o)(.text+0x1ddcb): In function `vgSysWrap_linux_sys_ioctl_before':
> m_syswrap/syswrap-linux.c:5748: undefined reference to `__builtin_popcountll'
> collect2: ld returned 1 exit status
> gmake[3]: *** [memcheck-x86-linux] Error 1
> gmake[3]: Leaving directory `/home/guru/v43/sisis-pap/src/valgrind/valgrind-3.10.0/memcheck'
> gmake[2]: *** [all-recursive] Error 1
> gmake[2]: Leaving directory `/home/guru/v43/sisis-pap/src/valgrind/valgrind-3.10.0/memcheck'
> gmake[1]: *** [all-recursive] Error 1
> gmake[1]: Leaving directory `/home/guru/v43/sisis-pap/src/valgrind/valgrind-3.10.0'
> gmake: *** [all] Error 2
> 
> Vy 73
> 
>          matthias
> 

Re: [Valgrind-users] Wrapping function for strcpy

[Julian S. <js...@ac...>]

On 09/23/2014 03:31 AM, Myoungkyu Song wrote:
> I have a question, which maybe was discussed.  I would like to implement a
> wrapper function for standard API such as "strcpy".  However, I failed to
> do.  When I tested a user-defined function like "hello(char *, char *)"
> below, I successfully wrapped it, accessing to arguments and a return
> value.

The problem is here

> char* I_WRAP_SONAME_FNNAME_ZU(NONE,strcpy) ( char *dest, const char *src )

By using "(NONE,strcpy)" you are requesting to wrap the function strcpy in
the main executable (that's what "NONE") means.  But strcpy lives in
libc.so.  Really you need to use VG_Z_LIBC_SONAME (with a suitable
definition for VG_Z_LIBC_SONAME) to make it work.  Unfortunately the
definition of VG_Z_LIBC_SONAME is system-dependent.

You should be able to find all the examples you need in
shared/vg_replace_strmem.c

Note also, using -v is very helpful for debugging wrapping/intercept
problems.  If you need complete details, also try --trace-redir=yes.

J

[Valgrind-users] callgrind: jcnd=<followed_count>/<total_count>

[John C. <joh...@ta...>]

So I got that specification for the callgrind jcnd= line from....

http://valgrind.10908.n7.nabble.com/The-syntax-of-jump-and-jcnd-in-callgrind-profile-files-td51025.html#a51026

I would assume then that
    followed_count <= total_count
would always be true.

This one liner....

find -name '*.callgrind' | xargs grep jcnd | ruby -nle 'p [$1, $2,$_] if
($_ =~ /jcnd=([0-9]+)\/([0-9]+)/) && ($1.to_i > $2.to_i)'

...finds thousands of counterexamples, and if I swap '>'  to '<'.... I find
thousands of examples again.

So I have concluded I don't understand what followed_count and total_count
mean.

What do they mean?

-- 
John Carter
Phone : (64)(3) 358 6639
Tait Electronics
PO Box 1645 Christchurch
New Zealand

-- 

------------------------------
This email, including any attachments, is only for the intended recipient. 
It is subject to copyright, is confidential and may be the subject of legal 
or other privilege, none of which is waived or lost by reason of this 
transmission.
If you are not an intended recipient, you may not use, disseminate, 
distribute or reproduce such email, any attachments, or any part thereof. 
If you have received a message in error, please notify the sender 
immediately and erase all copies of the message and any attachments.
Unfortunately, we cannot warrant that the email has not been altered or 
corrupted during transmission nor can we guarantee that any email or any 
attachments are free from computer viruses or other conditions which may 
damage or interfere with recipient data, hardware or software. The 
recipient relies upon its own procedures and assumes all risk of use and of 
opening any attachments.
------------------------------

Re: [Valgrind-users] valgrind run error , help me, thx

[John R. <jr...@Bi...>]

> ==5290== Process terminating with default action of signal 4 (SIGILL)
> ==5290==  Illegal opcode at address 0x3808AE70
> ==5290==    at 0x4000E50: _start (in /lib/ld-uClibc-0.9.32.1.so)

> # cat /proc/cpuinfo
> Processor       : ARMv7 Processor rev 1 (v7l)
> processor       : 0
> BogoMIPS        : 1987.37
> processor       : 1
> BogoMIPS        : 1993.93
> Features        : swp half thumb fastmult edsp tls

This smells like valgrind was built (compiled) for some other ARM architecture,
but installed on this box.  Or, it could be a bug the code which
valgrind uses to determine the current CPU architecture.

Find out what instruction (the four bytes) is at 0x3808AE70,
and tell is in hex and disassembled (use gdb).
That address is inside one of the valgrind tools itself.
On x86_64 it would be /usr/lib64/valgrind/memcheck-amd64-linux
so look for /usr/lib/valgrind/memcheck-arm*-linux or similar.
Then run gdb on that file, and say:
   x/x 0x3808AE70
   x/i 0x3808AE70
   q

-- 

Re: [Valgrind-users] Unique log filename

[Eliot M. <mo...@cs...>]

On 9/25/2014 5:45 AM, Skarakis, Konstantinos wrote:
> That's fantastic. Thank you very much for your time. It works great.
>
> Here's how I am using it:
>
> I have this line in my ~/.valgrindrc:
>
> --log-file=/software/valgrind/rpts/%s{"/software/dstring"}-%p-report.txt
>
> And these are the contents of /software/dstring:
>
> echo $(ps -f $PPID | tail -n 1 | awk "{print \$10}")-$(date +%Y%m%d%H%M%S%N)
>
> This results in this very nice log:
>
> $ valgrind ls
> cap.cap  cov  covfsn  md5r  rpts  rpts1  rpts_fsn_errors
>
> $ ls /software/valgrind/rpts
> ls-20140925123940975544578-18453-report.txt
>
>
> Kind Regards,
> Costas

You're welcome!  The use case that prompted me to add the feature was
using lackey to generate full memory access traces from a benchmark that
invoked subprocesses.  The traces are very large, and so I compress them
by piping lackey output to gzip.  This is easy to express for a single
process on the command line, but for dynamically generated subprocesses
I needed to construct a fifo, with gzip on the other end, and return
the path name of the fifo for valgrind to open.  As in your case, worked
great.

Cheers -- E

Re: [Valgrind-users] Problems with valgrind after a fork() and starting a container

[Vallevand, M. K <Mar...@UN...>]

I tried that option.  Doesn’t help.
I was afraid that it would be what Tom said.  [Theatrical sigh]
I have a couple of choices, I guess.  Find out why valgrind and lxc aren’t working together and fix that.  Or, do some kind of exec() outside of lxc.
The lxc_start() that is being called is a kind of exec(), I guess.  It creates a new set of namespaces and does a clone() and exec() in them.  That is where is it failing.  I’m trying to get a log file with more details.  There might be a chance to figure this out.

Regards.
Mark K Vallevand
"If there are no dogs in Heaven, then when I die I want to go where they went."
-Will Rogers

THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY MATERIAL and is thus for use only by the intended recipient. If you received this in error, please contact the sender and delete the e-mail and its attachments from all computers.
From: Alan Copy [mailto:ala...@gm...]
Sent: Thursday, September 25, 2014 06:51 AM
To: Tom Hughes
Cc: Vallevand, Mark K; val...@li...
Subject: Re: [Valgrind-users] Problems with valgrind after a fork() and starting a container

hi,

Tom is right you can detach if you don't use exec but i think you can silent child output using --child-silent-after-fork=no
Alan

2014-09-24 23:45 GMT+02:00 Tom Hughes <to...@co...<mailto:to...@co...>>:
On 24/09/14 22:04, Vallevand, Mark K wrote:

> We don’t care about valgrind in the child process.  We need to get the
> child to detach from valgrind before it calls the lxc library.
>
> So, how can this be done?

It can't - valgrind is a fundamental part of the process and the only
way to get rid of it is to exec into a different binary.

Tom

--
Tom Hughes (to...@co...<mailto:to...@co...>)
http://compton.nu/

------------------------------------------------------------------------------
Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer
Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports
Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper
Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer
http://pubads.g.doubleclick.net/gampad/clk?id=154622311&iu=/4140/ostg.clktrk
_______________________________________________
Valgrind-users mailing list
Val...@li...<mailto:Val...@li...>
https://lists.sourceforge.net/lists/listinfo/valgrind-users

Re: [Valgrind-users] Problems with valgrind after a fork() and starting a container

[Alan C. <ala...@gm...>]

hi,

Tom is right you can detach if you don't use exec but i think you can
silent child output using --child-silent-after-fork=no

Alan

2014-09-24 23:45 GMT+02:00 Tom Hughes <to...@co...>:

> On 24/09/14 22:04, Vallevand, Mark K wrote:
>
> > We don’t care about valgrind in the child process.  We need to get the
> > child to detach from valgrind before it calls the lxc library.
> >
> > So, how can this be done?
>
> It can't - valgrind is a fundamental part of the process and the only
> way to get rid of it is to exec into a different binary.
>
> Tom
>
> --
> Tom Hughes (to...@co...)
> http://compton.nu/
>
>
> ------------------------------------------------------------------------------
> Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer
> Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports
> Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper
> Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer
>
> http://pubads.g.doubleclick.net/gampad/clk?id=154622311&iu=/4140/ostg.clktrk
> _______________________________________________
> Valgrind-users mailing list
> Val...@li...
> https://lists.sourceforge.net/lists/listinfo/valgrind-users
>

[Valgrind-users] valgrind run error , help me, thx

[l. <238...@qq...>]

# /opt/vg/bin/valgrind ls
==5290== Memcheck, a memory error detector
==5290== Copyright (C) 2002-2013, and GNU GPL'd, by Julian Seward et al.
==5290== Using Valgrind-3.9.0 and LibVEX; rerun with -h for copyright info
==5290== Command: ls
==5290== 
==5290== 
==5290== Process terminating with default action of signal 4 (SIGILL)
==5290==  Illegal opcode at address 0x3808AE70
==5290==    at 0x4000E50: _start (in /lib/ld-uClibc-0.9.32.1.so)
 valgrind: m_scheduler/scheduler.c:957 (run_thread_for_a_while): Assertion 'done_this_time >= 0' failed.
==5290==    at 0x38039528: report_and_quit (m_libcassert.c:260)
==5290==    by 0xE08F4003: ???
 sched status:
  running_tid=1
 Thread 1: status = VgTs_Runnable
==5290==    at 0x4000E50: _start (in /lib/ld-uClibc-0.9.32.1.so)
 
Note: see also the FAQ in the source distribution.
It contains workarounds to several common problems.
In particular, if Valgrind aborted or crashed after
identifying problems in your program, there's a good chance
that fixing those problems will prevent Valgrind aborting or
crashing, especially if it happened in m_mallocfree.c.
 If that doesn't help, please report this bug to: www.valgrind.org
 In the bug report, send all the above text, the valgrind
version, and what OS and version you are using.  Thanks.
 # cat /proc/cpu
/proc/cpu/     /proc/cpuinfo
# cat /proc/cpuinfo 
Processor       : ARMv7 Processor rev 1 (v7l)
processor       : 0
BogoMIPS        : 1987.37
 processor       : 1
BogoMIPS        : 1993.93
 Features        : swp half thumb fastmult edsp tls 
CPU implementer : 0x41
CPU architecture: 7
CPU variant     : 0x4
CPU part        : 0xc09
CPU revision    : 1
 Hardware        : hi3535
Revision        : 0000
Serial          : 0000000000000000
 # uname -a  
Linux (none) 3.4.35_hi3535 #4 SMP Tue Jul 22 11:14:11 CST 2014 armv7l GNU/Linux
 # /opt/vg/bin/valgrind --version
valgrind-3.9.0

 what's wrong with me?