valgrind-users — General discussion list for Valgrind users

[Valgrind-users] Valgrind apparently looping after long test run

[Tim B. <ti...@va...>]

I'm using Valgrind 3.8.1 to run fuzzing tests on control software for an
embedded system. The tests are run on

Linux pod 3.11.4-201.fc19.x86_64 #1 SMP Thu Oct 10 14:11:18 UTC 2013
x86_64 x86_64 x86_64 GNU/Linux

Valgrind itself is the standard Fedora 19 build with the following
arguments:

valgrind	-v --leak-check=full
		--leak-resolution=high
		--show-possibly-lost=yes
		--track-fds=yes
		--num-callers=24
		--vgdb=no

Normally all this works fine, but last night I did an overnight run on a
new dataset and after about eight hours valgrind started looping. I
wasn't sure what to do about that... there were no diagnostics either
from my software or from valgrind. When I attached to the program with
strace I got this endless series:

clock_gettime(CLOCK_MONOTONIC, {124051, 458677331}) = 0
rt_sigprocmask(SIG_SETMASK, ~[], ~[ILL TRAP BUS FPE KILL SEGV STOP], 8) = 0
rt_sigtimedwait([HUP INT ILL BUS FPE KILL SEGV TERM STOP WINCH SYS RTMIN
RT_1], 0x4028a5e30, {0, 0}, 8) = -1 EAGAIN (Resource temporarily
unavailable)
rt_sigprocmask(SIG_SETMASK, ~[ILL TRAP BUS FPE KILL SEGV STOP], NULL, 8) = 0
gettid()                                = 30464
gettid()                                = 30464
write(1029, "A", 1)                     = 1
gettid()                                = 30464
read(1028, "A", 1)                      = 1
gettid()                                = 30464
clock_gettime(CLOCK_MONOTONIC, {124051, 469072047}) = 0
rt_sigprocmask(SIG_SETMASK, ~[], ~[ILL TRAP BUS FPE KILL SEGV STOP], 8) = 0
rt_sigtimedwait([HUP INT ILL BUS FPE KILL SEGV TERM STOP WINCH SYS RTMIN
RT_1], 0x4028a5e30, {0, 0}, 8) = -1 EAGAIN (Resource temporarily
unavailable)
rt_sigprocmask(SIG_SETMASK, ~[ILL TRAP BUS FPE KILL SEGV STOP], NULL, 8) = 0
gettid()                                = 30464
gettid()                                = 30464
write(1029, "B", 1)                     = 1
gettid()                                = 30464
read(1028, "B", 1)                      = 1
gettid()

It loops through the English alphabet, one letter at a time, uppercase A
to uppercase Z, and then repeats. TID 30464 is the PID of the valgrind
process. File descriptors 1028 and 1029 appear to be the opposite ends
of a pipe, but I have no idea why the alphabet would be cycling through
it. The sigtimedwait() call is polling for one of those signals and not
getting it. We have no such calls explicitly in our code, and no RT
calls at all, which leads me to think this is valgrind's internal code,
but of course it could still be measuring something within the main program.

I ran gstack on it but got only:

gstack 30464
#0  0x0000000038033cb0 in vgMemCheck_helperc_LOADV64le ()
#1  0x0000000403290318 in ?? ()
#2  0x00000004028a5f00 in ?? ()
#3  0x0000000000000000 in ?? ()

which doesn't tell me a whole lot, and I don't find vgMemCheck_helperc
anywhere in the code, so I guess it's something synthesized at compile time.

My test is scripted so I can re-run it easily (given time), but could
use some pointers on how to approach this and get more information. I
imagine that rebuilding valgrind with -g might help with gstack, but is
there a way I can signal or stop Valgrind and have it display a stack
trace? It looks like SIGINT is blocked, and sending TERM merely stops
the process and I get nothing.

Thanks for any pointers!

Tim

[Valgrind-users] CFP Valgrind developer room at FOSDEM 2014 (Brussels, Belgium, 2 February)

[Mark W. <mj...@re...>]

Valgrind developer room at FOSDEM 2014 (Brussels, Belgium, 2 February).

FOSDEM is a free software event that offers open source communities a
place to meet, share ideas and collaborate. It is renowned for being
highly developer-oriented and brings together 5000+ hackers from all
over the world. Taking place in the city of Brussels (Belgium).
http://fosdem.org/

FOSDEM 2014 will take place during the weekend of Saturday, February 1st
and Sunday, February 2nd. On Sunday we will have a devroom for Valgrind.
Devrooms are a place for development teams to meet, discuss, hack and
publicly present the project latest improvements and future directions. 

We will have a whole day to hang out together as Valgrind community.
Please join us whether you are a Valgrind core hacker, Valgrind tool
hacker, Valgrind user, Valgrind packager or hacker on a project that
integrates, extends or complements Valgrind.

Call For Participation

We would like to organize a series of talks/discussions on various
topics relevant to both core hackers, new developers, users, packagers
and cross project functionality. Please do submit a talk proposal before
Sunday December 8th 2013, so we can make a list of activities during the
day.

Some possible topics for talks/discussions are:

- The recently added functional changes (for valgrind users).

- State of the valgrind code base (core hackers).

- Helgrind - basic design, problems and opportunities (core and tools).

- Get feedback on what what kinds of new functionality would
  be useful. Which tools users would like to see and/or which new
  features for the existing tools. (valgrind developers and users).

  - Modify memcheck to report the last leaked pointer to a block
    integrate "omega" as a memcheck option or omega as a separate tool.

  - Better support compiled and JITted code.
    allowing the JIT compiler to indicate the link between
    the JITted code and the source code.

  - Valgrind and transactional memory.

- How to add simple features (adding syscalls for a platform or VEX
  instructions for a architecture port). (new core developers).

- Making Valgrind really multi-threaded, parallelising Memcheck
  parallelising the rest of the framework, and tools (for core hackers).

- Should we continue to support MacOS? What about Valgrind on
  MS-Windows? Solaris? (attracting new hackers).

- Redo the JIT framework to reduce baseline overheads? (core hackers).

- Make Callgrind work sanely on ARM (core hackers).

- Discuss release/bugfixing strategy/policy (core hackers, packagers).

- Packaging valgrind for distros, handling patches, suppressions, etc.
  (packagers).

- Valgrind/GDB integration (cross project).

- Valgrind vs the compiler. Compilers like GCC and clang now have
  "valgrind like" features -fsanitize=address|thread|undefined.
  How does valgrind complement or improve on these features?

- Eclipse and other visualisation tools for valgrind (cross project).

- Practical examples of using Valgrind in (big) systems automatic
  regression testing (users).

Use the FOSDEM 'pentabarf' tool to submit your proposal.
https://penta.fosdem.org/submission/FOSDEM14/

- If necessary, create a Pentabarf account and activate it.

- In the "Person" section, provide First name, Last name
  (in the "General" tab), Email (in the "Contact" tab)
  and Bio ("Abstract" field in the "Description" tab).

