valgrind-users — General discussion list for Valgrind users

Re: [Valgrind-users] Marking blocks as write-once/grow-only

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

> Is it possible for the DRD/Helgrind tools to detect this sort of
> double-write access behaviour?

Both of them should be able to detect a write-vs-write race, if
that's what you mean.

> Could I instrument QEMU so it marked the
> codegen buffer as one that should only grow upwards (modulo-patchable
> bits) so if anything re-wrote the buffer it could trigger an error?

This is confusing.  Both tools are able to detect races at a byte level
granularity.  If you can show that QEMU doesn't race on individual writes
to its code buffer, isn't that good enough from a correctness perspective?

J

[Valgrind-users] VG_(message) floating points

[Domingues L. F. <Lui...@ed...>]

Hello,

On a tool, I try to print on the stdout the value of a floating point.
But when I use the %f formating in VG(printf) or VG_(message) it print
my string, but not my float/double.

It is a bug? Or there are another way to print floating points?

Regards,
Luis Domingues

[Valgrind-users] NCSU Survey Invitation

[Jim W. <jim...@nc...>]

Hi, Valgrind users! This is Jim Witschey and Dr. Emerson Murphy-Hill. 
We're researchers at North Carolina State University, and we'd like to 
ask you some questions about Valgrind and other tools that can help 
developers find security vulnerabilities.

If you are among the first 50 members of this mailing list to 
participate in this survey, you will receive a $15 Amazon gift card. If 
you want to participate, please click this link:

http://ncsu.qualtrics.com//SE/?SID=SV_eSaATLVmzGnubt3

Your responses will be anonymous. Thanks for your consideration! Again, 
if you'd like to participate, follow this link:

http://ncsu.qualtrics.com//SE/?SID=SV_eSaATLVmzGnubt3

Best,

Jim Witschey and Dr. Emerson Murphy-Hill

Re: [Valgrind-users] valgrind breaks any long double operation on x86-64

[Alex B. <ker...@be...>]

Irek Szczesniak <isz...@gm...> writes:

> On Thu, Jan 23, 2014 at 11:12 AM, Dallman, John
> <joh...@si...> wrote:
>>> Do any common platforms, other than x86/x86_64, offer more-than-64-bit "long double"?
>>
>> Not that they support as full speed hardware operations, AFAIK. SPARC has defined
>> registers and instructions for 128-bit floating point, but implements them as
>> sequences of operations on 64-bit floats, so they aren't terribly fast.
>
<snip>
> 3. Some SPARC emulators like Transitive implement full SPARCV9 128bit
> floating point instruction support, i.e. using the SPARCV9
> instructions directly results in faster execution than going through
> the libc wrappers and have them executed by Transitive
<snip>

FWIW the Transitive DBT also had to disable the generation of x87 code
by the compiler as it could seriously screw up NaN propagation when
interpreting SPARC floating point instructions. 

-- 
Alex Bennée

[Valgrind-users] Marking blocks as write-once/grow-only

[Alex B. <ker...@be...>]

Hi,

I was recently using Valgrind to investigate some issues with QEMU's
multi-threading behaviour. One problem was without locking the code
generator multiple threads started accessing the codegen buffer and
hilarity ensued.

Is it possible for the DRD/Helgrind tools to detect this sort of
double-write access behaviour? Could I instrument QEMU so it marked the
codegen buffer as one that should only grow upwards (modulo-patchable
bits) so if anything re-wrote the buffer it could trigger an error?

-- 
Alex Bennée

Re: [Valgrind-users] (unavoidable) false positive?

[Shachar S. <sh...@sh...>]

The following email contains discussion that can best be described as
"academic". If theoreticals are not for you, do yourself a favor and hit
"delete" right now.

