valgrind-users — General discussion list for Valgrind users

[Valgrind-users] multiplatform support

[Paolo P. <ppi...@cs...>]

Perhaps I did not understanding the nature of valgrind multiplatform 
support, so my previous questions were somewhat unclear.  Allow me to 
start from a more root question:

Is a given arch/OS build of valgrind only capable of running guest 
applications that target that same exact arch/OS?  When fiddling around 
with --enable-only* configurations it seems that the x86_64 builds don't 
run i386 applications even if the OS supports running i386 (e.g. 
x86_64-darwin valgrind libs don't work for i386 apps even though OSX 
supports i386).  Am I correct to say that "dual-arch" configuration just 
meaning that both x86_64 and i386 core and tools are built and the 
launcher picks the correct libs to use, but the individual libs are 
still limited to instrumenting applications that are of the same 
architecture that they themselves are compiled for? (i.e. you don't get 
VM-like capabilities of running another arch/OS by intermediate 
translation to VEXIR and then JIT into the native arch/OS)

-Paolo

Re: [Valgrind-users] Question about Valgrind tool implementation

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

On Mon, 2013-09-09 at 10:50 +0900, Chang-Jae Lee wrote:

> 
> The first definition of variable c is at line 11. We then suppress the
> line 11, and subsequent use of variable c(at line 12)
The above defines what to do speaking in terms of source lines,
while valgrind works at binary level.
There is not necessarily a one to one mapping between a source
line and a (contiguous) range of instructions. 
Also what if the source code has more than one statement
on one single line (either because that is how it was typed
or due to pre-processors macros) ?

At this stage, how to implement what you describe in a
valgrind tool looks quite a challenge to me.
Sorry to not be able to help on this.

Philippe

Re: [Valgrind-users] How to instruments only binary of executable under memcheck?

[Vasily G. <vas...@gm...>]

Hello, Mr. Mitnick.

You can generate suppression file for all Memcheck's output in libraries
and use it. In any case, Valgrind have to instrument all binary code in
libraries to track all read\write to the memory. Look at: valgrind --help
and flags --suppressions and --gen-suppressions.

Vasily


On Mon, Sep 9, 2013 at 8:16 PM, Lu Mitnick <kin...@gm...> wrote:

> Hello everyone,
>
> When I run memcheck with my application, which is a dynamic linked
> executable (ELF). It seems that memcheck instruments binary not only from
> executable itself but also from shared library. I just want to focus on the
> application written by my own. Is there any option to control memcheck only
> instruments binary of executables?
>
> Thanks a lot
>
>
> ------------------------------------------------------------------------------
> Learn the latest--Visual Studio 2012, SharePoint 2013, SQL 2012, more!
> Discover the easy way to master current and previous Microsoft technologies
> and advance your career. Get an incredible 1,500+ hours of step-by-step
> tutorial videos with LearnDevNow. Subscribe today and save!
> http://pubads.g.doubleclick.net/gampad/clk?id=58041391&iu=/4140/ostg.clktrk
> _______________________________________________
> Valgrind-users mailing list
> Val...@li...
> https://lists.sourceforge.net/lists/listinfo/valgrind-users
>
>


-- 
Best Regards,
Vasily

[Valgrind-users] How to instruments only binary of executable under memcheck?

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

Hello everyone,

When I run memcheck with my application, which is a dynamic linked
executable (ELF). It seems that memcheck instruments binary not only from
executable itself but also from shared library. I just want to focus on the
application written by my own. Is there any option to control memcheck only
instruments binary of executables?

Thanks a lot

Re: [Valgrind-users] Question about Valgrind tool implementation

[Chang-Jae L. <sik...@gm...>]

On Fri, Sep 6, 2013 at 5:43 AM, Philippe Waroquiers <
phi...@sk...> wrote:

> On Thu, 2013-09-05 at 16:01 +0900, Chang-Jae Lee wrote:
>
>
> Not too sure about what you mean with the above. Valgrind works
> at binary level, it does not really have a notion of "statement".
> For example, if in the code you have:
> f()
> {
>    char *ptr1;
>    char *ptr2;
>
> these two "statements" will just be part of the stack setup
> (e.g. change the stack pointer) and so there is no way to
> "remove" the instruction corresponding to
> e.g. only the first "ptr definition".
>
>
> As I do not understand the tool you have to write, I have no idea
> how to best do what you need.
>
>
>
Here I brought an example of the execution suppression from the paper:

-------------------------
- Let x and y be pointers to two malloc'ed memory regions, each able to
hold two integers.
- Let intArray be a heap array of integers.
- Let structArray be a heap array of pointers to structs with a f ield f.

1: int * p1 = &x[1];
2: int * p2 = &x[0];
3: int * q1 = &y[1];
4: int * q2 = &x[0]; // copy-paste error: should be &y[0]
5: *p1 = readInt();
6: *p2 = readInt(); // gets clobbered at line 8
7: *q1 = readInt();
8: *q2 = readInt(); // clobbers line 6 defi nition
9: int a = *p1 + *p2; // uses infected *p2/*q2
10: int b = *q1 + *q2; // uses infected *p2/*q2
11: int c = a + b + 1; // uses infected a and b
12: intArray[c] = 0; // potential buff er overfow
13: structArray[*p2]->f = 0; // potential NULL dereference
14: free(p2);
15: free(q2); // potential double free
-------------------------

The line 4 has a copy-paste error, corrupting a pointer q2.
>From there, several reads/writes exist on the corrupted location.
Let's suppose that at first the crash occurs at line 12, because of reading
illegal memory address.
The first definition of variable c is at line 11. We then suppress the line
11, and subsequent use of variable c(at line 12)
Now running this program results another crash at line 13. Use of p2/q2
results crash, so we suppress the definition of q2 at line 8, and
subsequent use of q2 - line 9 and 10.
Running this program again still have a crash, in line 15 because of double
free.
Suppressing the definition of q2 in line 4, and use of q2 in line 15,
running again then no crash occur,
So we can conclude that line 4 is the first location of memory corruption.


And about uninitialized pointers like Philippe you mentioned, you're right.
In that case it's not suppress-able.
But if there's a code like this -
--------------------------
void foo()
{
  char* pt1;
  char* pt2;

  pt1[0] = 'X';
  printf("%s\n", pt1);
}
--------------------------
The crash occurs at " pt1[0] = 'X'; " so we suppress this statement(since
there's no value assignment of pt1, this is the only suppression point)
and on the next run there would be no crash.
Therefore we can conclude using uninitialized pointer is the root cause of
the crash.



>

Re: [Valgrind-users] cross platform tool development

[Paolo P. <ppi...@cs...>]

On 8/26/13 4:34 PM, Konstantin Tokarev wrote:
>
> 26.08.2013, 19:18, "Paolo Piselli" <ppi...@cs...>:
>> Hi, I'm working on a Valgrind tool targeting 32-bit guests that up to
>> this point we have been running on 32-bit hosts.  I would like to also
>> be able to compile to target 32-bit guest on 64-bit host.  So far, the
>> largest difference that I have found is described in the comments of
>> "doHelperCall" in host_amd64_isel.c:
>>
>> "This function only deals with a tiny set of possibilities, which cover
>> all helpers in practice.  The restrictions are that only arguments in
>> registers are supported, hence only 6x64 integer bits in total can be
>> passed.  In fact the only supported arg type is I64."
>>
>> With this constraint in place, I was wondering if there were any
>> particular best-practices for cross platform tool development.  For
>> instance, we could promote all parameters for all tool callbacks to
>> 64-bit across all platforms to keep the code clean and uniform, or we
>> could maintain parallel platform-specific callback compilation units
>> that must be manually kept consistent across feature changes and bug
>> fixes, or we could throw a bunch of #ifdefs in the source to change the
>> function signatures and IExpr marshaling depending on platform.
>>
>> Any thoughts are appreciated!
> Why not just use 32-bit build of valgrind instead?
>

I have two concerns:

1. I am working on an analysis tool that can be quite memory intensive.  
I would ultimately like to be able to compile on 64-bit in order to 
perform analysis on larger inputs.

2. I have been going over the file 
"docs/internals/multiple-architectures.txt" and it is not clear how to 
force usage of the 32-bit build on dual-arch systems.  From what I 
gather from this doc, the launcher is always built 64-bit on a dual-arch 
system, and the host libraries to use are determined by the nature of 
the guest executable.  I am referring to this section specifically:

"The launcher program (ie the valgrind binary itself) is always built
as a program for the primary target (so a 64 bit program on amd64 and
ppc64) but will peek at the program which it is being asked to run and
decide which of the possible tools to run taking both the requested
tool and the format of the program being run into account."

If this is the case, then how is it possible to, on a 64-bit platform, 
tell valgrind to run as a 32-bit host even when executing a 64-bit 
guest?  Is the only way to do this to force a single-arch 32-bit build?

-Paolo

[Valgrind-users] Does "--read-var-info=yes" in the current release?

[ishikawa <ish...@yk...>]

Maybe I am missing something, but

I can't seem to get a decent symbolic dump with valgrind even when I use
--read-var-info=yes

--- quote from the valgrind manual ----
 --read-var-info=<yes|no> [default: no]

    When enabled, Valgrind will read information about variable types and
locations from DWARF3 debug info. This slows Valgrind down and makes it use
more memory, but for the tools that can take advantage of it (Memcheck,
Helgrind, DRD) it can result in more precise error messages. For example,
here are some standard errors issued by Memcheck:

    ==15516== Uninitialised byte(s) found during client check request
    ==15516==    at 0x400633: croak (varinfo1.c:28)
    ==15516==    by 0x4006B2: main (varinfo1.c:55)
    ==15516==  Address 0x60103b is 7 bytes inside data symbol "global_i2"
    ==15516==
    ==15516== Uninitialised byte(s) found during client check request
    ==15516==    at 0x400633: croak (varinfo1.c:28)
    ==15516==    by 0x4006BC: main (varinfo1.c:56)
    ==15516==  Address 0x7fefffefc is on thread 1's stack

    And here are the same errors with --read-var-info=yes:

    ==15522== Uninitialised byte(s) found during client check request
    ==15522==    at 0x400633: croak (varinfo1.c:28)
    ==15522==    by 0x4006B2: main (varinfo1.c:55)
    ==15522==  Location 0x60103b is 0 bytes inside global_i2[7],
    ==15522==  a global variable declared at varinfo1.c:41
    ==15522==
    ==15522== Uninitialised byte(s) found during client check request
    ==15522==    at 0x400633: croak (varinfo1.c:28)
    ==15522==    by 0x4006BC: main (varinfo1.c:56)
    ==15522==  Location 0x7fefffefc is 0 bytes inside local var "local"
    ==15522==  declared at varinfo1.c:46, in frame #1 of thread 1


--- end quote ---


But in real world, here is what happens.

ishikawa@debian-vbox-ci:~/repos/valgrind$ gcc --version
gcc (Debian 4.7.3-4) 4.7.3
Copyright (C) 2012 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

Here is the test program to see if symbolic name of the
memory area is printed by valgrind.

ishikawa@debian-vbox-ci:~/repos/valgrind$ cat test-split-dwarf.c
/*
 * gcc-4.8 -g -gsplit-dwarf -Wl,--gdb-index test-split-dwarf.c
 * then run the binary under valgrind.
 * Compare the output from valgrind when compile command is
 * simply
 * gcc test-gsplit-dwarf
 *
 */
#include <stdio.h>
#include <stdlib.h>


char *p;

int test()
{
  return p[10];
}

main() {
  int uninitialized_int10[10];
  int uninit_int1;
  int init_int2;
  init_int2 = 2;

  p = malloc(10);
  printf ("%d\n", test());

  if(uninitialized_int10[3])
    printf ("%d\n", uninitialized_int10[3]);

  if(uninit_int1)
    printf("%d, %d\n", init_int2, uninit_int1);

  * ((int *) 0) = 1;

  exit(EXIT_SUCCESS);
}
ishikawa@debian-vbox-ci:~/repos/valgrind$ gcc -g -g3 test-split-dwarf.c
ishikawa@debian-vbox-ci:~/repos/valgrind$ valgrind --version
valgrind-3.9.0.SVN

The line wrap is artifact of the e-mail client.

ishikawa@debian-vbox-ci:~/repos/valgrind$ valgrind --read-var-info=yes
--track-origins=yes ./a.out
==13189== Memcheck, a memory error detector
==13189== Copyright (C) 2002-2012, and GNU GPL'd, by Julian Seward et al.
==13189== Using Valgrind-3.9.0.SVN and LibVEX; rerun with -h for copyright info
==13189== Command: ./a.out
==13189==
==13189== Invalid read of size 1
==13189==    at 0x80484E7: test (test-split-dwarf.c:17)
==13189==    by 0x8048515: main (test-split-dwarf.c:27)
==13189==  Address 0x41fd032 is 0 bytes after a block of size 10 alloc'd
==13189==    at 0x4029FD0: malloc (vg_replace_malloc.c:291)
==13189==    by 0x804850B: main (test-split-dwarf.c:26)
==13189==
0
==13189== Conditional jump or move depends on uninitialised value(s)
==13189==    at 0x804852C: main (test-split-dwarf.c:29)
==13189==  Uninitialised value was created by a stack allocation
==13189==    at 0x80484F5: main (test-split-dwarf.c:20)
==13189==
==13189== Use of uninitialised value of size 4
==13189==    at 0x408EC4B: _itoa_word (_itoa.c:179)
==13189==    by 0x4092819: vfprintf (vfprintf.c:1648)
==13189==    by 0x4098F8E: printf (printf.c:34)
==13189==    by 0x8048541: main (test-split-dwarf.c:30)
==13189==  Uninitialised value was created by a stack allocation
==13189==    at 0x80484F5: main (test-split-dwarf.c:20)
==13189==
==13189== Conditional jump or move depends on uninitialised value(s)
==13189==    at 0x408EC53: _itoa_word (_itoa.c:179)
==13189==    by 0x4092819: vfprintf (vfprintf.c:1648)
==13189==    by 0x4098F8E: printf (printf.c:34)
==13189==    by 0x8048541: main (test-split-dwarf.c:30)
==13189==  Uninitialised value was created by a stack allocation
==13189==    at 0x80484F5: main (test-split-dwarf.c:20)
==13189==
==13189== Conditional jump or move depends on uninitialised value(s)
==13189==    at 0x408F99D: vfprintf (vfprintf.c:1648)
==13189==    by 0x4098F8E: printf (printf.c:34)
==13189==    by 0x8048541: main (test-split-dwarf.c:30)
==13189==  Uninitialised value was created by a stack allocation
==13189==    at 0x80484F5: main (test-split-dwarf.c:20)
==13189==
==13189== Conditional jump or move depends on uninitialised value(s)
==13189==    at 0x408FA19: vfprintf (vfprintf.c:1648)
==13189==    by 0x4098F8E: printf (printf.c:34)
==13189==    by 0x8048541: main (test-split-dwarf.c:30)
==13189==  Uninitialised value was created by a stack allocation
==13189==    at 0x80484F5: main (test-split-dwarf.c:20)
==13189==
==13189== Conditional jump or move depends on uninitialised value(s)
==13189==    at 0x40924EB: vfprintf (vfprintf.c:1648)
==13189==    by 0x4098F8E: printf (printf.c:34)
==13189==    by 0x8048541: main (test-split-dwarf.c:30)
==13189==  Uninitialised value was created by a stack allocation
==13189==    at 0x80484F5: main (test-split-dwarf.c:20)
==13189==
==13189== Conditional jump or move depends on uninitialised value(s)
==13189==    at 0x408FA70: vfprintf (vfprintf.c:1648)
==13189==    by 0x4098F8E: printf (printf.c:34)
==13189==    by 0x8048541: main (test-split-dwarf.c:30)
==13189==  Uninitialised value was created by a stack allocation
==13189==    at 0x80484F5: main (test-split-dwarf.c:20)
==13189==
==13189== Conditional jump or move depends on uninitialised value(s)
==13189==    at 0x408FAA9: vfprintf (vfprintf.c:1648)
==13189==    by 0x4098F8E: printf (printf.c:34)
==13189==    by 0x8048541: main (test-split-dwarf.c:30)
==13189==  Uninitialised value was created by a stack allocation
==13189==    at 0x80484F5: main (test-split-dwarf.c:20)
==13189==
134514130
==13189== Conditional jump or move depends on uninitialised value(s)
==13189==    at 0x8048547: main (test-split-dwarf.c:32)
==13189==  Uninitialised value was created by a stack allocation
==13189==    at 0x80484F5: main (test-split-dwarf.c:20)
==13189==
==13189== Use of uninitialised value of size 4
==13189==    at 0x408EC4B: _itoa_word (_itoa.c:179)
==13189==    by 0x4092819: vfprintf (vfprintf.c:1648)
==13189==    by 0x4098F8E: printf (printf.c:34)
==13189==    by 0x8048564: main (test-split-dwarf.c:33)
==13189==  Uninitialised value was created by a stack allocation
==13189==    at 0x80484F5: main (test-split-dwarf.c:20)
==13189==
==13189== Conditional jump or move depends on uninitialised value(s)
==13189==    at 0x408EC53: _itoa_word (_itoa.c:179)
==13189==    by 0x4092819: vfprintf (vfprintf.c:1648)
==13189==    by 0x4098F8E: printf (printf.c:34)
==13189==    by 0x8048564: main (test-split-dwarf.c:33)
==13189==  Uninitialised value was created by a stack allocation
==13189==    at 0x80484F5: main (test-split-dwarf.c:20)
==13189==
==13189== Conditional jump or move depends on uninitialised value(s)
==13189==    at 0x408F99D: vfprintf (vfprintf.c:1648)
==13189==    by 0x4098F8E: printf (printf.c:34)
==13189==    by 0x8048564: main (test-split-dwarf.c:33)
==13189==  Uninitialised value was created by a stack allocation
==13189==    at 0x80484F5: main (test-split-dwarf.c:20)
==13189==
==13189== Conditional jump or move depends on uninitialised value(s)
==13189==    at 0x408FA19: vfprintf (vfprintf.c:1648)
==13189==    by 0x4098F8E: printf (printf.c:34)
==13189==    by 0x8048564: main (test-split-dwarf.c:33)
==13189==  Uninitialised value was created by a stack allocation
==13189==    at 0x80484F5: main (test-split-dwarf.c:20)
==13189==
==13189== Conditional jump or move depends on uninitialised value(s)
==13189==    at 0x40924EB: vfprintf (vfprintf.c:1648)
==13189==    by 0x4098F8E: printf (printf.c:34)
==13189==    by 0x8048564: main (test-split-dwarf.c:33)
==13189==  Uninitialised value was created by a stack allocation
==13189==    at 0x80484F5: main (test-split-dwarf.c:20)
==13189==
==13189== Conditional jump or move depends on uninitialised value(s)
==13189==    at 0x408FA70: vfprintf (vfprintf.c:1648)
==13189==    by 0x4098F8E: printf (printf.c:34)
==13189==    by 0x8048564: main (test-split-dwarf.c:33)
==13189==  Uninitialised value was created by a stack allocation
==13189==    at 0x80484F5: main (test-split-dwarf.c:20)
==13189==
==13189== Conditional jump or move depends on uninitialised value(s)
==13189==    at 0x408FAA9: vfprintf (vfprintf.c:1648)
==13189==    by 0x4098F8E: printf (printf.c:34)
==13189==    by 0x8048564: main (test-split-dwarf.c:33)
==13189==  Uninitialised value was created by a stack allocation
==13189==    at 0x80484F5: main (test-split-dwarf.c:20)
==13189==
2, 134514059
==13189== Invalid write of size 4
==13189==    at 0x804856A: main (test-split-dwarf.c:35)
==13189==  Address 0x0 is not stack'd, malloc'd or (recently) free'd
==13189==
==13189==
==13189== Process terminating with default action of signal 11 (SIGSEGV)
==13189==  Access not within mapped region at address 0x0
==13189==    at 0x804856A: main (test-split-dwarf.c:35)
==13189==  If you believe this happened as a result of a stack
==13189==  overflow in your program's main thread (unlikely but
==13189==  possible), you can try to increase the size of the
==13189==  main thread stack using the --main-stacksize= flag.
==13189==  The main thread stack size used in this run was 8388608.
==13189==
==13189== HEAP SUMMARY:
==13189==     in use at exit: 10 bytes in 1 blocks
==13189==   total heap usage: 1 allocs, 0 frees, 10 bytes allocated
==13189==
==13189== LEAK SUMMARY:
==13189==    definitely lost: 0 bytes in 0 blocks
==13189==    indirectly lost: 0 bytes in 0 blocks
==13189==      possibly lost: 0 bytes in 0 blocks
==13189==    still reachable: 10 bytes in 1 blocks
==13189==         suppressed: 0 bytes in 0 blocks
==13189== Rerun with --leak-check=full to see details of leaked memory
==13189==
==13189== For counts of detected and suppressed errors, rerun with: -v
==13189== ERROR SUMMARY: 50 errors from 18 contexts (suppressed: 2 from 2)
Segmentation fault
ishikawa@debian-vbox-ci:~/repos/valgrind$

I wish valgrind prints the warnings by referring to the variable names if
possible. But it didn't. Why?

TIA

Re: [Valgrind-users] Question about Valgrind tool implementation

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

On Thu, 2013-09-05 at 16:01 +0900, Chang-Jae Lee wrote:
> Hi,
> 
> 
>  I am a grad-student in KAIST, and I'm working on a project for
> finding bugs or errors.
> Currently I'm following a routine from the paper "Execution
> Suppression: An Automated Iterative Technique for Locating Memory
> Errors." 
> It is about finding the root cause of memory error(s) when a program
> shows a crash, 
> by suppressing the code statement which defines that memory location 
> and subsequent statements using the location and restart the program,
> until no crash happens.
> So what I need here is,
> 
> 
> - How can I handle target application's segmentation fault in my tool?
> First I ran my target with Lackey and it gets SIGSEGV, alerts to me,
> and returns 0, but the last thing it does is saying that it was
> terminated with segmentation fault. here I attached the log of Lackey.

>From what I can see, you will have to modify Valgrind "core" to let
the tool "intercept" the guest signals.
At first sight, your tool might install a fault_catcher
using VG_(set_fault_catcher).
However, currently, such a fault catcher can only run in non generated
code (see sync_signalhandler_from_kernel). You might have to change
that.

Maybe some other changes will be needed (such as allowing the fault
catcher to indiate that the signal is not to be propagated.

You will find a current use of such a fault catcher in memcheck
(mc_leakcheck.c), but however not in generated code.



> 
> - I need to suppress instructions which stands for a single code
> statement, like defining pointers or accessing particular memory
> addresses.
> Looks like the core connects debug information if there is one. Then,
> how does the tool recognize it (like memcheck does)? Is VEX IR
> superblock contains about it?
Not too sure about what you mean with the above. Valgrind works
at binary level, it does not really have a notion of "statement".
For example, if in the code you have:
f()
{
   char *ptr1;
   char *ptr2;

these two "statements" will just be part of the stack setup
(e.g. change the stack pointer) and so there is no way to
"remove" the instruction corresponding to
e.g. only the first "ptr definition".


As I do not understand the tool you have to write, I have no idea
how to best do what you need.


Philippe

[Valgrind-users] Question about Valgrind tool implementation

[Chang-Jae L. <sik...@gm...>]

Hi,

 I am a grad-student in KAIST, and I'm working on a project for finding
bugs or errors.
Currently I'm following a routine from the paper "Execution Suppression: An
Automated Iterative Technique for Locating Memory Errors."
It is about finding the root cause of memory error(s) when a program shows
a crash,
by suppressing the code statement which defines that memory location
and subsequent statements using the location and restart the program, until
no crash happens.
So what I need here is,

- How can I handle target application's segmentation fault in my tool?
First I ran my target with Lackey and it gets SIGSEGV, alerts to me, and
returns 0, but the last thing it does is saying that it was terminated with
segmentation fault. here I attached the log of Lackey.

<
==16834== Lackey, an example Valgrind tool
==16834== Copyright (C) 2002-2012, and GNU GPL'd, by Nicholas Nethercote.
==16834== Using Valgrind-3.9.0.SVN and LibVEX; rerun with -h for copyright
info
==16834== Command: ./test1_x64
==16834==
==16834==
==16834== Process terminating with default action of signal 11 (SIGSEGV)
==16834==  Bad permissions for mapped region at address 0x4005D8
==16834==    at 0x400503: main (test1.c:13)
==16834==
==16834== Counted 1 call to main()
==16834==
==16834== Jccs:
==16834==   total:         14,169
==16834==   taken:         5,874 ( 41%)
==16834==
==16834== Executed:
==16834==   SBs entered:   14,440
==16834==   SBs completed: 9,214
==16834==   guest instrs:  82,505
==16834==   IRStmts:       483,662
==16834==
==16834== Ratios:
==16834==   guest instrs : SB entered  = 57 : 10
==16834==        IRStmts : SB entered  = 334 : 10
==16834==        IRStmts : guest instr = 58 : 10
==16834==
==16834== Exit code:       0
Segmentation fault (core dumped)
>


- I need to suppress instructions which stands for a single code statement,
like defining pointers or accessing particular memory addresses.
Looks like the core connects debug information if there is one. Then, how
does the tool recognize it (like memcheck does)? Is VEX IR superblock
contains about it?


Thank you in advance.

[Valgrind-users] (no subject)

[<la...@ii...>]

Hello,

              I want to do speculative loop paralleization on GPU.in which
i have to do dependency analysis and check if one iteration
of loop is reading some value and check that some other
iteration have written to same memory location general "read
after write" and "write after write" and "write after read"
detection.

I want to do it for GPU can i do it using valgrind tool

Plz Help

Thanks

[Valgrind-users] (no subject)

[<la...@ii...>]

Hello,

              I want to do speculative loop paralleization on GPU.in which
i have to do dependency analysis and check if one iteration
of loop is reading some value and check that some other
iteration have written to same memory location general "read
after write" and "write after write" and "write after read"
detection.

I want to do it for GPU can i do it using valgrind tool

Plz Help

Thanks

Re: [Valgrind-users] cross platform tool development

[Konstantin T. <an...@ya...>]

26.08.2013, 19:18, "Paolo Piselli" <ppi...@cs...>:
> Hi, I'm working on a Valgrind tool targeting 32-bit guests that up to
> this point we have been running on 32-bit hosts.  I would like to also
> be able to compile to target 32-bit guest on 64-bit host.  So far, the
> largest difference that I have found is described in the comments of
> "doHelperCall" in host_amd64_isel.c:
>
> "This function only deals with a tiny set of possibilities, which cover
> all helpers in practice.  The restrictions are that only arguments in
> registers are supported, hence only 6x64 integer bits in total can be
> passed.  In fact the only supported arg type is I64."
>
> With this constraint in place, I was wondering if there were any
> particular best-practices for cross platform tool development.  For
> instance, we could promote all parameters for all tool callbacks to
> 64-bit across all platforms to keep the code clean and uniform, or we
> could maintain parallel platform-specific callback compilation units
> that must be manually kept consistent across feature changes and bug
> fixes, or we could throw a bunch of #ifdefs in the source to change the
> function signatures and IExpr marshaling depending on platform.
>
> Any thoughts are appreciated!

Why not just use 32-bit build of valgrind instead?

-- 
Regards,
Konstantin

[Valgrind-users] Next Valgrind Release?

[Paralkar Anmol-B. <B0...@fr...>]

Hello,

 When could we expect the next Valgrind release?

Thanks,
Anmol P. Paralkar

[Valgrind-users] cross platform tool development

[Paolo P. <ppi...@cs...>]

Hi, I'm working on a Valgrind tool targeting 32-bit guests that up to 
this point we have been running on 32-bit hosts.  I would like to also 
be able to compile to target 32-bit guest on 64-bit host.  So far, the 
largest difference that I have found is described in the comments of 
"doHelperCall" in host_amd64_isel.c:

"This function only deals with a tiny set of possibilities, which cover 
all helpers in practice.  The restrictions are that only arguments in 
registers are supported, hence only 6x64 integer bits in total can be 
passed.  In fact the only supported arg type is I64."

With this constraint in place, I was wondering if there were any 
particular best-practices for cross platform tool development.  For 
instance, we could promote all parameters for all tool callbacks to 
64-bit across all platforms to keep the code clean and uniform, or we 
could maintain parallel platform-specific callback compilation units 
that must be manually kept consistent across feature changes and bug 
fixes, or we could throw a bunch of #ifdefs in the source to change the 
function signatures and IExpr marshaling depending on platform.

Any thoughts are appreciated!

- Paolo

Re: [Valgrind-users] using valgrind at specific point while running program

[Vasily G. <vas...@gm...>]

Yes, unfortunately, you are right. Since Valgrind binary translates your
program and track all memory read\write you have to run Memcheck at the
start of your program.
Maybe you can somehow reduce run path of your program changing some
functions to simpler one. So, my point is - try to localize problem fix it
and run full test (2,5 hours) only once.

Vasily


On Mon, Aug 26, 2013 at 5:17 PM, Mahmood Naderan <nt_...@ya...>wrote:

>
> >What particular tool would you like to use (Memcheck, Callgrind, Massif)?
>
> Unfortunately I want to use memcheck which seems to be impossible
>
> Regards,
> Mahmood*
> *
>
>   ------------------------------
>  *From:* Vasily Golubev <vas...@gm...>
> *To:* "val...@li..." <
> val...@li...>
> *Sent:* Monday, August 26, 2013 5:12 PM
>
> *Subject:* Re: [Valgrind-users] using valgrind at specific point while
> running program
>
> Hello, Mr. Naderan.
>
> What particular tool would you like to use (Memcheck, Callgrind, Massif)?
> If callgrind - you can switch off instrumentation at the start and then
> switch it on at some particular point (or time). In any case, at first -
> please test your program with:
> valgrind --tool=none ./path-to-your-program
> If it spends a lot of time then probably Valgrind (like Memcheck, Massif,
> etc) is useless for you because of time constrains.
> I mean: None - is the fastest tool of Valgrind. It doesn't detect any
> errors, simply run your code.
> If it runs quite fast (for you) and you want to collect only call-graph
> (use Callgrind) - then you can look at parameters for Callgrind.
>
> Vasily
>
>
> On Mon, Aug 26, 2013 at 12:00 PM, Mahmood Naderan <nt_...@ya...>wrote:
>
> Thanks. To be honest, I didn't understand!
> It seems that with these macros, I can insert them in the specific section
> of the code. However my problem is different. There are iterative
> functions. So I want to start valgrind after, say, 0.5 hours of execution
> to see what is going on.
>
>
> Regards,
> Mahmood
>
>
>
> ----- Original Message -----
> From: Konstantin Tokarev <an...@ya...>
> To: Mahmood Naderan <nt_...@ya...>; "
> val...@li..." <
> val...@li...>
> Cc:
> Sent: Monday, August 26, 2013 12:17 PM
> Subject: Re: [Valgrind-users] using valgrind at specific point while
> running program
>
>
>
> 26.08.2013, 11:45, "Mahmood Naderan" <nt_...@ya...>:
> > I want to use valrgind at a specific time while my program is running.
> For example, when I use -O3 it will take 0.5 hours to reach the desired
> point. When I use -g -ggdb it will take nearly 2.5 hours to reach the
> desired point.
> >
> > Now if I use valgrind with -g -ggdb, the program is extremely slow and I
> can not predict when it reach the desired point.
> > What should I do?
>
> Use client requests:
>
> http://valgrind.org/docs/manual/manual-core-adv.html
>
> --
> Regards,
> Konstantin
>
>
>
> ------------------------------------------------------------------------------
> Introducing Performance Central, a new site from SourceForge and
> AppDynamics. Performance Central is your source for news, insights,
> analysis and resources for efficient Application Performance Management.
> Visit us today!
> http://pubads.g.doubleclick.net/gampad/clk?id=48897511&iu=/4140/ostg.clktrk
> _______________________________________________
> Valgrind-users mailing list
> Val...@li...
> https://lists.sourceforge.net/lists/listinfo/valgrind-users
>
>
>
>
> --
> Best Regards,
> Vasily
>
>
> ------------------------------------------------------------------------------
> Introducing Performance Central, a new site from SourceForge and
> AppDynamics. Performance Central is your source for news, insights,
> analysis and resources for efficient Application Performance Management.
> Visit us today!
> http://pubads.g.doubleclick.net/gampad/clk?id=48897511&iu=/4140/ostg.clktrk
> _______________________________________________
> Valgrind-users mailing list
> Val...@li...
> https://lists.sourceforge.net/lists/listinfo/valgrind-users
>
>
>


-- 
Best Regards,
Vasily

Re: [Valgrind-users] using valgrind at specific point while running program

[Mahmood N. <nt_...@ya...>]

>What particular tool would you like to use (Memcheck, Callgrind, Massif)? 

Unfortunately I want to use memcheck which seems to be impossible


Regards,
Mahmood



________________________________
 From: Vasily Golubev <vas...@gm...>
To: "val...@li..." <val...@li...> 
Sent: Monday, August 26, 2013 5:12 PM
Subject: Re: [Valgrind-users] using valgrind at specific point while running	program
 


Hello, Mr. Naderan.

What particular tool would you like to use (Memcheck, Callgrind, Massif)? If callgrind - you can switch off instrumentation at the start and then switch it on at some particular point (or time). In any case, at first - please test your program with:
valgrind --tool=none ./path-to-your-program
If it spends a lot of time then probably Valgrind (like Memcheck, Massif, etc) is useless for you because of time constrains.
I mean: None - is the fastest tool of Valgrind. It doesn't detect any errors, simply run your code.
If it runs quite fast (for you) and you want to collect only call-graph (use Callgrind) - then you can look at parameters for Callgrind.

Vasily




On Mon, Aug 26, 2013 at 12:00 PM, Mahmood Naderan <nt_...@ya...> wrote:

Thanks. To be honest, I didn't understand!
>It seems that with these macros, I can insert them in the specific section of the code. However my problem is different. There are iterative functions. So I want to start valgrind after, say, 0.5 hours of execution to see what is going on.
>
> 
>Regards,
>Mahmood
>
>
>
>
>----- Original Message -----
>From: Konstantin Tokarev <an...@ya...>
>To: Mahmood Naderan <nt_...@ya...>; "val...@li..." <val...@li...>
>Cc:
>Sent: Monday, August 26, 2013 12:17 PM
>Subject: Re: [Valgrind-users] using valgrind at specific point while running program
>
>
>
>26.08.2013, 11:45, "Mahmood Naderan" <nt_...@ya...>:
>> I want to use valrgind at a specific time while my program is running. For example, when I use -O3 it will take 0.5 hours to reach the desired point. When I use -g -ggdb it will take nearly 2.5 hours to reach the desired point.
>>
>> Now if I use valgrind with -g -ggdb, the program is extremely slow and I can not predict when it reach the desired point.
>> What should I do?
>
>Use client requests:
>
>http://valgrind.org/docs/manual/manual-core-adv.html
>
>--
>Regards,
>Konstantin
>
>
>------------------------------------------------------------------------------
>Introducing Performance Central, a new site from SourceForge and
>AppDynamics. Performance Central is your source for news, insights,
>analysis and resources for efficient Application Performance Management.
>Visit us today!
>http://pubads.g.doubleclick.net/gampad/clk?id=48897511&iu=/4140/ostg.clktrk
>_______________________________________________
>Valgrind-users mailing list
>Val...@li...
>https://lists.sourceforge.net/lists/listinfo/valgrind-users
>


-- 
Best Regards,
Vasily

------------------------------------------------------------------------------
Introducing Performance Central, a new site from SourceForge and 
AppDynamics. Performance Central is your source for news, insights, 
analysis and resources for efficient Application Performance Management. 
Visit us today!
http://pubads.g.doubleclick.net/gampad/clk?id=48897511&iu=/4140/ostg.clktrk
_______________________________________________
Valgrind-users mailing list
Val...@li...
https://lists.sourceforge.net/lists/listinfo/valgrind-users

Re: [Valgrind-users] using valgrind at specific point while running program

[Vasily G. <vas...@gm...>]

Hello, Mr. Naderan.

What particular tool would you like to use (Memcheck, Callgrind, Massif)?
If callgrind - you can switch off instrumentation at the start and then
switch it on at some particular point (or time). In any case, at first -
please test your program with:
valgrind --tool=none ./path-to-your-program
If it spends a lot of time then probably Valgrind (like Memcheck, Massif,
etc) is useless for you because of time constrains.
I mean: None - is the fastest tool of Valgrind. It doesn't detect any
errors, simply run your code.
If it runs quite fast (for you) and you want to collect only call-graph
(use Callgrind) - then you can look at parameters for Callgrind.

Vasily


On Mon, Aug 26, 2013 at 12:00 PM, Mahmood Naderan <nt_...@ya...>wrote:

> Thanks. To be honest, I didn't understand!
> It seems that with these macros, I can insert them in the specific section
> of the code. However my problem is different. There are iterative
> functions. So I want to start valgrind after, say, 0.5 hours of execution
> to see what is going on.
>
>
> Regards,
> Mahmood
>
>
>
> ----- Original Message -----
> From: Konstantin Tokarev <an...@ya...>
> To: Mahmood Naderan <nt_...@ya...>; "
> val...@li..." <
> val...@li...>
> Cc:
> Sent: Monday, August 26, 2013 12:17 PM
> Subject: Re: [Valgrind-users] using valgrind at specific point while
> running program
>
>
>
> 26.08.2013, 11:45, "Mahmood Naderan" <nt_...@ya...>:
> > I want to use valrgind at a specific time while my program is running.
> For example, when I use -O3 it will take 0.5 hours to reach the desired
> point. When I use -g -ggdb it will take nearly 2.5 hours to reach the
> desired point.
> >
> > Now if I use valgrind with -g -ggdb, the program is extremely slow and I
> can not predict when it reach the desired point.
> > What should I do?
>
> Use client requests:
>
> http://valgrind.org/docs/manual/manual-core-adv.html
>
> --
> Regards,
> Konstantin
>
>
>
> ------------------------------------------------------------------------------
> Introducing Performance Central, a new site from SourceForge and
> AppDynamics. Performance Central is your source for news, insights,
> analysis and resources for efficient Application Performance Management.
> Visit us today!
> http://pubads.g.doubleclick.net/gampad/clk?id=48897511&iu=/4140/ostg.clktrk
> _______________________________________________
> Valgrind-users mailing list
> Val...@li...
> https://lists.sourceforge.net/lists/listinfo/valgrind-users
>



-- 
Best Regards,
Vasily

Re: [Valgrind-users] using valgrind at specific point while running program

[Jonatan W. <jo...@vo...>]

On 08/26/2013 10:00 AM, Mahmood Naderan wrote:
> Thanks. To be honest, I didn't understand!
> It seems that with these macros, I can insert them in the specific section of the code. However my problem is different. There are iterative functions. So I want to start valgrind after, say, 0.5 hours of execution to see what is going on.
Sorry, don't think that's possible - valgrind has to run from the 
start... Since it's a VM after all.
One thing I've done is to use multi-threading whenever possible - 
valgrind runs in multipe threads as well.. That can speed up the time 
for your program.

/jaw

Re: [Valgrind-users] using valgrind at specific point while running program

[Konstantin T. <an...@ya...>]

26.08.2013, 12:00, "Mahmood Naderan" <nt_...@ya...>:
> Thanks. To be honest, I didn't understand!
> It seems that with these macros, I can insert them in the specific section of the code. However my problem is different. There are iterative functions. So I want to start valgrind after, say, 0.5 hours of execution to see what is going on.

Sorry, I misunderstood your query. If all you need is to know current execution point, use vgdb (the same link). You can attach gdb to the running program and check backtrace.

-- 
Regards,
Konstantin

Re: [Valgrind-users] using valgrind at specific point while running program

[Mahmood N. <nt_...@ya...>]

Thanks. To be honest, I didn't understand!
It seems that with these macros, I can insert them in the specific section of the code. However my problem is different. There are iterative functions. So I want to start valgrind after, say, 0.5 hours of execution to see what is going on.

 
Regards,
Mahmood



----- Original Message -----
From: Konstantin Tokarev <an...@ya...>
To: Mahmood Naderan <nt_...@ya...>; "val...@li..." <val...@li...>
Cc: 
Sent: Monday, August 26, 2013 12:17 PM
Subject: Re: [Valgrind-users] using valgrind at specific point while running program



26.08.2013, 11:45, "Mahmood Naderan" <nt_...@ya...>:
> I want to use valrgind at a specific time while my program is running. For example, when I use -O3 it will take 0.5 hours to reach the desired point. When I use -g -ggdb it will take nearly 2.5 hours to reach the desired point.
>
> Now if I use valgrind with -g -ggdb, the program is extremely slow and I can not predict when it reach the desired point.
> What should I do?

Use client requests:

http://valgrind.org/docs/manual/manual-core-adv.html

-- 
Regards,
Konstantin

Re: [Valgrind-users] using valgrind at specific point while running program

[Konstantin T. <an...@ya...>]

26.08.2013, 11:45, "Mahmood Naderan" <nt_...@ya...>:
> I want to use valrgind at a specific time while my program is running. For example, when I use -O3 it will take 0.5 hours to reach the desired point. When I use -g -ggdb it will take nearly 2.5 hours to reach the desired point.
>
> Now if I use valgrind with -g -ggdb, the program is extremely slow and I can not predict when it reach the desired point.
> What should I do?

Use client requests:

http://valgrind.org/docs/manual/manual-core-adv.html

-- 
Regards,
Konstantin

[Valgrind-users] using valgrind at specific point while running program

[Mahmood N. <nt_...@ya...>]

I want to use valrgind at a specific time while my program is running. For example, when I use -O3 it will take 0.5 hours to reach the desired point. When I use -g -ggdb it will take nearly 2.5 hours to reach the desired point. 


Now if I use valgrind with -g -ggdb, the program is extremely slow and I can not predict when it reach the desired point.
What should I do?

Regards,
Mahmood

Re: [Valgrind-users] question on valgrind's configure and build process

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

On 22/08/13 22:16, janjust wrote:

> 19 vex amd64->IR: unhandled instruction bytes: vex amd64->IR: unhandled
> instruction bytes: 0x8F 0xE8 0x78 0xA2 0xC1 0x40 0xC5 0xFB

That's a XOP instruction which is an AMD specific extension that I don't 
believe valgrind currently supports. See:

http://en.wikipedia.org/wiki/XOP_instruction_set

Tom

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

Re: [Valgrind-users] question on valgrind's configure and build process

[janjust <tja...@un...>]

I forgot to mention that I used a pgi compiler in the previous run, if I swap
my modules and use a gnu compiler environment it still breaks but this time
the unhandled instruction bytes are a different:

I'm not sure sure if the significance of this other than unhandled
instructions?

19 vex amd64->IR: unhandled instruction bytes: vex amd64->IR: unhandled
instruction bytes: 0x8F 0xE8 0x78 0xA2 0xC1 0x40 0xC5 0xFB
 20 vex amd640
 21 vex amd64->IR:   VEX=0 VEX.L=0 VEX.nVVVV=0x
 22 vex amd64
 23 vex amd64->IR:   PFX.66=0 PFX.F2=0 PFX.F3=0
 24 vex amd64->IR:   PFX.66=0 PFX.F2=0 PFX.F3=0
 25 3=0
 26 vex amd64->IR: unhandled instruction bytes: 0x8F 0xE8 0x78 0xA2 0xC1
0x40 0xC5 0xFB
 27 vex amd64->IR:   REX=0 REX.W=0 REX.R=0 REX.X=0 REX.B=0
 28 vex amd64->IR:   VEX=0 VEX.L=0 VEX.nVVVV=0x0 ESC=NONE
 29 vex amd64->IR:   PFX.66=0 PFX.F2=0 PFX.F3=0
 30 ==19226== valgrind: Unrecognised instruction at address 0x402ed7.
 31 ==19228== valgrind: Unrecognised instruction at address 0x402ed7.
 32 vex amd64->IR: unhandled instruction bytes: 0x8F 0xE8 0x78 0xA2 0xC1
0x40 0xC5 0xFB
 33 vex amd64->IR:   REX=0 REX.W=0 REX.R=0 REX.X=0 REX.B=0
 34 vex amd64->IR:   VEX=0 VEX.L=0 VEX.nVVVV=0x0 ESC=NONE
 35 vex amd64->IR:   PFX.66=0 PFX.F2=0 PFX.F3=0

-Tommy




--
View this message in context: http://valgrind.10908.n7.nabble.com/question-on-valgrind-s-configure-and-build-process-tp46406p46408.html
Sent from the Valgrind - Users mailing list archive at Nabble.com.

Re: [Valgrind-users] question on valgrind's configure and build process

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

On 22/08/13 20:58, janjust wrote:

>   If certain instructions are not detected through configure process, does
> that imply that a valgrind build will not be configured to handle these
> instructions (i.e. fail at runtime)?

No - those tests mostly only govern which bits of the test suite will be 
built and run. The actual emulation engine checks at run time which 
instructions are supported.

> 21 vex amd64->IR: unhandled instruction bytes: 0xC4 0xE3 0xF1 0x6B 0x15 0x12
> 0x4 0x0
> 22 vex amd64->IR:   REX=0 REX.W=1 REX.R=0 REX.X=0 REX.B=0
> 23 vex amd64->IR:   VEX=1 VEX.L=0 VEX.nVVVV=0x1 ESC=0F3A
> 24 vex amd64->IR:   PFX.66=1 PFX.F2=0 PFX.F3=0
> 25 3=0

That (in effect 66 0F 3A 6B) appears to be undefined in the latest Intel 
manual so I'm guessing it's some AMD extension... That said it doesn't 
seem to be defined in the AMD manual either which is a little confusing...

Tom

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