- Submit a proposal by clicking on "Create event".

- Important! Select the "Valgrind devroom" track
  (on the "General" tab).

- Provide the title of your talk ("Event title" in the "General" tab).

- Provide a description of the subject of the talk and the
  intended audience (in the "Abstract" field of the "Description" tab)

- Provide a rough outline of the talk or goals of the session (a short
  list of bullet points covering topics that will be discussed) in the
  "Full description" field in the "Description" tab

Julian, Philippe and Mark will review the proposals and organize the
schedule for the day. Please feel free to suggest or discuss any ideas
for the devroom on the Valgrind developer mailinglist before creating a
proposal: val...@li...

Call For (Video) Volunteers

The FOSDEM organization can provide us with equipment to record some or
all of the talks in our devroom. But we need at least two volunteers to
do the actual recordings. An ideal candidate for this job would be
someone who is going to be watching talks in the Valgrind devroom most
(or all) of the time anyway, and who doesn't mind watching after a
camera and/or an audio mixer while watching the talk.

While some A/V experience is obviously useful for the volunteer, it is
absolutely not required; FOSDEM will provide the right gear and help set
it up, and FOSDEM organizers will also provide enough information so the
volunteers know what to do. This will include a live training session
during the opening talk (in Janson) for those who want it.

If you want to help record talks/discussions in the Valgrind devroom
please let us know before the end of November.

Important dates:

  Video Volunteers:                       Before 30 Nov 2013
  Talk/Discussion Submission deadline:    Sunday  8 Dec 2013
  Devroom Schedule announcement:          Sunday 15 Dec 2013
  Devroom day:                            Sunday  2 Feb 2014

Hope to see you all at FOSDEM 2014 in the Valgrind devroom.
Brussels (Belgium), Sunday 2 February, 2014.
https://fosdem.org/2014/schedule/track/valgrind/

Re: [Valgrind-users] Is it possible to use valgrind for i386-x86_64 translation?

[Philippe W. <phi...@sk...>]

On Tue, 2013-10-22 at 05:59 +0800, Lu Mitnick wrote:
> Hello Philippe,
> 
> 
> Thanks your reply. Is it means that the option of host and target
> should be the same when we configured?
Yes, currently configuring valgrind to run on one arch, but execute a
program from another arch is not supported.

Philippe

Re: [Valgrind-users] valgrind on macosx 10.8 and 10.9

[Philippe W. <phi...@sk...>]

On Tue, 2013-10-22 at 09:00 -0700, Robert Henry wrote:
> I upgraded my macosx machine from 10.7 to 10.8, and only then
> discovered that there's very limited support in valgrind for 10.8
> (never mind the about to be released 10.9).
> 
> 
> Are there any forks of the code base that supports macosx 10.8 +
> valgrind more completely?
Some support for 10.8 has been added by Julian in the SVN version
(which will soon be released as 3.9.0).
So, now is the good time to try it :).

> 
> 
> What are the technical issues with running 10.8 + valgrind?
IIRC, it reasonably works in 64 bits, but not so good on 32 bits.
The best is to test the SVN version, and report problems.

Philippe

[Valgrind-users] valgrind on macosx 10.8 and 10.9

[Robert H. <rr...@ne...>]

I upgraded my macosx machine from 10.7 to 10.8, and only then discovered
that there's very limited support in valgrind for 10.8 (never mind the
about to be released 10.9).

Are there any forks of the code base that supports macosx 10.8 + valgrind
more completely?

What are the technical issues with running 10.8 + valgrind?

-- 
Robert Henry, New Relic

Re: [Valgrind-users] Is it possible to use valgrind for i386-x86_64 translation?

[Lu M. <kin...@gm...>]

Hello Philippe,

Thanks your reply. Is it means that the option of host and target should be
the same when we configured?

Thanks a lot

Re: [Valgrind-users] Is it possible to use valgrind for i386-x86_64 translation?

[Philippe W. <phi...@sk...>]

On Tue, 2013-10-22 at 05:23 +0800, Lu Mitnick wrote:
> Hello all,
> 
> 
> none-x86-linux could be used as a binary translator, which generate
> i386 binary with input of i386 executable. On the other hand,
> none-amd64-linux  could be used for amd64-amd64 translation. I am
> wondering whether it is possible to use valgrind for i386-x86_64
> translation, which means the input is i386 executable and generate
> x86_64 binary in code cache.
In theory yes. In practice, I think it will imply a significant
effort to get this working.

Philippe

[Valgrind-users] Is it possible to use valgrind for i386-x86_64 translation?

[Lu M. <kin...@gm...>]

Hello all,

none-x86-linux could be used as a binary translator, which generate i386
binary with input of i386 executable. On the other hand, none-amd64-linux
 could be used for amd64-amd64 translation. I am wondering whether it is
possible to use valgrind for i386-x86_64 translation, which means the input
is i386 executable and generate x86_64 binary in code cache.

Thanks a lot.

Re: [Valgrind-users] valgrind error on fedora 19 AMD64

[Jerry B. <je...@ge...>]

Mark,
Looks good on this end.
Thanks.
Jerry

valgrind]$ ll /usr/bin/valgrind
-rwxr-xr-x 1 root root 54427 Oct 17 01:04 /usr/bin/valgrind

 valgrind]$ valgrind ls -l