On 05/05/14 02:26, John Reiser wrote:
> The *easy* way to avoid hassle is to clear any union (or struct which suffers
> alignment or padding) immediately after declaration:
> 	memset(&u, 0, sizeof(u));
> In addition to keeping memcheck quiet, this tends to increase the reproducibility
> of any bugs, and to insulate the application from unpleasant interactions
> when the protocol gets enhanced or extended.  Of course, the memset also
> tends to mask any actual uninit errors.  But these tend to be caught
> by other means because typically they cause incorrect results.
>
>
While I don't have any particular issue with valgrind reporting this
particular case as a problem (though I still think it is, at its core, a
false positive), I think the off handedness with which you offer memset
as an *easy* alternative is over-simplifying things.

Please consider the following rather simple C++ program:

> class A { char a; public: explicit A( char chr ) : a(chr) { } }; class
> B : public A { int b; public: explicit B( char chr ) : A(chr),
> b(chr+1) { } }; B func(int fd, char chr) { // Point 1 B b(chr); //
> Point 2 write(fd, &b, sizeof(B)); return b; } 

sizeof(A) is 1, but sizeof(B) is 8 (i.e. - three bytes of padding).
Despite the fact that the constructor initializes each and every member
of the type, there are three uninitialized bytes in each instance of B.
During the write, valgrind, correctly, complains about them.

Adding memset to this mix, however, is far from trivial. You cannot do
it in the constructor for A for three reasons:

 1. It is bad design. A doesn't have any padding.
 2. A doesn't know the size of the final object being allocated (B)
 3. A can only run the memset in the constructor's body, by which time
    its members are already initialized.

You cannot do it in the constructor for B because:

 4. B still doesn't know that it's the final object. Someone might be
    inheriting from it. They may need to repeat the memset, costing us
    unnecessary performance.
 5. By the time B's constructor runs, both the A instance inside B, as
    well as all of the members, are already initialized (same as point 3
    above)

You cannot do it by overloading the new operator, because, as is the
case here, B might be created on the stack.

You cannot do it in point 1, as at that point b has no storage
associated with it.

You cannot do it in point 2, as at that point b is already fully
constructed.

You options are, as far as I can see them:
Change B's constructor to read:

>     explicit B( char chr ) : A((memset(this, 0, sizeof(B)), chr)),
> b(chr+1)
>     {
>     }
This is ugly, hard to maintain (you'd need to do it to each constructor
individually), easy to miss, and uses an operator few remember exists,
and fewer still understand (the comma operator, unchanged from its C
days, and equally unused). This also suffers from problem 4 above.

You can use placement new. Replace the line between point 1 and point 2
with:

>     char b_storage[sizeof(B)];     memset(b_storage, 0, sizeof(B));
>     B &b( *new (b_storage) (chr) );     ScopeGuard b_guard( [b]()
> mutable { b.~B() } );

(this is C++11 code. With pre-C++11, this would be even uglier and less
readable).

The last option is to turn the padding explicit:

> class B : public A { char pad1, pad2, pad3; int b; public: explicit B(
> char chr ) : A(chr), pad1(0), pad2(0), pad3(0), b(chr+1) { } }; 

This code creates a dependency between B's implementation and A's
implementation, relies on alignment requirements of specific platforms,
and relies on undefined compiler behavior.

In the long run, all of the above solutions are much more likely to
cause bugs than to fix them.

The good news is that the more code uses constructs such as self
initializing data members, the less likely it is to have actual use of
uninitialized data. The same undefined behavior that cases the third
solution to be unacceptable also makes it unlikely that it would be okay
to send the buffer, byte for byte, to sendto. Cases such as fakeroot-ng,
where the process is guaranteed to be communicating with code run from
the same executable, should be very rare.

The point I was trying to make was that memset, while a good solution
for many of the cases, is not something that is always applicable.

Shachar

P.s.
If you feel you have just wasted three minutes of your time reading a
long complicated email with no action items attached to it, then you
should have listened to my advice from the first paragraph of the email :-)

[Valgrind-users] Get Function call arguments

[Domingues L. F. <Lui...@ed...>]

Hello,

I'm making a tool where I need to intercept function calls. I can do
that, I was inspired by the lackely tool, using the
VG_(get_fnname_if_entry) function.

But I don't know how to read the arguments values. I know how many
parameters the function has. How can I read the arguments values? Did I
need to read the stack or the registers?

I'm using Valgring 3.9 on Linux amd64.

Regards,
Luis Domingues

Re: [Valgrind-users] (unavoidable) false positive?

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

> The source of the error seems to be padding and data variables not used in my particular scenario. While it's true they are passed, uninitialized, to "sendto", the other end will parse them according to the same criteria, and will also ignore them.
> 
> Since the other end of this socket is a process also managed by the same valgrind instance, it is theoretically possible for valgrind to postpone the error report until actual use after the read. I'm not sure that is a useful application of the developer's time, however.

According to the manual page (man 2 send), "The only difference between send()
and write(2) is the presence of flags."  Therefore memcheck correctly complains
about uninitialized bytes among the data that is written into the socket.
Once the bytes have been written there is no way to know how the values
will be used or ignored by any receiver at the other end.
Memcheck must assume that every byte is used.

Socketcall() is particularly nasty.  It multiplexes sa everal functions into
one system call by passing a structure that contains a "control packet"
with flags and variable bytes.  Correctly interpreting the control packet
requires pages of code which duplicate the kernel's logic for implementing
socketcall.  It is particularly difficult to discover the dataflow
for error conditions.

The easy way to avoid hassle is to clear any union (or struct which suffers
alignment or padding) immediately after declaration:
	memset(&u, 0, sizeof(u));
In addition to keeping memcheck quiet, this tends to increase the reproducibility
of any bugs, and to insulate the application from unpleasant interactions
when the protocol gets enhanced or extended.  Of course, the memset also
tends to mask any actual uninit errors.  But these tend to be caught
by other means because typically they cause incorrect results.

[Valgrind-users] (unavoidable) false positive?

[Shachar S. <sh...@sh...>]

Hi all,

I'm running Valgrind on fakeroot-ng (which used to be not possible, so
kudus!) and getting the following error:
==23945== Thread 3:
==23945== Syscall param socketcall.sendto(msg) points to uninitialised
byte(s)
==23945==    at 0x6368EFB: send (send.c:31)
==23945==    by 0x43FC20:
SyscallHandlerTask::proxy_call(std::function<void ()> const&)
(parent.cpp:211)
==23945==    by 0x43DD9B: pid_state::end_handling() (parent.cpp:708)
==23945==    by 0x44649B: sys_getuid(int, int, pid_state*)
(credentials.cpp:32)
==23945==    by 0x4404D3: SyscallHandlerTask::process_syscall()
(parent.cpp:310)
==23945==    by 0x43FB7D: SyscallHandlerTask::run() (parent.cpp:202)
==23945==    by 0x4332A9: worker_queue::worker() (worker_queue.cpp:97)
==23945==    by 0x437808: void std::_Mem_fn<void
(worker_queue::*)()>::operator()<, void>(worker_queue*) const (in
/home/sun/sources/myfoss/fakeroot-ng/git/build_dbg/fakeroot-ng)
==23945==    by 0x437758: void std::_Bind_simple<std::_Mem_fn<void
(worker_queue::*)()>
(worker_queue*)>::_M_invoke<0ul>(std::_Index_tuple<0ul>) (functional:1732)
==23945==    by 0x437660: std::_Bind_simple<std::_Mem_fn<void
(worker_queue::*)()> (worker_queue*)>::operator()() (functional:1720)
==23945==    by 0x4375F9:
std::thread::_Impl<std::_Bind_simple<std::_Mem_fn<void
(worker_queue::*)()> (worker_queue*)> >::_M_run() (thread:115)
==23945==    by 0x5BEC9BF: ??? (in
/usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.20)
==23945==  Address 0x8980ad4 is on thread 3's stack