==4957== Memcheck, a memory error detector
==4957== Copyright (C) 2002-2012, and GNU GPL'd, by Julian Seward et al.
==4957== Using Valgrind-3.9.0.SVN and LibVEX; rerun with -h for copyright
info
==4957== Command: ls -l
==4957==
total 1712
-rw-r--r--  1 jerry pantheon  41426 Oct 17 00:36 aclocal.m4
-rw-r--r--  1 jerry pantheon   3097 Oct 17 00:35 AUTHORS
-rwxr-xr-x  1 jerry pantheon    191 Oct 17 00:35 autogen.sh
drwxr-xr-x  2 jerry pantheon   4096 Oct 17 00:37 autom4te.cache
drwxr-xr-x  4 jerry pantheon   4096 Oct 17 00:41 auxprogs
-rw-r--r--  1 jerry pantheon   1285 Oct 17 00:35 bionic.supp
drwxr-xr-x  5 jerry pantheon   4096 Oct 17 01:03 cachegrind
drwxr-xr-x  5 jerry pantheon   4096 Oct 17 01:03 callgrind
lrwxrwxrwx  1 jerry pantheon     32 Oct 17 00:37 compile ->
/usr/share/automake-1.13/compile
lrwxrwxrwx  1 jerry pantheon     37 Oct 17 00:37 config.guess ->
/usr/share/automake-1.13/config.guess
-rw-r--r--  1 jerry pantheon  10675 Oct 17 00:37 config.h
-rw-r--r--  1 jerry pantheon  10013 Oct 17 00:36 config.h.in
-rw-r--r--  1 jerry pantheon 100412 Oct 17 00:38 config.log
-rwxr-xr-x  1 jerry pantheon  50326 Oct 17 00:37 config.status
lrwxrwxrwx  1 jerry pantheon     35 Oct 17 00:37 config.sub ->
/usr/share/automake-1.13/config.sub
-rwxr-xr-x  1 jerry pantheon 370866 Oct 17 00:37 configure
-rw-r--r--  1 jerry pantheon  86441 Oct 17 00:36 configure.ac
-rw-r--r--  1 jerry pantheon  17987 Oct 17 00:36 COPYING
-rw-r--r--  1 jerry pantheon  20415 Oct 17 00:35 COPYING.DOCS
drwxr-xr-x 17 jerry pantheon  12288 Oct 17 01:03 coregrind
-rw-r--r--  1 jerry pantheon   2542 Oct 17 00:36 darwin10-drd.supp
-rw-r--r--  1 jerry pantheon   1727 Oct 17 00:35 darwin10.supp
-rw-r--r--  1 jerry pantheon   6268 Oct 17 00:36 darwin11.supp
-rw-r--r--  1 jerry pantheon   5911 Oct 17 00:35 darwin12.supp
-rw-r--r--  1 jerry pantheon  10266 Oct 17 00:36 darwin9-drd.supp
-rw-r--r--  1 jerry pantheon   7182 Oct 17 00:36 darwin9.supp
-rw-r--r--  1 jerry pantheon  29799 Oct 17 00:38 default.supp
lrwxrwxrwx  1 jerry pantheon     32 Oct 17 00:37 depcomp ->
/usr/share/automake-1.13/depcomp
drwxr-xr-x  6 jerry pantheon   4096 Oct 17 00:37 docs
drwxr-xr-x  6 jerry pantheon   4096 Oct 17 01:03 drd
drwxr-xr-x  5 jerry pantheon   4096 Oct 17 01:03 exp-bbv
drwxr-xr-x  5 jerry pantheon   4096 Oct 17 01:03 exp-dhat
drwxr-xr-x  5 jerry pantheon   4096 Oct 17 01:03 exp-sgcheck
-rw-r--r--  1 jerry pantheon    372 Oct 17 00:36 exp-sgcheck.supp
drwxr-xr-x  3 jerry pantheon   4096 Oct 17 00:37 gdbserver_tests
-rw-r--r--  1 jerry pantheon   1203 Oct 17 00:36
glibc-2.2-LinuxThreads-helgrind.supp
-rw-r--r--  1 jerry pantheon   9477 Oct 17 00:36 glibc-2.2.supp
-rw-r--r--  1 jerry pantheon   5759 Oct 17 00:36
glibc-2.34567-NPTL-helgrind.supp
-rw-r--r--  1 jerry pantheon  11294 Oct 17 00:36 glibc-2.3.supp
-rw-r--r--  1 jerry pantheon   4816 Oct 17 00:36 glibc-2.4.supp
-rw-r--r--  1 jerry pantheon   3941 Oct 17 00:35 glibc-2.5.supp
-rw-r--r--  1 jerry pantheon   4795 Oct 17 00:36 glibc-2.6.supp
-rw-r--r--  1 jerry pantheon    695 Oct 17 00:35 glibc-2.7.supp
-rw-r--r--  1 jerry pantheon   6769 Oct 17 00:36 glibc-2.X-drd.supp
-rw-r--r--  1 jerry pantheon   4749 Oct 17 00:37 glibc-2.X.supp
-rw-r--r--  1 jerry pantheon   5277 Oct 17 00:35 glibc-2.X.supp.in
drwxr-xr-x  5 jerry pantheon   4096 Oct 17 01:03 helgrind
drwxr-xr-x  3 jerry pantheon   4096 Oct 17 00:37 include
lrwxrwxrwx  1 jerry pantheon     35 Oct 17 00:37 install-sh ->
/usr/share/automake-1.13/install-sh
drwxr-xr-x  5 jerry pantheon   4096 Oct 17 01:03 lackey
-rw-r--r--  1 jerry pantheon  41909 Oct 17 00:37 Makefile
-rw-r--r--  1 jerry pantheon   8372 Oct 17 00:35 Makefile.all.am
-rw-r--r--  1 jerry pantheon   3362 Oct 17 00:35 Makefile.am
-rw-r--r--  1 jerry pantheon  42614 Oct 17 00:37 Makefile.in
-rw-r--r--  1 jerry pantheon   5616 Oct 17 00:36 Makefile.tool.am
-rw-r--r--  1 jerry pantheon   1372 Oct 17 00:35 Makefile.tool-tests.am
-rw-r--r--  1 jerry pantheon   4585 Oct 17 00:35 Makefile.vex.am
-rw-r--r--  1 jerry pantheon 296066 Oct 17 00:37 Makefile.vex.in
drwxr-xr-x  5 jerry pantheon   4096 Oct 17 01:03 massif
drwxr-xr-x  5 jerry pantheon   4096 Oct 17 01:03 memcheck
lrwxrwxrwx  1 jerry pantheon     32 Oct 17 00:37 missing ->
/usr/share/automake-1.13/missing
drwxr-xr-x  3 jerry pantheon   4096 Oct 17 00:37 mpi
-rw-r--r--  1 jerry pantheon 105926 Oct 17 00:35 NEWS
-rw-r--r--  1 jerry pantheon  86605 Oct 17 00:36 NEWS.old
drwxr-xr-x  4 jerry pantheon   4096 Oct 17 00:36 nightly
drwxr-xr-x  5 jerry pantheon   4096 Oct 17 01:03 none
drwxr-xr-x  3 jerry pantheon   4096 Oct 17 00:37 perf
-rw-r--r--  1 jerry pantheon   3237 Oct 17 00:35 README
-rw-r--r--  1 jerry pantheon   5389 Oct 17 00:35 README.android
-rw-r--r--  1 jerry pantheon   1884 Oct 17 00:35 README.android_emulator
-rw-r--r--  1 jerry pantheon  11384 Oct 17 00:35 README_DEVELOPERS
-rw-r--r--  1 jerry pantheon   2157 Oct 17 00:36 README.mips
-rw-r--r--  1 jerry pantheon   6936 Oct 17 00:35
README_MISSING_SYSCALL_OR_IOCTL
-rw-r--r--  1 jerry pantheon   4463 Oct 17 00:35 README_PACKAGERS
-rw-r--r--  1 jerry pantheon   1994 Oct 17 00:36 README.s390
-rw-r--r--  1 jerry pantheon     23 Oct 17 00:37 stamp-h1
drwxr-xr-x  3 jerry pantheon   4096 Oct 17 00:37 tests
-rw-r--r--  1 jerry pantheon    369 Oct 17 00:37 valgrind.pc
-rw-r--r--  1 jerry pantheon    447 Oct 17 00:35 valgrind.pc.in
-rw-r--r--  1 jerry pantheon   1219 Oct 17 00:37 valgrind.spec
-rw-r--r--  1 jerry pantheon   1222 Oct 17 00:36 valgrind.spec.in
drwxr-xr-x 15 jerry pantheon   4096 Oct 17 00:40 VEX
-rwxr-xr-x  1 jerry pantheon    691 Oct 17 00:36 vg-in-place
-rw-r--r--  1 jerry pantheon   2946 Oct 17 00:36 xfree-3.supp
-rw-r--r--  1 jerry pantheon   9018 Oct 17 00:36 xfree-4.supp
==4957==
==4957== HEAP SUMMARY:
==4957==     in use at exit: 22,689 bytes in 97 blocks
==4957==   total heap usage: 418 allocs, 321 frees, 97,864 bytes allocated
==4957==
==4957== LEAK SUMMARY:
==4957==    definitely lost: 0 bytes in 0 blocks
==4957==    indirectly lost: 0 bytes in 0 blocks
==4957==      possibly lost: 0 bytes in 0 blocks
==4957==    still reachable: 22,689 bytes in 97 blocks
==4957==         suppressed: 0 bytes in 0 blocks
==4957== Rerun with --leak-check=full to see details of leaked memory
==4957==
==4957== For counts of detected and suppressed errors, rerun with: -v
==4957== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 2 from 2)