This is generated by the following code:
http://sourceforge.net/p/fakerootng/source/ci/754928033faa0f235df244744d12e5d2da2fb55b/tree/parent.cpp#l211

thread_request is defined like so:

struct thread_request {
    enum request_type {
        THREADREQ_PTRACE,
        THREADREQ_PROXYCALL,
    } request;

    union {
        struct {
            __ptrace_request request;
            pid_t pid;
            void *addr;
            void *data;
        } ptrace;
        struct {
            const std::function< void() > *worker;
        } proxy;
    } u;
};

The source of the error seems to be padding and data variables not used
in my particular scenario. While it's true they are passed,
uninitialized, to "sendto", the other end will parse them according to
the same criteria, and will also ignore them.

Since the other end of this socket is a process also managed by the same
valgrind instance, it is theoretically possible for valgrind to postpone
the error report until actual use after the read. I'm not sure that is a
useful application of the developer's time, however.

I just wanted to make sure that:
1. This is, indeed, a false positive (i.e. - that I'm not missing
something important).
and
2. That there is nothing to do about it.

Thanks,
Shachar

Re: [Valgrind-users] --tool help not too helpful

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

On Wed, 2014-04-30 at 15:44 -0500, Skip Montanaro wrote:
> > In the next valgrind version, the man page (and the corresponding place
> > in the user manual) will now be:
> >
> >   ...
> >   TOOL SELECTION OPTIONS
> >        The single most important option.
> >
> >        --tool=<toolname> [default: memcheck]
> >            Run the Valgrind tool called toolname, e.g. memcheck, cachegrind, callgrind,
> >            helgrind, drd, massif, lackey, none, exp-sgcheck, exp-bbv, exp-dhat, etc.
> >    ...
> 
> That will be great. The version I have available (3.7.0 - which I'm
> sure is ancient in developers' terms, but it's what was provided with
> openSUSE 12.2) only mentions that first line in the --help output, and
> just a smidgen more in the man page:
> 
>        --tool=<toolname> [default: memcheck]
>            Run the Valgrind tool called toolname, e.g. Memcheck, Cachegrind,
>            etc.
Note that I have changed the manual and the man page,
but the --help output is *not* changed.

Philippe

Re: [Valgrind-users] --tool help not too helpful

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

On Wed, 2014-04-30 at 15:27 +0000, Skip Montanaro wrote:
> I went to file a bug report but was thwarted by the need to create yet
> another login to file a simple bug, and find Bugzilla an almost
> insurmountable hurdle anyway, so I will just mention my issues and
> suggestions here, and hope someone better tied into Valgrind development
> will pass it along. (That said, as a former Python core developer, I
> realize the need/desire for login credentials.)
> 
> I am a brand new Valgrind user, afflicted with some threading problems. I
> knew about the "memcheck" tool, but didn't know what any of the other
> tools were. While reading the man page, I saw mention of the Helgrind and
> DRD tools. "Great!" I thought. Alas, specifying "--tool=Helgrind" or
> "--tool=DRD" on the command line resulted in rather vague error:
> 
> ... failed to start tool '<whatever>' for platform 'amd64-linux': ...
> 
> Initially, I thought those tools were simply not available on my
> platform. Eventually, though, I figured out that tool names must be given
> in lower case. "Helgrind" and "DRD" appear to only be given with those
> spellings. I saw one instance of "helgrind" in the man page, but it was
> part of a larger compound word. I saw no mention of "drd".
> 
> Further, I saw no enumeration of all the available tools. The --help
> output says that "memcheck" is the default tool. Any mention in --help
> output of other tools was secondary (mentioning tools which support
> various options).
> 
> So, my recommendations:
> 
> 1. Briefly enumerate all the possible tools somewhere, together in one
> place. This would be great in the man page. I think it would be less
> important in the --help output.
In the next valgrind version, the man page (and the corresponding place
in the user manual) will now be:

  ...
  TOOL SELECTION OPTIONS
       The single most important option.

       --tool=<toolname> [default: memcheck]
           Run the Valgrind tool called toolname, e.g. memcheck, cachegrind, callgrind,
           helgrind, drd, massif, lackey, none, exp-sgcheck, exp-bbv, exp-dhat, etc.
   ...

That being said, I stronly suggest to read the user manual, in
particular for helgrind and drd : race detection is a sophisticated
functionality, and the helgrind and drd sections are very useful
to read.

And, cherry on the cake, all user manual tool sections starts with
a sentence such as:

  ...
  To use this tool, you must specify --tool=helgrind on the Valgrind command line.
  ...

which I guess would have helped :)

Philippe

[Valgrind-users] --tool help not too helpful

[Skip M. <sk...@po...>]

I went to file a bug report but was thwarted by the need to create yet
another login to file a simple bug, and find Bugzilla an almost
insurmountable hurdle anyway, so I will just mention my issues and
suggestions here, and hope someone better tied into Valgrind development
will pass it along. (That said, as a former Python core developer, I
realize the need/desire for login credentials.)

I am a brand new Valgrind user, afflicted with some threading problems. I
knew about the "memcheck" tool, but didn't know what any of the other
tools were. While reading the man page, I saw mention of the Helgrind and
DRD tools. "Great!" I thought. Alas, specifying "--tool=Helgrind" or
"--tool=DRD" on the command line resulted in rather vague error:

... failed to start tool '<whatever>' for platform 'amd64-linux': ...

Initially, I thought those tools were simply not available on my
platform. Eventually, though, I figured out that tool names must be given
in lower case. "Helgrind" and "DRD" appear to only be given with those
spellings. I saw one instance of "helgrind" in the man page, but it was
part of a larger compound word. I saw no mention of "drd".

Further, I saw no enumeration of all the available tools. The --help
output says that "memcheck" is the default tool. Any mention in --help
output of other tools was secondary (mentioning tools which support
various options).

So, my recommendations:

1. Briefly enumerate all the possible tools somewhere, together in one
place. This would be great in the man page. I think it would be less
important in the --help output.

2. In --help output, at least mention that the toolname must be spelled in
lowercase, no matter how it is spelled in the documentation.

3. (optional) Allow --tool to operate in a case-insensitive fashion.

Thanks,

Skip Montanaro
sk...@po...

Re: [Valgrind-users] dangling pointers, out of scope C++ not detected

[<jr...@bi...>]

int sub(void) {
   int *p;
   {
     int x = 123; p = &x;
   }

// Although x is out-of-scope according to the language,
// gcc/g++ allocates local variables by subroutine, not by block contour.
// (Allocating by subroutine is faster and smaller.)
// Therefore p still points somewhere into the current frame,
// and memcheck does not complain when de-referencing p.
// In order to elicit a complaint from memcheck, then the compiler
// must allocate and de-allocate by block contour.

   return *p;
}

[Valgrind-users] dangling pointers, out of scope C++ not detected

[mathog <ma...@ca...>]

Is there some trick to get valgrind to detect this sort of dangling 
pointer error?

cat >test.cpp <<EOD
#include <iostream>
int sub(void) {
      int *p;
      {
         int x = 123;
         p = &x;
      }
      std::cout << "value of p " << *p << std::endl;
      return *p;
}
int main() {
      int ret = sub();
      std::cout << "value of ret " << ret << std::endl;
      return ret;
}
EOD
g++ -Wall -g -O0 -o test test.cpp
./test
value of p 123
value of ret 123
valgrind ./test
# no problems reported

If sub() instead uses an explicit

    p = (int *) malloc(sizeof(int));
    *p = 123;
    free(p);