On Wed, Oct 16, 2013 at 2:52 PM, Mark Wielaard <mj...@re...> wrote:

> On Wed, 2013-10-16 at 13:02 -0700, Jerry Blakley wrote:
> > Thanks. Created the bug: Bug 326113 - valgrind libvex hwcaps error on
> > AMD64
>
> Thanks. I added some comments and a proposed patch for valgrind SVN to
> that bug report. If you could try that out, that would be great.
>
> Mark
>
>
>

Re: [Valgrind-users] valgrind error on fedora 19 AMD64

[Mark W. <mj...@re...>]

On Wed, 2013-10-16 at 13:02 -0700, Jerry Blakley wrote:
> Thanks. Created the bug: Bug 326113 - valgrind libvex hwcaps error on
> AMD64

Thanks. I added some comments and a proposed patch for valgrind SVN to
that bug report. If you could try that out, that would be great.

Mark

Re: [Valgrind-users] valgrind error on fedora 19 AMD64

[Jerry B. <je...@ge...>]

Thanks. Created the bug: Bug 326113 - valgrind libvex hwcaps error on AMD64
Jerry


On Wed, Oct 16, 2013 at 11:34 AM, Mark Wielaard <mj...@re...> wrote:

> On Wed, 2013-10-16 at 10:48 -0700, Jerry Blakley wrote:
>
> > Thanks for the note. Here's the version I've been using:
> >
> > valgrind-3.8.1-15.fc19.x86_64
> >
> > I wasn't able to find a more recent fedora package.
>
> That is the latest stable version for f19.
> There are some newer versions for f20/rawhide, but I doubt they solve
> the issue. http://koji.fedoraproject.org/koji/packageinfo?packageID=98
>
> > We run on servers at rackspace. There is an older generation of cpu's
> > and valgrind works find on them. It is the newer (about a year-old)
> > generation on which valgrind doesn't work. This was a big surprise,
> > since I think they are stock processors. Might there be something in
> > the VM/hypervisor layer which is not translating correctly?
> >
> >
> > I did just go the svn route. The results look similar.
>
> Then it at least isn't the fedora package/patches. Thanks for checking.
> So it must be some flag/cpuid combination valgrind isn't handling
> correctly.
>
> Would you mind installing cpuid (it is packaged for fedora) or building
> it from source: http://etallen.com/cpuid.html
>
> Then run:
>         cpuid -1
> and
>         cpuid -1 -r
>
> Please file that output in a new bug at:
> https://bugs.kde.org/enter_bug.cgi?product=valgrind
>
> Thanks,
>
> Mark
>
>
>

Re: [Valgrind-users] Lock address can't be shown?

[Philippe W. <phi...@sk...>]

On Wed, 2013-10-16 at 17:36 +0000, Phil Longstaff wrote:

> ==23046== Locks held: 3, at addresses 0xFDA2148 0xFE2B020  (and 1 that
> can't be shown)
> What could cause a lock to have an address that can’t be shown?

Here is a comment from hg_errors.c which explains:

/* Given a normal Lock (LockN), convert it to a persistent Lock
   (LockP).  In some cases the LockN could be invalid (if it's been
   freed), so we enquire, in hg_main.c's admin_locks list, whether it
   is in fact valid.  If allowed_to_be_invalid is True, then it's OK
   for the LockN to be invalid, in which case Lock_INVALID is
   returned.  In all other cases, we insist that the LockN is a valid
   lock, and return its corresponding LockP.

   Why can LockNs sometimes be invalid?  Because they are harvested
   from locksets that are attached to the OldRef info for conflicting
   threads.  By the time we detect a race, the some of the elements of
   the lockset may have been destroyed by the client, in which case
   the corresponding Lock structures we maintain will have been freed.

   So we check that each LockN is a member of the admin_locks double
   linked list of all Lock structures.  That stops us prodding around
   in potentially freed-up Lock structures.  However, it's not quite a
   proper check: if a new Lock has been reallocated at the same
   address as one which was previously freed, we'll wind up copying
   the new one as the basis for the LockP, which is completely bogus
   because it is unrelated to the previous Lock that lived there.
   Let's hope that doesn't happen too often.
*/

Re: [Valgrind-users] valgrind error on fedora 19 AMD64

[Mark W. <mj...@re...>]

On Wed, 2013-10-16 at 10:48 -0700, Jerry Blakley wrote:

> Thanks for the note. Here's the version I've been using:
>
> valgrind-3.8.1-15.fc19.x86_64
>
> I wasn't able to find a more recent fedora package.

That is the latest stable version for f19.
There are some newer versions for f20/rawhide, but I doubt they solve
the issue. http://koji.fedoraproject.org/koji/packageinfo?packageID=98

> We run on servers at rackspace. There is an older generation of cpu's
> and valgrind works find on them. It is the newer (about a year-old)
> generation on which valgrind doesn't work. This was a big surprise,
> since I think they are stock processors. Might there be something in
> the VM/hypervisor layer which is not translating correctly?
> 
> 
> I did just go the svn route. The results look similar.

Then it at least isn't the fedora package/patches. Thanks for checking.
So it must be some flag/cpuid combination valgrind isn't handling
correctly.

Would you mind installing cpuid (it is packaged for fedora) or building
it from source: http://etallen.com/cpuid.html

Then run:
	cpuid -1
and
	cpuid -1 -r

Please file that output in a new bug at:
https://bugs.kde.org/enter_bug.cgi?product=valgrind

Thanks,

Mark

Re: [Valgrind-users] valgrind error on fedora 19 AMD64

[Jerry B. <je...@ge...>]

Hi Mark,
Thanks for the note. Here's the version I've been using:

valgrind-3.8.1-15.fc19.x86_64

I wasn't able to find a more recent fedora package.

We run on servers at rackspace. There is an older generation of cpu's and
valgrind works find on them. It is the newer (about a year-old) generation
on which valgrind doesn't work. This was a big surprise, since I think they
are stock processors. Might there be something in the VM/hypervisor layer
which is not translating correctly?

I did just go the svn route. The results look similar.

 valgrind]$ ll /usr/bin/valgrind