then valgrind sees the use of memory after free.  But in the original it 
seems that x is on the stack,
and there is never an explicit delete() when the variable goes out of 
scope, so nothing tells valgrind
that that memory is no longer valid.

(This came up on the Inkscape developer list, originally in reference to 
the warnings clang emits.)

Thanks,

David Mathog
ma...@ca...
Manager, Sequence Analysis Facility, Biology Division, Caltech

[Valgrind-users] Valgrind calls

[Domingues L. F. <Lui...@ed...>]

Hello,

How can I include, on a tool I'm building, dirty-calls when the program
I'm instrumenting is calling a function? (callq x86_64 instruction).

Regards,
Luis Domingues

Re: [Valgrind-users] Build valgrind with Intel compilers

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

On 04/22/2014 09:15 PM, Ying Zhang wrote:
> I'm trying to build valgrind with Intel/2013 compilers, but seems that it is looking
> for GCC. Is Valgrind built with Intel compilers?

It has been known to work at some point in the past, but is not a supported
configuration.  Just give it the gcc it wants :)

J

[Valgrind-users] Build valgrind with Intel compilers

[Ying Z. <zh...@hp...>]

Dear User Support,

I'm trying to build valgrind with Intel/2013 compilers, but seems that it is looking for GCC. Is Valgrind built with Intel compilers?

Thanks,

Ying Zhang

Re: [Valgrind-users] m_cpuid.S: Assembler messages:

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

> I am trying to compile and install valgrind on a 64 bits CENT OS 6.5 system.
> 
> When I compile valgrind (with make), I get the following errors:
> 
> m_cpuid.S:40: Error: suffix or operands invalid for `push'

> m_cpuid.S:43: Error: suffix or operands invalid for `pushf'