-rwxr-xr-x. 1 root root 54427 Oct 16 17:44 /usr/bin/valgrind

valgrind]$ valgrind ls -l
==21888== Memcheck, a memory error detector
==21888== Copyright (C) 2002-2012, and GNU GPL'd, by Julian Seward et al.
==21888== Using Valgrind-3.9.0.SVN and LibVEX; rerun with -h for copyright
info
==21888== Command: ls -l
==21888==

vex: priv/main_main.c:338 (LibVEX_Translate): Assertion
`are_valid_hwcaps(VexArchAMD64, vta->archinfo_host.hwcaps)' failed.
vex storage: T total 0 bytes allocated
vex storage: P total 0 bytes allocated

valgrind: the 'impossible' happened:
   LibVEX called failure_exit().
==21888==    at 0x3804FBAC: report_and_quit (m_libcassert.c:260)
==21888==    by 0x3804FDB1: vgPlain_core_panic_at (m_libcassert.c:350)
==21888==    by 0x3804FDDA: vgPlain_core_panic (m_libcassert.c:360)
==21888==    by 0x38067E32: failure_exit (m_translate.c:731)
==21888==    by 0x380FA1F8: vex_assert_fail (main_util.c:219)
==21888==    by 0x380F90AF: LibVEX_Translate (main_main.c:338)
==21888==    by 0x3806A24E: vgPlain_translate (m_translate.c:1602)
==21888==    by 0x3809B596: vgPlain_scheduler (scheduler.c:1004)
==21888==    by 0x380AA6FC: run_a_thread_NORETURN (syswrap-linux.c:103)

sched status:
  running_tid=1

Thread 1: status = VgTs_Runnable
==21888==    at 0x315C601420: ??? (in /usr/lib64/ld-2.17.so)
==21888==    by 0x1: ???
==21888==    by 0xFFF0005CA: ???
==21888==    by 0xFFF0005CD: ???


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.

Thanks.
Jerry


On Wed, Oct 16, 2013 at 6:55 AM, Mark Wielaard <mj...@re...> wrote:

> On Tue, 2013-10-15 at 14:48 -0700, Jerry Blakley wrote:
> > I'm running valgrind on fedora 19. I checked libvex code which
> > executes the hwcaps code, but can't find anything in particular.
>
>
> > vex: priv/main_main.c:319 (LibVEX_Translate): Assertion
> > `are_valid_hwcaps(VexArchAMD64, vta->archinfo_host.hwcaps)' failed.
>
> This will happen when valgrind/VEX doesn't understand the (combination
> of) cpuid capabilities of your CPU.
>
> Specifically show_hwcaps_amd64 () in VEX/priv/main_main.c should return
> a valid string describing the configuration (not NULL).
>
> The version in fedora valgrind 3.8.1 only handles fixed combinations of
> flags, the version in valgrind SVN is more flexible.
>
> > flags : fpu de tsc msr pae cx8 cmov pat clflush mmx fxsr sse sse2 ht
> > syscall nx mmxext fxsr_opt lm rep_good nopl pni pclmulqdq ssse3 fma
> > cx16 sse4_1 sse4_2 popcnt aes f16c hypervisor lahf_lm cmp_legacy
> > extapic cr8_legacy abm sse4a misalignsse 3dnowprefetch xop fma4 tce
> > tbm perfctr_core perfctr_nb arat cpb hw_pstate
>
> If I am reading that right, you don't have AVX, RDTSCP, BMI or AVX. You
> do have SSE3 (pni), XC16 and LZCNT (abm)
>
> Which should give you:
>
>       case VEX_HWCAPS_AMD64_SSE3 | VEX_HWCAPS_AMD64_CX16
>            | VEX_HWCAPS_AMD64_LZCNT:
>          return "amd64-sse3-cx16-lzcnt";
>
> So I am probably missing some detail/flag.
>
> Which fedora valgrind package version is this exactly?
> You can tell by running "rpm -q valgrind".
> Have you tried valgrind build from SVN?
>
> Thanks,
>
> Mark
>
>

[Valgrind-users] Lock address can't be shown?

[Phil L. <plo...@sa...>]

Using valgrind 3.8.0 on a freebsd system, I get this report:

==23046== Possible data race during read of size 8 at 0x12D2C5A0 by thread #65
==23046== Locks held: none
==23046==    at 0x41C11F6: memmove (in /lib/libc.so.7)
==23046==    by 0x1030375: variable_list** std::__copy_move<false, true, std::random_access_iterator_tag>::__copy_m<variable_list*>(variable_list* const*, variable_list* const*, variable_list**) (stl_algobase.h:377)
==23046==    by 0x10303BD: variable_list** std::__copy_move_a<false, variable_list**, variable_list**>(variable_list**, variable_list**, variable_list**) (stl_algobase.h:396)
==23046==    by 0x1030405: variable_list** std::__copy_move_a2<false, variable_list**, variable_list**>(variable_list**, variable_list**, variable_list**) (stl_algobase.h:435)
==23046==    by 0x1030447: variable_list** std::copy<variable_list**, variable_list**>(variable_list**, variable_list**, variable_list**) (stl_algobase.h:466)
==23046==    by 0x1030473: variable_list** std::__uninitialized_copy<true>::uninitialized_copy<variable_list**, variable_list**>(variable_list**, variable_list**, variable_list**) (stl_uninitialized.h:98)
==23046==    by 0x103049A: variable_list** std::uninitialized_copy<variable_list**, variable_list**>(variable_list**, variable_list**, variable_list**) (stl_uninitialized.h:122)
==23046==    by 0x10304C5: variable_list** std::__uninitialized_copy_a<variable_list**, variable_list**, variable_list*>(variable_list**, variable_list**, variable_list**, std::allocator<variable_list*>&) (stl_uninitialized.h:262)
==23046==    by 0x10304F4: variable_list** std::__uninitialized_move_a<variable_list**, variable_list**, std::allocator<variable_list*> >(variable_list**, variable_list**, variable_list**, std::allocator<variable_list*>&) (stl_uninitialized.h:272)
==23046==    by 0x103074A: std::vector<variable_list*, std::allocator<variable_list*> >::_M_insert_aux(__gnu_cxx::__normal_iterator<variable_list**, std::vector<variable_list*, std::allocator<variable_list*> > >, variable_list* const&) (vector.tcc:316)
==23046==    by 0x10308DC: std::vector<variable_list*, std::allocator<variable_list*> >::insert(__gnu_cxx::__normal_iterator<variable_list**, std::vector<variable_list*, std::allocator<variable_list*> > >, variable_list* const&) (vector.tcc:113)
==23046==    by 0x102E417: snmpNotification::addVarbind(snmpVarbind const&, unsigned long) (snmpNotification.cpp:392)
==23046==
==23046== This conflicts with a previous write of size 8 by thread #43
==23046== Locks held: 3, at addresses 0xFDA2148 0xFE2B020  (and 1 that can't be shown)
==23046==    at 0x11D4CA3: pdbBulkUpdateRecord::pdbBulkUpdateRecord(pdbBulkUpdateRecord const&) (BulkUpdateDefs.h:36)
==23046==    by 0x1212730: __gnu_cxx::new_allocator<pdbBulkUpdateRecord>::construct(pdbBulkUpdateRecord*, pdbBulkUpdateRecord const&) (new_allocator.h:108)
==23046==    by 0x1216A4C: std::vector<pdbBulkUpdateRecord, std::allocator<pdbBulkUpdateRecord> >::push_back(pdbBulkUpdateRecord const&) (stl_vector.h:690)

What could cause a lock to have an address that can't be shown?

Phil
-----
Phil Longstaff
Senior Software Engineer
x2904

Re: [Valgrind-users] valgrind error on fedora 19 AMD64

[Mark W. <mj...@re...>]

On Tue, 2013-10-15 at 14:48 -0700, Jerry Blakley wrote:
> I'm running valgrind on fedora 19. I checked libvex code which
> executes the hwcaps code, but can't find anything in particular.


> vex: priv/main_main.c:319 (LibVEX_Translate): Assertion
> `are_valid_hwcaps(VexArchAMD64, vta->archinfo_host.hwcaps)' failed.

This will happen when valgrind/VEX doesn't understand the (combination
of) cpuid capabilities of your CPU.

Specifically show_hwcaps_amd64 () in VEX/priv/main_main.c should return
a valid string describing the configuration (not NULL).

The version in fedora valgrind 3.8.1 only handles fixed combinations of
flags, the version in valgrind SVN is more flexible.

> flags : fpu de tsc msr pae cx8 cmov pat clflush mmx fxsr sse sse2 ht
> syscall nx mmxext fxsr_opt lm rep_good nopl pni pclmulqdq ssse3 fma
> cx16 sse4_1 sse4_2 popcnt aes f16c hypervisor lahf_lm cmp_legacy
> extapic cr8_legacy abm sse4a misalignsse 3dnowprefetch xop fma4 tce
> tbm perfctr_core perfctr_nb arat cpb hw_pstate

If I am reading that right, you don't have AVX, RDTSCP, BMI or AVX. You
do have SSE3 (pni), XC16 and LZCNT (abm)

Which should give you:

      case VEX_HWCAPS_AMD64_SSE3 | VEX_HWCAPS_AMD64_CX16
           | VEX_HWCAPS_AMD64_LZCNT:
         return "amd64-sse3-cx16-lzcnt";

So I am probably missing some detail/flag.

Which fedora valgrind package version is this exactly?
You can tell by running "rpm -q valgrind".
Have you tried valgrind build from SVN?

Thanks,

Mark

[Valgrind-users] valgrind error on fedora 19 AMD64

[Jerry B. <je...@ge...>]

I'm running valgrind on fedora 19. I checked libvex code which executes the
hwcaps code, but can't find anything in particular.

valgrind --tool=memcheck /bin/ls

==23682== Memcheck, a memory error detector
==23682== Copyright (C) 2002-2012, and GNU GPL'd, by Julian Seward et al.
==23682== Using Valgrind-3.8.1 and LibVEX; rerun with -h for copyright info
==23682== Command: /bin/ls
==23682==

vex: priv/main_main.c:319 (LibVEX_Translate): Assertion
`are_valid_hwcaps(VexArchAMD64, vta->archinfo_host.hwcaps)' failed.
vex storage: T total 0 bytes allocated
vex storage: P total 0 bytes allocated

valgrind: the 'impossible' happened:
   LibVEX called failure_exit().
==23682==    at 0x38059B6F: ??? (in
/usr/lib64/valgrind/memcheck-amd64-linux)
==23682==    by 0x38059D31: ??? (in
/usr/lib64/valgrind/memcheck-amd64-linux)
==23682==    by 0x38059D5A: ??? (in
/usr/lib64/valgrind/memcheck-amd64-linux)
==23682==    by 0x38071252: ??? (in
/usr/lib64/valgrind/memcheck-amd64-linux)
==23682==    by 0x380F6618: ??? (in
/usr/lib64/valgrind/memcheck-amd64-linux)
==23682==    by 0x380F5640: ??? (in
/usr/lib64/valgrind/memcheck-amd64-linux)
==23682==    by 0x3807352F: ??? (in
/usr/lib64/valgrind/memcheck-amd64-linux)
==23682==    by 0x3809F096: ??? (in
/usr/lib64/valgrind/memcheck-amd64-linux)
==23682==    by 0x380AE0FC: ??? (in
/usr/lib64/valgrind/memcheck-amd64-linux)

sched status:
  running_tid=1

Thread 1: status = VgTs_Runnable
==23682==    at 0x4001420: ??? (in /usr/lib64/ld-2.17.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.


ls -l /usr/bin/valgrind
-rwxr-xr-x. 1 root root 19880 Apr 25 08:57 /usr/bin/valgrind



Here's the CPU info
cat /proc/cpuinfo
processor : 0
vendor_id : AuthenticAMD
cpu family : 21
model : 2
model name : AMD Opteron(tm) Processor 4332 HE
stepping : 0
microcode : 0x600081f
cpu MHz : 3000.098
cache size : 2048 KB
fpu : yes
fpu_exception : yes
cpuid level : 13
wp : yes
flags : fpu de tsc msr pae cx8 cmov pat clflush mmx fxsr sse sse2 ht
syscall nx mmxext fxsr_opt lm rep_good nopl pni pclmulqdq ssse3 fma cx16
sse4_1 sse4_2 popcnt aes f16c hypervisor lahf_lm cmp_legacy extapic
cr8_legacy abm sse4a misalignsse 3dnowprefetch xop fma4 tce tbm
perfctr_core perfctr_nb arat cpb hw_pstate
bogomips : 6000.19
TLB size : 1536 4K pages
clflush size : 64
cache_alignment : 64
address sizes : 48 bits physical, 48 bits virtual
power management: ts ttp tm 100mhzsteps hwpstate cpb eff_freq_ro

uname -a
Linux  3.10.11-200.fc19.x86_64 #1 SMP Mon Sep 9 13:03:01 UTC 2013 x86_64
x86_64 x86_64 GNU/Linux

Thanks.
Jerry

[Valgrind-users] Fwd: 3.9.0-SVN optimized build crashes with infinite loop

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

Compiling revision 13634 against GCC 4.8.1 on SUSE10 with CFLAGS="-O3 -g0"
causes the valgrind executable to crash with a SEGFAULT. Attaching with GDB
shows

Program received signal SIGSEGV, Segmentation fault.
0x000000003805ab5a in vgPlain_memset ()
(gdb) up
#1  0x000000003805ab5f in vgPlain_memset ()
(gdb) up
#2  0x000000003805ab5f in vgPlain_memset ()
(gdb) up
...

which looks very similar to this

http://llvm.org/bugs/show_bug.cgi?id=9795

but rebuilding with CFLAGS="-O3 -g0 -ffreestanding" did not help the
situation.

Debug builds work fine. -O2 works fine as well.

Re: [Valgrind-users] Limiting helgrind to finding only write-write conflicts

[David F. <fa...@kd...>]

On Tuesday 08 October 2013 19:34:03 Phil Longstaff wrote:
> I don't see any command line options which limit helgrind to ignoring
> read/write or write/read conflicts and only displaying write/write
> conflicts.  Would that be hard to add?
> 
> We have situations where we think only 1 thread updates some counter, and
> periodically, another thread reads the value for display.  If there's a
> conflict, we don't really care whether the display shows the before or the
> after value.  However, we are interested in knowing if some other code path
> tries to update the value i.e. we care about write/write conflicts.

A read-write conflict is still a race condition, which leads to undefined 
behavior according to the C++11 standard. On some non-x86 platforms, you could 
end up with the displayed value always being 0, for instance, if the CPU 
running that thread keeps getting it from its outdated cache. Without mutexes 
or atomic operations, there's no guarantee that cache will ever get updated.
My advice is to use std::atomic_int -- which provides exactly the behavior 
you're hoping to get ("we don't care whether the display shows the before or 
the after value").
This being said, helgrind might be missing suppressions for atomic_int (the 
same way I'm using suppressions for Qt's QAtomicInt) - since on the special 
case of x86, the two can't be distinguished by helgrind.

-- 
David Faure, fa...@kd..., http://www.davidfaure.fr
Working on KDE, in particular KDE Frameworks 5

[Valgrind-users] Limiting helgrind to finding only write-write conflicts

[Phil L. <plo...@sa...>]

I don't see any command line options which limit helgrind to ignoring read/write or write/read conflicts and only displaying write/write conflicts.  Would that be hard to add?

We have situations where we think only 1 thread updates some counter, and periodically, another thread reads the value for display.  If there's a conflict, we don't really care whether the display shows the before or the after value.  However, we are interested in knowing if some other code path tries to update the value i.e. we care about write/write conflicts.

Phil

Re: [Valgrind-users] Is it possible to check specified bugs?

[Brad H. <br...@fr...>]

On Mon, 7 Oct 2013 12:18:51 PM Lu Mitnick wrote:
> I would like to know the performance number for detection of each type of
> bug, ie. the execution time when the Valgrind only
> detect illegal read/write, or the execution time when the Valgrind only
> detect use of uninitialised values ... etc.  Is it possible to
> check specified bugs?
Is this some academic / theoretical exercise? The problem is that the 
detection of a single type of bug isn't well separated. So the cost of 
detecting bug type X and the cost of detecting bug type Y is going to have a 
lot of common factors (all the tracking work). 

If its academic, I'd suggest modifying the code to extract the numbers you 
want to show. It probably won't be very meaningful, but it is what it is.

If its not academic, please explain why you are trying to do this (not just 
what) - some context, so we can provide something that can help you solve your 
real problem.

Brad

Re: [Valgrind-users] Is it possible to check specified bugs?

[Lu M. <kin...@gm...>]

Hello Philippe,


2013/10/1 Philippe Waroquiers <phi...@sk...>

> On Mon, 2013-09-30 at 14:49 +0400, Konstantin Tokarev wrote:
> > 30.09.2013, 03:15, "Lu Mitnick" <kin...@gm...>:
> > > Hello all,
> > >
> > > Memcheck could be used to detect different type of bugs:
> > > 1. illegal read/write
> > > 2. use of uninitialised values
> > > 3. illegal frees
> > > 4. when a heap block is freed with an inappropriate deallocation
> function
> > > ...
> > >
> > > I am wondering whether it is possible to use valgrind to check
> specified bug types? In other words, I would like to use memcheck to only
> check addressable bug, illegal frees bug and allocation/deallocation
> routine mismatched bug in the first run. Then check the use of
> uninitialised values bug in the second run.
> What is the reason to do two runs rather than one single run (reporting
> all found problems) ?


I would like to know the performance number for detection of each type of
bug, ie. the execution time when the Valgrind only
detect illegal read/write, or the execution time when the Valgrind only
detect use of uninitialised values ... etc.  Is it possible to
check specified bugs?


> > >
> > > Thanks a lot.
> >
> > You can use AddressSanitizer (clang 3.0+ or gcc 4.8+) for the first run.
> As a bonus point it does not cause so heavy
> >  slowdown as valgrind and provides more verbose info for bugs like use
> after free (trace when it was allocated,
> > when it was deleted, and when it was used, while memcheck shows only the
> last one).
> Valgrind 3.8.1 (and before) gives the stack traces of the
> 'use after free' and and where it was freed.
>
> In Valgrind 3.9.0 SVN, the option
>    --keep-stacktraces=alloc|free|alloc-and-free|alloc-then-free|none
>         stack trace(s) to keep for malloc'd/free'd areas
> [alloc-then-free]
> allows to specify what to keep, giving e.g.
>
> ==2495== Invalid write of size 1
> ==2495==    at 0x804844A: really (malloc1.c:20)
> ==2495==    by 0x80483FE: main (malloc1.c:9)
> ==2495==  Address 0x4028029 is 1 bytes inside a block of size 10 free'd
> ==2495==    at 0x4006CC2: free (vg_replace_malloc.c:468)
> ==2495==    by 0x8048443: really (malloc1.c:19)
> ==2495==    by 0x80483FE: main (malloc1.c:9)
> ==2495==   block was alloc'd at
> ==2495==    at 0x40072D5: malloc (vg_replace_malloc.c:291)
> ==2495==    by 0x8048419: really (malloc1.c:16)
> ==2495==    by 0x80483FE: main (malloc1.c:9)
>
> Otherwise, the option --undef-value-errors=no|yes allows to disable/enable
> checking
> for undef values. --undef-value-errors=no more or less doubles the speed
> (measured on bz2 on x86-64).
>
> To my knowledge, Address sanitizer does not detect mismatch between alloc
> and free fn
> (which memcheck does) but it finds overruns in stack and global vars
>
> Philippe
>
>
>
Thanks a lot

Re: [Valgrind-users] Valgrind + Android

[Marc S. <mar...@gm...>]

I'm trying this with PIN and Valgrind but doesnt work:

http://stackoverflow.com/questions/9123124/how-to-start-an-android-app-with-valgrind


2013/10/6 Matthew Mitchell <mat...@th...>

> Is it not possible to restart zygote with zalgrind? I'm trying to debug an
> app using the NDK. I don't know if the NDK library is loaded and executed
> in the zygote process? If so I guess I have a similar problem.
>
> In the init.rc file on android zygote is started as:
>
> service zygote /system/bin/app_process -Xzygote /system/bin --zygote
> --start-system-server
>
> I suppose that could be changed to start zygote by valgrind instead? This
> would run valgrind for all apps though.
>
> Matthew.
>
>
> On 5 Oct 2013, at 18:32, Marc Sampé <mar...@gm...> wrote:
>
> > Yep. "am start" sends a signal via socket to zygote, so there's no
> children to follow.
> >
> >
> > 2013/10/5 Vasily Golubev <vas...@gm...>
> > Mr. Sampe,
> >
> > Did you try flag --trace-children=yes?
> >
> > Vasily
> >
> > On Thu, Oct 3, 2013 at 4:19 PM, Marc Sampé <mar...@es...>
> wrote:
> > > Hi!
> > >
> > > I'm new using Valgrind out of Linux. I'm working in a project on
> Android and
> > > I'm trying to instrument "com.android.mms" or Mms.apk.
> > >
> > > I tried using "am start" but am only sends a signal to Zygote so
> valgrind
> > > will never trace the new process.
> > >
> > > I read that Valgrind has ARM support, so I guess that someone knows
> hot to
> > > do it.
> > >
> > > Any hint or help will be grateful!
> > >
> > > Thanks
> > >
> > > --
> > > Marc Sampé Gascó
> > > Estudiant de Enginyeria Informàtica ( UPC )
> > >
> > >
> ------------------------------------------------------------------------------
> > > October Webinars: Code for Performance
> > > Free Intel webinars can help you accelerate application performance.
> > > Explore tips for MPI, OpenMP, advanced profiling, and more. Get the
> most
> > > from
> > > the latest Intel processors and coprocessors. See abstracts and
> register >
> > >
> http://pubads.g.doubleclick.net/gampad/clk?id=60134791&iu=/4140/ostg.clktrk
> > > _______________________________________________
> > > Valgrind-users mailing list
> > > Val...@li...
> > > https://lists.sourceforge.net/lists/listinfo/valgrind-users
> > >
> >
> >
> >
> > --
> > Best Regards,
> > Vasily
> >
> >
> ------------------------------------------------------------------------------
> > October Webinars: Code for Performance
> > Free Intel webinars can help you accelerate application performance.
> > Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most
> from
> > the latest Intel processors and coprocessors. See abstracts and register
> >
> >
> http://pubads.g.doubleclick.net/gampad/clk?id=60134791&iu=/4140/ostg.clktrk
> > _______________________________________________
> > Valgrind-users mailing list
> > Val...@li...
> > https://lists.sourceforge.net/lists/listinfo/valgrind-users
> >
> >
> >
> > --
> > Marc
> >
> ------------------------------------------------------------------------------
> > October Webinars: Code for Performance
> > Free Intel webinars can help you accelerate application performance.
> > Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most
> from
> > the latest Intel processors and coprocessors. See abstracts and register
> >
> >
> http://pubads.g.doubleclick.net/gampad/clk?id=60134791&iu=/4140/ostg.clktrk_______________________________________________
> > Valgrind-users mailing list
> > Val...@li...
> > https://lists.sourceforge.net/lists/listinfo/valgrind-users
>
>


-- 
Marc

Re: [Valgrind-users] Dirty helper called more times than expected

[Sonny T. <son...@gm...>]

2013/10/6 Josef Weidendorfer

> Am 04.10.2013 21:47, schrieb Sonny Tavernier:
> > Hi,
> >
> > I have an unexpected behavior with a basic tool.
> > For each Put statement of a basic block, I register a dirty helper using
> > unsafeIRDirty_0_N.
> > The problem is that the dirty helper is called more times than expected,
> > e.g. there are 5 Put statements in a basic block but the dirty helper is
> > called 13 times.
>
> You seem to confuse instrumentation vs. execution time.
>
> As you set the counters to zero only at instrumentation time, of course
> they will diverge when a BB is executed a second time (as every BB is
> instrumented only once).
>
> Further, Valgrind works on super blocks (SBs), not just BBs.
> A SB may have multiple side exits. Thus, counters may be
> different whenever the execution flow exits an SB early.
>
> Josef
>

Thank you for your useful answer Josef.

Re: [Valgrind-users] Valgrind + Android

[Matthew M. <mat...@th...>]

Is it not possible to restart zygote with zalgrind? I'm trying to debug an app using the NDK. I don't know if the NDK library is loaded and executed in the zygote process? If so I guess I have a similar problem.

In the init.rc file on android zygote is started as:

service zygote /system/bin/app_process -Xzygote /system/bin --zygote --start-system-server

I suppose that could be changed to start zygote by valgrind instead? This would run valgrind for all apps though.

Matthew.


On 5 Oct 2013, at 18:32, Marc Sampé <mar...@gm...> wrote:

> Yep. "am start" sends a signal via socket to zygote, so there's no children to follow.
> 
> 
> 2013/10/5 Vasily Golubev <vas...@gm...>
> Mr. Sampe,
> 
> Did you try flag --trace-children=yes?
> 
> Vasily
> 
> On Thu, Oct 3, 2013 at 4:19 PM, Marc Sampé <mar...@es...> wrote:
> > Hi!
> >
> > I'm new using Valgrind out of Linux. I'm working in a project on Android and
> > I'm trying to instrument "com.android.mms" or Mms.apk.
> >
> > I tried using "am start" but am only sends a signal to Zygote so valgrind
> > will never trace the new process.
> >
> > I read that Valgrind has ARM support, so I guess that someone knows hot to
> > do it.
> >
> > Any hint or help will be grateful!
> >
> > Thanks
> >
> > --
> > Marc Sampé Gascó
> > Estudiant de Enginyeria Informàtica ( UPC )
> >
> > ------------------------------------------------------------------------------
> > October Webinars: Code for Performance
> > Free Intel webinars can help you accelerate application performance.
> > Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most
> > from
> > the latest Intel processors and coprocessors. See abstracts and register >
> > http://pubads.g.doubleclick.net/gampad/clk?id=60134791&iu=/4140/ostg.clktrk
> > _______________________________________________
> > Valgrind-users mailing list
> > Val...@li...
> > https://lists.sourceforge.net/lists/listinfo/valgrind-users
> >
> 
> 
> 
> --
> Best Regards,
> Vasily
> 
> ------------------------------------------------------------------------------
> October Webinars: Code for Performance
> Free Intel webinars can help you accelerate application performance.
> Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from
> the latest Intel processors and coprocessors. See abstracts and register >
> http://pubads.g.doubleclick.net/gampad/clk?id=60134791&iu=/4140/ostg.clktrk
> _______________________________________________
> Valgrind-users mailing list
> Val...@li...
> https://lists.sourceforge.net/lists/listinfo/valgrind-users
> 
> 
> 
> -- 
> Marc
> ------------------------------------------------------------------------------
> October Webinars: Code for Performance
> Free Intel webinars can help you accelerate application performance.
> Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from 
> the latest Intel processors and coprocessors. See abstracts and register >
> http://pubads.g.doubleclick.net/gampad/clk?id=60134791&iu=/4140/ostg.clktrk_______________________________________________
> Valgrind-users mailing list
> Val...@li...
> https://lists.sourceforge.net/lists/listinfo/valgrind-users