> m_cpuid.S:45: Error: suffix or operands invalid for `pop'

> gcc (GCC) 4.7.3

Unfortunately that version of gcc/gas/bfd/binutils has a bug
in not allowing the 'l' on "pushl %ebp", "popl %ebp", "pushfl".
(They changed gcc and binutils together to omit the 'l',
but forgot that the rest of the world requires
backward compatibility with the old spellings of the opcodes.)

Either change the source to remove the 'l' on the indicated lines,
or upgrade to gcc-4.8.x.

-- 

Re: [Valgrind-users] Stack trace missing frame with inlined allocation function?

[Matthias S. <zz...@ge...>]

On 13.04.2014 01:16, Paul Smith wrote:
>> I can send the patch on monday.
>>
The attached patch writes the library load addresses to the xml output.

They can then be used to feed the contained addresses to addr2line.

Regards
Matthias

Re: [Valgrind-users] building valgrind + perftools-lite linking error

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

On Mon, 2014-04-14 at 15:38 +0200, Josef Weidendorfer wrote:
> Am 13.04.2014 13:37, schrieb Philippe Waroquiers:
> > To my knowledge, 2 techniques are working to profile valgrind:
> > 1. oprofile
> > 2. self-hosting (i.e. running valgrind under a valgrind tool such as
> >    callgrind or cachegrind.
> >    For more info about self-hosting, search for "Self-hosting"
> >    in README_DEVELOPERS
> 
> It also should work with perf, shouldn't it?

I guess yes, never tried but I am taking note of this 3rd possibility.

Philippe

Re: [Valgrind-users] building valgrind + perftools-lite linking error

[Josef W. <Jos...@gm...>]

Am 13.04.2014 13:37, schrieb Philippe Waroquiers:
> On Sun, 2014-04-06 at 19:29 -0700, janjust wrote:
>> Hi,
>>    I'm trying to profile valgrind using perftools-lite and when compiling
>> the tools I get an undefined reference error.
>> VEX and coregrind build, but during linking it errs (error is below).

...

> To my knowledge, 2 techniques are working to profile valgrind:
> 1. oprofile
> 2. self-hosting (i.e. running valgrind under a valgrind tool such as
>    callgrind or cachegrind.
>    For more info about self-hosting, search for "Self-hosting"
>    in README_DEVELOPERS

It also should work with perf, shouldn't it?

Josef

> 
> Philippe
> 
> 
> 
> ------------------------------------------------------------------------------
> Put Bad Developers to Shame
> Dominate Development with Jenkins Continuous Integration
> Continuously Automate Build, Test & Deployment 
> Start a new project now. Try Jenkins in the cloud.
> http://p.sf.net/sfu/13600_Cloudbees
> _______________________________________________
> Valgrind-users mailing list
> Val...@li...
> https://lists.sourceforge.net/lists/listinfo/valgrind-users
> 

Re: [Valgrind-users] Need assistance with diagnosing failure cause

[Lior T. <lio...@gm...>]

I was actually advised to add that to find out more info on the error by
Valgrind itself..


On Mon, Apr 14, 2014 at 4:26 PM, Julian Seward <js...@ac...> wrote:

> On 04/14/2014 12:05 PM, Lior Tal wrote:
> > I am getting an error when executing valgrind with the following options:
> >
> > valgrind --tool=memcheck --leak-check=full --dsymutil=yes
> > --read-var-info=yes --log-file=$VALGRIND_LOG ./$MACHO_NAME
>
> Try removing --read-var-info=yes.
>
> J
>
>

[Valgrind-users] ARMv8 port available for testing

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

The trunk now contains a port to AArch64 ARMv8 -- loosely, the
64-bit ARM architecture.  It has now reached a stage of being
useful for real debugging, and, in turn, could do with wider
testing.

Memcheck works and has a noise (false-error) level that is
comparable with other targets.  All the basic functionality --
detection of uninitialised value uses, invalid memory accesses,
detection of leaks, and origin tracking -- is available.  Other
tools -- Lackey, Cachegrind, Callgrind, Massif, DRD and Helgrind
-- work to some extent, but have not been extensively tested.

Current limitations are:

* Incomplete support of vector (SIMD) instructions.  Anything
  created by gcc-4.8.2 -O3, including SIMD code via
  autovectorization, works.  Completion of the SIMD support is
  ongoing.

* Incomplete syscall support.  Enough system calls are supported
  for large programs to work, but some are still unsupported.

* Integration with the built in GDB server is incomplete.

There has been extensive testing of the supported of integer, FP
and SIMD instructions.  At least one large application -- Firefox
26 -- is able to start up and quit.  The port is under active
development and will ship as part of the next release, Valgrind 3.10.

See README.aarch64 for instructions on how to build and run the port.

J

Re: [Valgrind-users] Need assistance with diagnosing failure cause

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

On 04/14/2014 12:05 PM, Lior Tal wrote:
> I am getting an error when executing valgrind with the following options:
> 
> valgrind --tool=memcheck --leak-check=full --dsymutil=yes
> --read-var-info=yes --log-file=$VALGRIND_LOG ./$MACHO_NAME

Try removing --read-var-info=yes.

J

[Valgrind-users] Need assistance with diagnosing failure cause

[Lior T. <lio...@gm...>]

[12:40:11]:									 [Exec] EXEC Support on MacOS 10.8 is experimental and mostly broken.
[12:40:11]:									 [Exec] EXEC Expect incorrect results, assertions and crashes.
[12:40:11]:									 [Exec] EXEC In particular, Memcheck on 32-bit programs will fail to
[12:40:11]:									 [Exec] EXEC detect any errors associated with heap-allocated data.
[12:40:11]:									 [Exec]      [exec] Emulator> ==61926==
[12:40:11]:									 [Exec]      [exec] Emulator> --61926-- run: /usr/bin/dsymutil "./Tests_AutomaticTests.macho"
[12:40:11]:									 [Exec]      [exec] Emulator> 
[12:40:11]:									 [Exec]      [exec] Emulator> parse_var_DIE: confused by:
[12:40:11]:									 [Exec]      [exec] Emulator>  <0><b>: DW_TAG_compile_unit
[12:40:11]:									 [Exec]      [exec] Emulator>      DW_AT_producer    : (indirect string, offset: 0xec): Apple LLVM version 4.2 (clang-425.0.28) (based on LLVM 3.2svn)
[12:40:11]:									 [Exec]      [exec] Emulator>      DW_AT_language    : 12
[12:40:11]:									 [Exec]      [exec] Emulator>      DW_AT_name        : (indirect string, offset: 0x12b): vg_preloaded.c
[12:40:11]:									 [Exec]      [exec] Emulator>      DW_AT_low_pc      : 0x190a
[12:40:11]:									 [Exec]      [exec] Emulator>      DW_AT_stmt_list   : 0
[12:40:11]:									 [Exec]      [exec] Emulator>      DW_AT_comp_dir    : (indirect string, offset: 0x13a): /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_devel_valgrind/valgrind/work/valgrind-3.9.0/coregrind
[12:40:11]:									 [Exec]      [exec] Emulator>      DW_AT_???         : 1
[12:40:11]:									 [Exec]      [exec] Emulator> 
[12:40:11]:									 [Exec] EXEC Serious error when reading debug info
[12:40:11]:									 [Exec]      [exec] Emulator> --61926-- When reading debug info from /opt/local/lib/valgrind/vgpreload_core-amd64-darwin.so:
[12:40:11]:									 [Exec]      [exec] Emulator> --61926-- parse_var_DIE: confused by the above DIE
[12:40:11]:									 [Exec]      [exec] Emulator> 
[12:40:11]:									 [Exec]      [exec] Emulator> parse_var_DIE: confused by:
[12:40:11]:									 [Exec]      [exec] Emulator>  <0><b>: DW_TAG_compile_unit
[12:40:11]:									 [Exec]      [exec] Emulator>      DW_AT_producer    : (indirect string, offset: 0x87a): Apple LLVM version 4.2 (clang-425.0.28) (based on LLVM 3.2svn)
[12:40:11]:									 [Exec]      [exec] Emulator>      DW_AT_language    : 12
[12:40:11]:									 [Exec]      [exec] Emulator>      DW_AT_name        : (indirect string, offset: 0x8b9): m_replacemalloc/vg_replace_malloc.c
[12:40:11]:									 [Exec]      [exec] Emulator>      DW_AT_low_pc      : 0x205a
[12:40:11]:									 [Exec]      [exec] Emulator>      DW_AT_stmt_list   : 0
[12:40:11]:									 [Exec]      [exec] Emulator>      DW_AT_comp_dir    : (indirect string, offset: 0x8dd): /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_devel_valgrind/valgrind/work/valgrind-3.9.0/coregrind
[12:40:11]:									 [Exec]      [exec] Emulator>      DW_AT_???         : 1
[12:40:11]:									 [Exec]      [exec] Emulator> 
[12:40:11]:									 [Exec] EXEC Serious error when reading debug info
[12:40:11]:									 [Exec]      [exec] Emulator> --61926-- When reading debug info from /opt/local/lib/valgrind/vgpreload_memcheck-amd64-darwin.so:
[12:40:11]:									 [Exec]      [exec] Emulator> --61926-- parse_var_DIE: confused by the above DIE
[12:40:11]:									 [Exec]      [exec] Emulator> ==61926==
[12:40:11]:									 [Exec]      [exec] Emulator> ==61926== HEAP SUMMARY:
[12:40:11]:									 [Exec]      [exec] Emulator> ==61926==     in use at exit: 5,774,126 bytes in 82,575 blocks
[12:40:11]:									 [Exec]      [exec] Emulator> ==61926==   total heap usage: 4,726,435 allocs, 4,643,860 frees, 162,119,253 bytes allocated
[12:40:11]:									 [Exec]      [exec] Emulator> ==61926==