valgrind-users — General discussion list for Valgrind users

[Valgrind-users] Valgrind on MIPS no output and 100% CPU

[Adam P. <ada...@ho...>]

Hi,
I've built Valgrind successfully using the MIPS toolchain for my hardware but it doesn't give any output to stdout and just hangs.Steps below:Cross compile Valgrind using my toolchain. Initially it was hanging during compilation. I've used information at https://bugs.kde.org/show_bug.cgi?id=327151 to change the compiler optimisation level and it successfully compilesRun valgrind using on the target device using: VALGRIND_LIB=<valgrind_lib_dir> ./valgrindI don't see any output on the console at all and can see that valgrind is nearly 100% CPU with the output from using top (hardware has 2 cores which explains the 48%):
6210  6190 root     R    16004  13%   0  48% {memcheck-mips32} ./valgrind
I know this is not much information to go on but can anyone provide a suggestion as to how I could proceed?
Thanks,
Adam
 		 	   		  

Re: [Valgrind-users] AM1808-armv5 support

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

> Does valgrind support ARM1808-armv5. When I cross compile I get an error saying not supported.
> The website says ARM/LINX upto and including ARMv7.
>
> Is it really supported or am I making a mistake while cross-compiling.

The armv5 and armv6 architectures are not supported.  (grep "armv[56]" /proc/cpuinfo)
The hardware is deficient because it does not provide reasonable support for threads.
If you are highly motivated then the bug tracker contains patches which enabled
support a couple years ago for armv5 for single-threaded memcheck only.

armv7 is the minimum supported hardware.  A RaspberryPi works very well,
especially B+ version 2 with 1GiB RAM.

[Valgrind-users] AM1808-armv5 support

[praveen p. <pra...@gm...>]

Hello,

Does valgrind support ARM1808-armv5. When I cross compile I get an error
saying not supported.
The website says ARM/LINX upto and including ARMv7.

Is it really supported or am I making a mistake while cross-compiling.

Thanks in advance,
Praveen

Re: [Valgrind-users] Valgrind and JNI java

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

> I update the code (github): https://github.com/avazquezdev/TestValgrindJava

> valgrind-3.10.1
> Kubuntu 15.04 (64bits)

> I created two files with the outputs whether or no memory leak.
> https://github.com/avazquezdev/TestValgrindJava/tree/master/ErrorInfo

> When I allocate memory valgrind show the next:
> https://github.com/avazquezdev/TestValgrindJava/blob/master/ErrorInfo/Example1.txt
> In this text I see nothing to indicate that my library allocates/free memory.


Looking at https://raw.githubusercontent.com/avazquezdev/TestValgrindJava/master/ErrorInfo/Leak.txt
I see signs of a large disconnect or misunderstanding between valgrind and the installed java.

--10539-- Reading syms from /usr/lib/jvm/java-7-openjdk-amd64/jre/bin/java
--10539--   Considering /usr/lib/jvm/java-7-openjdk-amd64/jre/bin/java ..
--10539--   .. CRC mismatch (computed 47030d71 wanted 31641b1e)
--10539--    object doesn't have a symbol table

Not finding the symbol table for .../jre/bin/java could mean that valgrind
will miss the connection to some allocators and deallocators, which will cripple
much of memcheck's machinery.  Determine why there is no symbol table;
the "CRC mismatch" indicates that the symbol table probably was stripped.
Do not do that.

The next message

--10539-- Reading syms from /lib/x86_64-linux-gnu/libc-2.21.so
--10539--   Considering /lib/x86_64-linux-gnu/libc-2.21.so ..
--10539--   .. CRC mismatch (computed 9362f137 wanted 040e4cfb)
--10539--   Considering /usr/lib/debug/lib/x86_64-linux-gnu/libc-2.21.so ..
--10539--   .. CRC is valid

indicates that /lib/x86_64-linux-gnu/libc-2.21.so also has no symbol table,
but that a substitute was found in /usr/lib/debug.  Perhaps you could install
the corresponding jvm/java-7-openjdk-amd64/jre/bin/java (with symbol table)
also beneath /usr/lib/debug ?

In general, if valgrind does not find the symbols, then that is bad.
Don't strip the symbol table; else install the un-stripped version
beneath /usr/lib/debug.


The first complaint regarding executed code:

==10539== Thread 2:
==10539== Conditional jump or move depends on uninitialised value(s)
==10539==    at 0x60F6178: Arena::Arena() (in /usr/lib/jvm/java-7-openjdk-amd64/jre/lib/amd64/server/libjvm.so)
==10539==    by 0x677BCD4: Thread::Thread() (in /usr/lib/jvm/java-7-openjdk-amd64/jre/lib/amd64/server/libjvm.so)
==10539==    by 0x6782474: Threads::create_vm(JavaVMInitArgs*, bool*) (in /usr/lib/jvm/java-7-openjdk-amd64/jre/lib/amd64/server/libjvm.so)
==10539==    by 0x646DB7F: JNI_CreateJavaVM (in /usr/lib/jvm/java-7-openjdk-amd64/jre/lib/amd64/server/libjvm.so)
==10539==    by 0x4E3AB8D: ??? (in /usr/lib/jvm/java-7-openjdk-amd64/jre/lib/amd64/jli/libjli.so)
==10539==    by 0x561B6A9: start_thread (pthread_create.c:333)
==10539==  Uninitialised value was created by a heap allocation
==10539==    at 0x4C2BBA0: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==10539==    by 0x6642F89: os::malloc(unsigned long, unsigned short, unsigned char*) (in /usr/lib/jvm/java-7-openjdk-amd64/jre/lib/amd64/server/libjvm.so)
==10539==    by 0x60F621F: Arena::operator new(unsigned long, unsigned short) (in /usr/lib/jvm/java-7-openjdk-amd64/jre/lib/amd64/server/libjvm.so)
==10539==    by 0x677BCC4: Thread::Thread() (in /usr/lib/jvm/java-7-openjdk-amd64/jre/lib/amd64/server/libjvm.so)
==10539==    by 0x6782474: Threads::create_vm(JavaVMInitArgs*, bool*) (in /usr/lib/jvm/java-7-openjdk-amd64/jre/lib/amd64/server/libjvm.so)
==10539==    by 0x646DB7F: JNI_CreateJavaVM (in /usr/lib/jvm/java-7-openjdk-amd64/jre/lib/amd64/server/libjvm.so)
==10539==    by 0x4E3AB8D: ??? (in /usr/lib/jvm/java-7-openjdk-amd64/jre/lib/amd64/jli/libjli.so)
==10539==    by 0x561B6A9: start_thread (pthread_create.c:333)

might be correct and valid.  Or, it might be a cascade from memcheck not being
connected to the java equivalent of calloc(), which initializes to zero.


The next kind of complaint

==10539== Invalid write of size 4
==10539==    at 0x855E445: ???
==10539==    by 0x854E4E6: ???
==10539==    by 0x644AAD3: JavaCalls::call_helper(JavaValue*, methodHandle*, JavaCallArguments*, Thread*) (in /usr/lib/jvm/java-7-openjdk-amd64/jre/lib/amd64/server/libjvm.so)
==10539==    by 0x644A547: JavaCalls::call(JavaValue*, methodHandle, JavaCallArguments*, Thread*) (in /usr/lib/jvm/java-7-openjdk-amd64/jre/lib/amd64/server/libjvm.so)
==10539==    by 0x6409286: instanceKlass::call_class_initializer_impl(instanceKlassHandle, Thread*) (in /usr/lib/jvm/java-7-openjdk-amd64/jre/lib/amd64/server/libjvm.so)
==10539==    by 0x6409318: instanceKlass::call_class_initializer(Thread*) (in /usr/lib/jvm/java-7-openjdk-amd64/jre/lib/amd64/server/libjvm.so)
==10539==    by 0x64094F4: instanceKlass::initialize_impl(instanceKlassHandle, Thread*) (in /usr/lib/jvm/java-7-openjdk-amd64/jre/lib/amd64/server/libjvm.so)
==10539==    by 0x64099A0: instanceKlass::initialize(Thread*) (in /usr/lib/jvm/java-7-openjdk-amd64/jre/lib/amd64/server/libjvm.so)
==10539==    by 0x6409657: instanceKlass::initialize_impl(instanceKlassHandle, Thread*) (in /usr/lib/jvm/java-7-openjdk-amd64/jre/lib/amd64/server/libjvm.so)
==10539==    by 0x64099A0: instanceKlass::initialize(Thread*) (in /usr/lib/jvm/java-7-openjdk-amd64/jre/lib/amd64/server/libjvm.so)
==10539==    by 0x67831A5: Threads::create_vm(JavaVMInitArgs*, bool*) (in /usr/lib/jvm/java-7-openjdk-amd64/jre/lib/amd64/server/libjvm.so)
==10539==    by 0x646DB7F: JNI_CreateJavaVM (in /usr/lib/jvm/java-7-openjdk-amd64/jre/lib/amd64/server/libjvm.so)
==10539==  Address 0x4158630 is on thread 2's stack
==10539==  4096 bytes below stack pointer

indicates that memcheck is not in sync with the java environment.
Either memcheck has not seen (or not recognized) a "change the stack pointer" event,
or java has implicit conventions about threads, stacks, and thread-local storage
that memcheck does not know or does not understand.


The leak check summary

==10539== HEAP SUMMARY:
==10539==     in use at exit: 22,902,921 bytes in 1,235 blocks
==10539==   total heap usage: 22,721 allocs, 21,486 frees, 44,322,524 bytes allocated
==10539==
==10539== Searching for pointers to 1,235 not-freed blocks
==10539== Checked 3,488,897,480 bytes

indicates that memcheck believes the allocation arenas are around 3.3GB big.  That's a lot,
especially for your tiny example program.  That's another worrisome sign of a disconnect
between memcheck and java.

The largest leaks

==10539== 5,242,880 bytes in 5 blocks are still reachable in loss record 779 of 779
==10539==    at 0x4C2BBA0: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==10539==    by 0x6642F89: os::malloc(unsigned long, unsigned short, unsigned char*) (in /usr/lib/jvm/java-7-openjdk-amd64/jre/lib/amd64/server/libjvm.so)
==10539==    by 0x66A1580: ParCompactionManager::initialize(ParMarkBitMap*) (in /usr/lib/jvm/java-7-openjdk-amd64/jre/lib/amd64/server/libjvm.so)
==10539==    by 0x66A8899: PSParallelCompact::post_initialize() (in /usr/lib/jvm/java-7-openjdk-amd64/jre/lib/amd64/server/libjvm.so)
==10539==    by 0x666AD04: ParallelScavengeHeap::post_initialize() (in /usr/lib/jvm/java-7-openjdk-amd64/jre/lib/amd64/server/libjvm.so)
==10539==    by 0x679EC1B: universe_post_init() (in /usr/lib/jvm/java-7-openjdk-amd64/jre/lib/amd64/server/libjvm.so)
==10539==    by 0x63FD939: init_globals() (in /usr/lib/jvm/java-7-openjdk-amd64/jre/lib/amd64/server/libjvm.so)
==10539==    by 0x67825DE: Threads::create_vm(JavaVMInitArgs*, bool*) (in /usr/lib/jvm/java-7-openjdk-amd64/jre/lib/amd64/server/libjvm.so)
==10539==    by 0x646DB7F: JNI_CreateJavaVM (in /usr/lib/jvm/java-7-openjdk-amd64/jre/lib/amd64/server/libjvm.so)
==10539==    by 0x4E3AB8D: ??? (in /usr/lib/jvm/java-7-openjdk-amd64/jre/lib/amd64/jli/libjli.so)
==10539==    by 0x561B6A9: start_thread (pthread_create.c:333)

hint that memcheck might not understand the conventions of java GarbageCollector.


In summary: fix the symbol table problems first.

Re: [Valgrind-users] Valgrind and JNI java

[Alex V. <ava...@gm...>]

Hi John!
I update the code (github): https://github.com/avazquezdev/TestValgrindJava

>
>Please state the version of valgrind ("valgrind --version"),
>and the hardware architecture, and the operating system and version.

valgrind-3.10.1
Kubuntu 15.04 (64bits)

>
>Please tell us how many (within a few percent), and post (copy+paste)
>two complete example complaints.
>

I created two files with the outputs whether or no memory leak.
https://github.com/avazquezdev/TestValgrindJava/tree/master/ErrorInfo

>
>Please give an example, and explain why not.  Do your routines have names?
>Do those names appear in the complaints from memcheck?

When I allocate memory valgrind show the next:
https://github.com/avazquezdev/TestValgrindJava/blob/master/ErrorInfo/Example1.txt
In this text I see nothing to indicate that my library allocates/free
memory.



2015-10-10 16:03 GMT+02:00 John Reiser <jr...@bi...>:

>  > I want to use valgrind to detect memory leaks for a library in Java
> native interface.
>  > For this I made a sample program by pressing a key reserve memory and
> another
>  > pressing the release and one for exiting the program.
>  >
>  > I have 2 problems:
>  > * If I activate the options to detect memory leaks I see too many
> failures.
>
> Please tell us how many (within a few percent), and post (copy+paste)
> two complete example complaints.
>
>  > * I can not detect which are memory leaks in my library.
>
> Please give an example, and explain why not.  Do your routines have names?
> Do those names appear in the complaints from memcheck?
>
>  >
>  > Option for valgrind:
>  > valgrind --smc-check=all --trace-children=yes --show-leak-kinds=all
> --track-origins=yes -v --leak-check=yes java -Djava.library.path=. App
>
> Please state the version of valgrind ("valgrind --version"),
> and the hardware architecture, and the operating system and version.
>
>  >
>  > Is there any way to filter leaks only my library?
>
> If you can determine which are in your library, then encode that knowledge
> into a filter (using python, perl, sed, awk, ...).  However, in general a
> leak
> results from a misunderstanding about some interface or software contract.
> Usually there are at least two pieces of software involved in creating a
> leak:
> the allocator and the non-free()r.  The leak "belongs" to the combination
> of all of the pieces.
>
>  > Do the choices I am using to search for leaks is right for Java native
> code?
>
> We cannot say until you post verbatim examples of the output that you get.
>
>
>
>
> ------------------------------------------------------------------------------
> _______________________________________________
> Valgrind-users mailing list
> Val...@li...
> https://lists.sourceforge.net/lists/listinfo/valgrind-users
>

Re: [Valgrind-users] Valgrind and JNI java

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

 > I want to use valgrind to detect memory leaks for a library in Java native interface.
 > For this I made a sample program by pressing a key reserve memory and another
 > pressing the release and one for exiting the program.
 >
 > I have 2 problems:
 > * If I activate the options to detect memory leaks I see too many failures.

Please tell us how many (within a few percent), and post (copy+paste)
two complete example complaints.

 > * I can not detect which are memory leaks in my library.

Please give an example, and explain why not.  Do your routines have names?
Do those names appear in the complaints from memcheck?

 >
 > Option for valgrind:
 > valgrind --smc-check=all --trace-children=yes --show-leak-kinds=all --track-origins=yes -v --leak-check=yes java -Djava.library.path=. App

Please state the version of valgrind ("valgrind --version"),
and the hardware architecture, and the operating system and version.

 >
 > Is there any way to filter leaks only my library?

If you can determine which are in your library, then encode that knowledge
into a filter (using python, perl, sed, awk, ...).  However, in general a leak
results from a misunderstanding about some interface or software contract.
Usually there are at least two pieces of software involved in creating a leak:
the allocator and the non-free()r.  The leak "belongs" to the combination
of all of the pieces.

 > Do the choices I am using to search for leaks is right for Java native code?

We cannot say until you post verbatim examples of the output that you get.

[Valgrind-users] Valgrind and JNI java

[Alex V. <ava...@gm...>]

Hi all!
I want to use valgrind to detect memory leaks for a library in Java native
interface. For this I made a sample program by pressing a key reserve
memory and another pressing the release and one for exiting the program.

I have 2 problems:
* If I activate the options to detect memory leaks I see too many failures.
* I can not detect which are memory leaks in my library.

Option for valgrind:
valgrind --smc-check=all --trace-children=yes --show-leak-kinds=all
--track-origins=yes -v --leak-check=yes java -Djava.library.path=. App

Is there any way to filter leaks only my library?
Do the choices I am using to search for leaks is right for Java native code?

Thanks!

Re: [Valgrind-users] Valgrind-users Digest, Vol 113, Issue 1

[Martin I. de O. <iom...@io...>]

On Wed, Oct 07, 2015 at 02:30:02PM +0000, val...@li... wrote:
> Date: Mon, 28 Sep 2015 16:47:43 +0200
> From: Josef Weidendorfer <Jos...@gm...>
> Subject: Re: [Valgrind-users] Cachegrind - Tracing LLC misses
> To: val...@li...
> Message-ID: <560...@gm...>
> Content-Type: text/plain; charset=windows-1252
> 
> Am 25.09.2015 um 22:27 schrieb martin:
> > I'm trying to do a memory trace of my application, but only for  
> > operations that go to DRAM, that is, only if there was a LLC miss  
> > should I care. Is it possible to achieve that with Cachegrind? AFAICS,  
> > it only counts the number of events (and where they happened), but  
> > maybe it wouldn't be too hard to modify it to print the address every  
> > time a LLC miss happens. If anyone could point me to the right place  
> > to look, I would appreciate it.
> 
> See cachegrind/cg_sim.c, function "cachesim_D1_doref". The "*(mL)++" is
> incrementing the counter for a last-level cache miss. At this point,
> you can use VG_(printf) to print out the address ("a").
> If you also want to print out the address of the instruction doing the
> memory
> access, or whether it is a read or write, you need to modify the callers
> of cachesim_D1_doref (and change the return value to tell if it's a LLC
> miss).
> 
> Josef
> 
> Message: 2
> Date: Mon, 28 Sep 2015 18:07:30 +0200
> From: Josef Weidendorfer <Jos...@gm...>
> Subject: Re: [Valgrind-users] Cachegrind - Tracing LLC misses
> To: val...@li...
> Message-ID: <560...@gm...>
> Content-Type: text/plain; charset=iso-8859-15
> 
> Am 27.09.2015 um 20:02 schrieb Milian Wolff:
> > On Freitag, 25. September 2015 20:27:45 CEST martin wrote:
> >> Hello,
> >>
> >> I'm new to Cachegrind (and cache simulation in general).
> >>
> >> I'm trying to do a memory trace of my application, but only for
> >> operations that go to DRAM, that is, only if there was a LLC miss
> >> should I care. Is it possible to achieve that with Cachegrind? AFAICS,
> >> it only counts the number of events (and where they happened), but
> >> maybe it wouldn't be too hard to modify it to print the address every
> >> time a LLC miss happens. If anyone could point me to the right place
> >> to look, I would appreciate it.
> > 
> > You could also use perf for this use case, if your CPU has the required 
> > performance counters. This is also going to be much faster and more accurate, 
> > as you don't need to simulate anything, but get the real counters directly 
> > from hardware:
> > 
> > perf record --event cache-misses --call-graph dwarf <your application>
> 
> Yes, using perf for real measurement is another option if you are fine with
> sampled results (not every access). This way you get the behavior of the
> real
> cache.
> 
> But if I remember right, it is more tricky to get the data addresses
> printed out.
> On Intel something like
> 
>   perf record -d -e cpu/mem-loads,ldlat=100/pp <app>
> 
> "-d" is writing data addresses into output, "/pp" is requesting PEBS for
> hardware
> to provide data addresses in the first place, and "ldlat=100" only
> counts events
> with load latency at least 100 cycles, which should be memory accesses.
> To get the addresses, you could use
> 
>   perf report -D | grep addr
> 
> There is a field "period" in the output which shows you how many events
> you lost due
> to sampling. Theoretically, one can ask for every event via "perf record
> -c 1 ...",
> but I suppose there are most events missed due to buffer overrun in the
> kernel or
> other effects (at least the machine does not lock up here :-).
> 
> Josef

Josef, Milian:

Thank you very much. I'll look into your suggestions.

Best,
Martin

Re: [Valgrind-users] cross compiling valgrind

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

> My target machine is running an older linux distro on a 32 bit armv5 processor
> Linux Evolution.example.com 2.6.18_pro500-davinci_IPNC_DM368_2.6.0 #1 PREEMPT Fri Apr 24 12:17:38 BST 2015 armv5tejl GNU/Linux

armv5* is not officially supported as a target.  The hardware is deficient
because it does not provide reasonable support for threads.
There are unsupported patches (see the bug tracker) which enable support
for single-threaded ONLY, and memcheck ONLY; but you yourself
must support them (including adapt as needed from 2 or 3 years ago.)
armv7 is the minimal supported hardware.

Perhaps someone else can explain the failed attempt at configuration
(all the complaints from gcc, etc.)

[Valgrind-users] cross compiling valgrind

[Jerry O. <jo...@on...>]

Having difficulty (valgrind newbie) configuring valgrind for a cross compile for my armv5/Linux embedded target. (Host/target and config information shown below) Doubt my configuration was correct but could find little documentation or examples online. Guessed at the required config options.

My host machine is running Ubuntu:
inux joram-Latitude-E6440 3.19.0-25-generic #26-Ubuntu SMP Fri Jul 24 21:17:31 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux

My target machine is running an older linux distro on a 32 bit armv5 processor
Linux Evolution.example.com 2.6.18_pro500-davinci_IPNC_DM368_2.6.0 #1 PREEMPT Fri Apr 24 12:17:38 BST 2015 armv5tejl GNU/Linux

My configuration script looks like this:
sudo ./configure --prefix=/home/joram/valgrind/bin \                                                                                     --host=x86_64-ubuntu-linux --target=armv5-linux  \
CC=/opt/mv_pro_5.0/montavista/pro/devkit/arm/v5t_le/bin/arm_v5t_le-gcc \
AR=/opt/mv_pro_5.0/montavista/pro/devkit/arm/v5t_le/bin/arm_v5t_le-ar

 (montavista toolchain)
Not sure I got that right although the configure script didn't complain, the end of it's output did
not look right:

        Maximum build arch: amd64
        Primary build arch: amd64
      Secondary build arch:
                  Build OS: linux
      Primary build target: AMD64_LINUX
    Secondary build target:
          Platform variant: vanilla
     Primary -DVGPV string: -DVGPV_amd64_linux_vanilla=1
        Default supp files: exp-sgcheck.supp xfree-3.supp xfree-4.supp glibc-2.X-drd.supp glibc-2.34567-NPTL-helgrind.supp glibc-2.5.sup
p

/*have no idea where the amd64 came from, my host machine is an  x86_64*/
 When I ran make it chugged through most of the build ok before it crapped out on:

make[3]: Entering directory '/home/joram/valgrind/valgrind-3.11.0/coregrind' with a ton of compiler errors:

/opt/mv_pro_5.0/montavista/pro/devkit/arm/v5t_le/bin/arm_v5t_le-gcc -DHAVE_CONFIG_H -I. -I..  -I.. -I../include -I../VEX/pub -I../VEX/pub
-DVGA_amd64=1 -DVGO_linux=1 -DVGP_amd64_linux=1 -DVGPV_amd64_linux_vanilla=1 -I../coregrind -DVG_LIBDIR="\"/home/joram/valgrind/bin/lib/
valgrind"\" -DVG_PLATFORM="\"amd64-linux\""  -O2 -g -std=gnu99 -Wall -Wmissing-prototypes -Wshadow -Wpointer-arith -Wstrict-prototypes -W
missing-declarations -Wcast-align -Wcast-qual -Wwrite-strings -Wformat -Wformat-security -fno-stack-protector -fno-strict-aliasing -fno-b
uiltin  -fomit-frame-pointer   -MT libcoregrind_amd64_linux_a-m_addrinfo.o -MD -MP -MF .deps/libcoregrind_amd64_linux_a-m_addrinfo.Tpo -c
-o libcoregrind_amd64_linux_a-m_addrinfo.o `test -f 'm_addrinfo.c' || echo './'`m_addrinfo.c
In file included from ../include/pub_tool_vki.h:49,
                from pub_core_vki.h:44,
                from pub_core_threadstate.h:44,
                from m_addrinfo.c:44:
../include/vki/vki-linux.h: In function ‘__vki_cmsg_nxthdr’:
../include/vki/vki-linux.h:677: warning: cast increases required alignment of target type
In file included from ../include/pub_tool_vki.h:60,
                from pub_core_vki.h:44,
                from pub_core_threadstate.h:44,
                from m_addrinfo.c:44:
../include/vki/vki-xen.h:84:2: error: #error "Need to define per-ARCH Xen types for this platform"
In file included from ../include/pub_tool_vki.h:60,
                from pub_core_vki.h:44,
                from pub_core_threadstate.h:44,
                from m_addrinfo.c:44:
../include/vki/vki-xen.h: At top level:
../include/vki/vki-xen.h:87: error: ‘void’ must be the only parameter
../include/vki/vki-xen.h:87: warning: data definition has no type or storage class
../include/vki/vki-xen.h:87: warning: type defaults to ‘int’ in declaration of ‘___DEFINE_VKI_XEN_GUEST_HANDLE’
../include/vki/vki-xen.h:87: error: expected ‘)’ before ‘const’
../include/vki/vki-xen.h:88: warning: data definition has no type or storage class
../include/vki/vki-xen.h:88: warning: type defaults to ‘int’ in declaration of ‘___DEFINE_VKI_XEN_GUEST_HANDLE’
../include/vki/vki-xen.h:88: error: conflicting types for ‘___DEFINE_VKI_XEN_GUEST_HANDLE’
../include/vki/vki-xen.h:87: error: previous declaration of ‘___DEFINE_VKI_XEN_GUEST_HANDLE’ was here
../include/vki/vki-xen.h:88: error: expected ‘)’ before ‘const’
../include/vki/vki-xen.h:89: warning: data definition has no type or storage class
../include/vki/vki-xen.h:89: warning: type defaults to ‘int’ in declaration of ‘___DEFINE_VKI_XEN_GUEST_HANDLE’
../include/vki/vki-xen.h:89: warning: parameter names (without types) in function declaration
../include/vki/vki-xen.h:89: error: expected ‘)’ before ‘const’
../include/vki/vki-xen.h:91: error: expected ‘)’ before ‘unsigned’
../include/vki/vki-xen.h:91: error: expected ‘)’ before ‘const’
../include/vki/vki-xen.h:93: error: expected ‘)’ before ‘vki_int16_t’
../include/vki/vki-xen.h:93: error: expected ‘)’ before ‘const’
../include/vki/vki-xen.h:94: error: expected ‘)’ before ‘vki_int32_t’
../include/vki/vki-xen.h:94: error: expected ‘)’ before ‘const’
../include/vki/vki-xen.h:95: error: expected ‘)’ before ‘vki_int64_t’
../include/vki/vki-xen.h:95: error: expected ‘)’ before ‘const’
../include/vki/vki-xen.h:97: error: expected ‘)’ before ‘vki_uint8_t’
../include/vki/vki-xen.h:97: error: expected ‘)’ before ‘const’
../include/vki/vki-xen.h:98: error: expected ‘)’ before ‘vki_uint16_t’
../include/vki/vki-xen.h:98: error: expected ‘)’ before ‘const’
../include/vki/vki-xen.h:99: error: expected ‘)’ before ‘vki_uint32_t’
../include/vki/vki-xen.h:99: error: expected ‘)’ before ‘const’
../include/vki/vki-xen.h:100: error: expected ‘)’ before ‘vki_uint64_t’
../include/vki/vki-xen.h:100: error: expected ‘)’ before ‘const’
../include/vki/vki-xen.h:103: error: expected specifier-qualifier-list before ‘VKI_XEN_GUEST_HANDLE_64’
In file included from ../include/vki/vki-xen.h:107,
                from ../include/pub_tool_vki.h:60,
                from pub_core_vki.h:44,
                from pub_core_threadstate.h:44,
                from m_addrinfo.c:44:
../include/vki/vki-xen-domctl.h:135: error: expected specifier-qualifier-list before ‘vki_xen_uint64_aligned_t’
../include/vki/vki-xen-domctl.h:148: warning: data definition has no type or storage class
../include/vki/vki-xen-domctl.h:148: warning: type defaults to ‘int’ in declaration of ‘___DEFINE_VKI_XEN_GUEST_HANDLE’
../include/vki/vki-xen-domctl.h:148: error: conflicting types for ‘___DEFINE_VKI_XEN_GUEST_HANDLE’
../include/vki/vki-xen.h:87: error: previous declaration of ‘___DEFINE_VKI_XEN_GUEST_HANDLE’ was here
../include/vki/vki-xen-domctl.h:148: error: expected ‘)’ before ‘const’
../include/vki/vki-xen-domctl.h:154: error: expected specifier-qualifier-list before ‘vki_xen_uint64_aligned_t’
../include/vki/vki-xen-domctl.h:167: warning: data definition has no type or storage class
../include/vki/vki-xen-domctl.h:167: warning: type defaults to ‘int’ in declaration of ‘___DEFINE_VKI_XEN_GUEST_HANDLE’
../include/vki/vki-xen-domctl.h:167: error: conflicting types for ‘___DEFINE_VKI_XEN_GUEST_HANDLE’
../include/vki/vki-xen.h:87: error: previous declaration of ‘___DEFINE_VKI_XEN_GUEST_HANDLE’ was here
../include/vki/vki-xen-domctl.h:167: error: expected ‘)’ before ‘const’
../include/vki/vki-xen-domctl.h:173: error: expected specifier-qualifier-list before ‘vki_xen_uint64_aligned_t’
../include/vki/vki-xen-domctl.h:187: warning: data definition has no type or storage class
../include/vki/vki-xen-domctl.h:187: warning: type defaults to ‘int’ in declaration of ‘___DEFINE_VKI_XEN_GUEST_HANDLE’
../include/vki/vki-xen-domctl.h:187: error: conflicting types for ‘___DEFINE_VKI_XEN_GUEST_HANDLE’
../include/vki/vki-xen.h:87: error: previous declaration of ‘___DEFINE_VKI_XEN_GUEST_HANDLE’ was here
../include/vki/vki-xen-domctl.h:187: error: expected ‘)’ before ‘const’
../include/vki/vki-xen-domctl.h:198: warning: data definition has no type or storage class
../include/vki/vki-xen-domctl.h:198: warning: type defaults to ‘int’ in declaration of ‘___DEFINE_VKI_XEN_GUEST_HANDLE’
../include/vki/vki-xen-domctl.h:198: error: conflicting types for ‘___DEFINE_VKI_XEN_GUEST_HANDLE’
../include/vki/vki-xen.h:87: error: previous declaration of ‘___DEFINE_VKI_XEN_GUEST_HANDLE’ was here
../include/vki/vki-xen-domctl.h:198: error: expected ‘)’ before ‘const’
../include/vki/vki-xen-domctl.h:201: error: expected specifier-qualifier-list before ‘vki_xen_uint64_aligned_t’
../include/vki/vki-xen-domctl.h:248: error: expected specifier-qualifier-list before ‘VKI_XEN_GUEST_HANDLE_64’
../include/vki/vki-xen-domctl.h:255: error: expected specifier-qualifier-list before ‘vki_xen_uint64_aligned_t’
../include/vki/vki-xen-domctl.h:260: error: expected specifier-qualifier-list before ‘VKI_XEN_GUEST_HANDLE_64’
../include/vki/vki-xen-domctl.h:270: error: expected specifier-qualifier-list before ‘vki_xen_uint64_aligned_t’
../include/vki/vki-xen-domctl.h:286: error: expected specifier-qualifier-list before ‘vki_xen_uint64_aligned_t’
../include/vki/vki-xen-domctl.h:317: error: expected specifier-qualifier-list before ‘vki_xen_uint64_aligned_t’
../include/vki/vki-xen-domctl.h:329: error: expected specifier-qualifier-list before ‘vki_xen_uint64_aligned_t’
../include/vki/vki-xen-domctl.h:349: error: expected specifier-qualifier-list before ‘vki_xen_uint64_aligned_t’
../include/vki/vki-xen-domctl.h:352: warning: data definition has no type or storage class
../include/vki/vki-xen-domctl.h:352: warning: type defaults to ‘int’ in declaration of ‘___DEFINE_VKI_XEN_GUEST_HANDLE’
../include/vki/vki-xen-domctl.h:352: error: conflicting types for ‘___DEFINE_VKI_XEN_GUEST_HANDLE’
../include/vki/vki-xen.h:87: error: previous declaration of ‘___DEFINE_VKI_XEN_GUEST_HANDLE’ was here
../include/vki/vki-xen-domctl.h:352: error: expected ‘)’ before ‘const’
../include/vki/vki-xen-domctl.h:356: error: expected specifier-qualifier-list before ‘VKI_XEN_GUEST_HANDLE_64’
../include/vki/vki-xen-domctl.h:359: warning: data definition has no type or storage class
../include/vki/vki-xen-domctl.h:359: warning: type defaults to ‘int’ in declaration of ‘___DEFINE_VKI_XEN_GUEST_HANDLE’
../include/vki/vki-xen-domctl.h:359: error: conflicting types for ‘___DEFINE_VKI_XEN_GUEST_HANDLE’
../include/vki/vki-xen.h:87: error: previous declaration of ‘___DEFINE_VKI_XEN_GUEST_HANDLE’ was here
../include/vki/vki-xen-domctl.h:359: error: expected ‘)’ before ‘const’
../include/vki/vki-xen-domctl.h:364: error: expected specifier-qualifier-list before ‘VKI_XEN_GUEST_HANDLE_64’
../include/vki/vki-xen-domctl.h:367: warning: data definition has no type or storage class
../include/vki/vki-xen-domctl.h:367: warning: type defaults to ‘int’ in declaration of ‘___DEFINE_VKI_XEN_GUEST_HANDLE’
../include/vki/vki-xen-domctl.h:367: error: conflicting types for ‘___DEFINE_VKI_XEN_GUEST_HANDLE’
../include/vki/vki-xen.h:87: error: previous declaration of ‘___DEFINE_VKI_XEN_GUEST_HANDLE’ was here
../include/vki/vki-xen-domctl.h:367: error: expected ‘)’ before ‘const’
../include/vki/vki-xen-domctl.h:370: error: expected specifier-qualifier-list before ‘VKI_XEN_GUEST_HANDLE_64’
../include/vki/vki-xen-domctl.h:375: error: expected specifier-qualifier-list before ‘vki_xen_uint64_aligned_t’
../include/vki/vki-xen-domctl.h:419: error: expected specifier-qualifier-list before ‘vki_xen_uint64_aligned_t’
../include/vki/vki-xen-domctl.h:454: error: expected specifier-qualifier-list before ‘vki_xen_pfn_t’
../include/vki/vki-xen-domctl.h:460: error: expected specifier-qualifier-list before ‘vki_xen_uint64_aligned_t’
../include/vki/vki-xen-domctl.h:463: warning: data definition has no type or storage class
../include/vki/vki-xen-domctl.h:463: warning: type defaults to ‘int’ in declaration of ‘___DEFINE_VKI_XEN_GUEST_HANDLE’
../include/vki/vki-xen-domctl.h:463: error: conflicting types for ‘___DEFINE_VKI_XEN_GUEST_HANDLE’
../include/vki/vki-xen.h:87: error: previous declaration of ‘___DEFINE_VKI_XEN_GUEST_HANDLE’ was here
../include/vki/vki-xen-domctl.h:463: error: expected ‘)’ before ‘const’
../include/vki/vki-xen-domctl.h:468: error: expected specifier-qualifier-list before ‘VKI_XEN_GUEST_HANDLE_64’
In file included from ../include/vki/vki-xen.h:108,
                from ../include/pub_tool_vki.h:60,
                from pub_core_vki.h:44,
                from pub_core_threadstate.h:44,
                from m_addrinfo.c:44:
../include/vki/vki-xen-sysctl.h:54: error: expected specifier-qualifier-list before ‘VKI_XEN_GUEST_HANDLE_64’
../include/vki/vki-xen-sysctl.h:67: error: expected specifier-qualifier-list before ‘VKI_XEN_GUEST_HANDLE_64’
../include/vki/vki-xen-sysctl.h:76: error: expected specifier-qualifier-list before ‘VKI_XEN_GUEST_HANDLE_64’
../include/vki/vki-xen-sysctl.h:85: error: expected specifier-qualifier-list before ‘VKI_XEN_GUEST_HANDLE_64’
../include/vki/vki-xen-sysctl.h:112: error: expected specifier-qualifier-list before ‘VKI_XEN_GUEST_HANDLE_64’
../include/vki/vki-xen-sysctl.h:118: error: expected specifier-qualifier-list before ‘VKI_XEN_GUEST_HANDLE_64’
../include/vki/vki-xen-sysctl.h:125: error: expected specifier-qualifier-list before ‘VKI_XEN_GUEST_HANDLE_64’
../include/vki/vki-xen-sysctl.h:137: error: expected specifier-qualifier-list before ‘vki_xen_uint64_aligned_t’
../include/vki/vki-xen-sysctl.h:153: error: expected specifier-qualifier-list before ‘vki_xen_uint64_aligned_t’
In file included from ../include/vki/vki-xen.h:109,
                from ../include/pub_tool_vki.h:60,
(truncated)





This communication is for the exclusive use of the addressee and may contain information that is private and confidential. If you are not the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication and its attachments is strictly prohibited. If you have received this information in error please contact the sender and delete the communication from your system. Any views or opinions presented are solely those of the author and do not necessarily represent those of Oncam Grandeye unless specifically stated.


This message has been scanned for malware by Websense. www.websense.com

Re: [Valgrind-users] Cachegrind - Tracing LLC misses

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

Am 27.09.2015 um 20:02 schrieb Milian Wolff:
> On Freitag, 25. September 2015 20:27:45 CEST martin wrote:
>> Hello,
>>
>> I'm new to Cachegrind (and cache simulation in general).
>>
>> I'm trying to do a memory trace of my application, but only for
>> operations that go to DRAM, that is, only if there was a LLC miss
>> should I care. Is it possible to achieve that with Cachegrind? AFAICS,
>> it only counts the number of events (and where they happened), but
>> maybe it wouldn't be too hard to modify it to print the address every
>> time a LLC miss happens. If anyone could point me to the right place
>> to look, I would appreciate it.
> 
> You could also use perf for this use case, if your CPU has the required 
> performance counters. This is also going to be much faster and more accurate, 
> as you don't need to simulate anything, but get the real counters directly 
> from hardware:
> 
> perf record --event cache-misses --call-graph dwarf <your application>

Yes, using perf for real measurement is another option if you are fine with
sampled results (not every access). This way you get the behavior of the
real
cache.

But if I remember right, it is more tricky to get the data addresses
printed out.
On Intel something like

  perf record -d -e cpu/mem-loads,ldlat=100/pp <app>

"-d" is writing data addresses into output, "/pp" is requesting PEBS for
hardware
to provide data addresses in the first place, and "ldlat=100" only
counts events
with load latency at least 100 cycles, which should be memory accesses.
To get the addresses, you could use

  perf report -D | grep addr

There is a field "period" in the output which shows you how many events
you lost due
to sampling. Theoretically, one can ask for every event via "perf record
-c 1 ...",
but I suppose there are most events missed due to buffer overrun in the
kernel or
other effects (at least the machine does not lock up here :-).

Josef

Re: [Valgrind-users] Cachegrind - Tracing LLC misses

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

Am 25.09.2015 um 22:27 schrieb martin:
> I'm trying to do a memory trace of my application, but only for  
> operations that go to DRAM, that is, only if there was a LLC miss  
> should I care. Is it possible to achieve that with Cachegrind? AFAICS,  
> it only counts the number of events (and where they happened), but  
> maybe it wouldn't be too hard to modify it to print the address every  
> time a LLC miss happens. If anyone could point me to the right place  
> to look, I would appreciate it.

See cachegrind/cg_sim.c, function "cachesim_D1_doref". The "*(mL)++" is
incrementing the counter for a last-level cache miss. At this point,
you can use VG_(printf) to print out the address ("a").
If you also want to print out the address of the instruction doing the
memory
access, or whether it is a read or write, you need to modify the callers
of cachesim_D1_doref (and change the return value to tell if it's a LLC
miss).

Josef

> 
> Thank you,
> Martin
> 
> 
> ------------------------------------------------------------------------------
> _______________________________________________
> Valgrind-users mailing list
> Val...@li...
> https://lists.sourceforge.net/lists/listinfo/valgrind-users
> 

[Valgrind-users] Fw: important

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

Hey!

 

Important message, please visit <http://banrangsit.com/seems.php?i99>

 

phi...@sk...

Re: [Valgrind-users] Cachegrind - Tracing LLC misses

[Milian W. <ma...@mi...>]

On Freitag, 25. September 2015 20:27:45 CEST martin wrote:
> Hello,
> 
> I'm new to Cachegrind (and cache simulation in general).
> 
> I'm trying to do a memory trace of my application, but only for
> operations that go to DRAM, that is, only if there was a LLC miss
> should I care. Is it possible to achieve that with Cachegrind? AFAICS,
> it only counts the number of events (and where they happened), but
> maybe it wouldn't be too hard to modify it to print the address every
> time a LLC miss happens. If anyone could point me to the right place
> to look, I would appreciate it.

You could also use perf for this use case, if your CPU has the required 
performance counters. This is also going to be much faster and more accurate, 
as you don't need to simulate anything, but get the real counters directly 
from hardware:

perf record --event cache-misses --call-graph dwarf <your application>

Visualize it then with either a FlameGraph, ur directly with perf report.

HTH
-- 
Milian Wolff
ma...@mi...
http://milianw.de

Re: [Valgrind-users] Two stacktraces printed: what is the relationship between them?

[Harry W. <fre...@gm...>]

Hi,
The first stack trace is showing where the invalid read is occurring:
at an instruction at address 0xA0148F0, which corresponds to
selectable.c, line 247. The read is invalid because although that
memory was valid at one point, it is in a block which was freed. The
second stack trace is showing where that block was freed.

The message is essentially trying to tell you that you have read from
an address which is invalid because it has been freed. This doesn't
crash when run normally because the memory being accessed might still
be mapped.

Thanks,
Harrry

On 26 September 2015 at 16:33, Graham Leggett <mi...@sh...> wrote:
> Hi all,
>
> I have a very strange case of a piece of code that crashes when run under valgrind, but doesn’t crash when run normally or under gdb. Obviously something is wrong, but I don’t understand the information valgrind is trying to tell me.
>
> I get an error "Invalid read of size 1”, a stacktrace, a message about overlapping memory then a second stacktrace, and that’s it.
>
> Can anyone explain what the relationship is between these two stacktraces, what is this message trying to tell me?
>
> ==29256== Invalid read of size 1
> ==29256==    at 0xA0148F0: pn_selectable_is_terminal (selectable.c:247)
> ==29256==    by 0x997599B: run_messenger_thread (mod_amqp.c:1900)
> ==29256==    by 0x5F21DF4: start_thread (in /usr/lib64/libpthread-2.17.so)
> ==29256==    by 0x64301AC: clone (in /usr/lib64/libc-2.17.so)
> ==29256==  Address 0x698e343 is 99 bytes inside a block of size 104 free'd
> ==29256==    at 0x4C2AD17: free (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
> ==29256==    by 0x9FF6BE5: pn_class_decref (object.c:103)
> ==29256==    by 0xA01067B: pn_messenger_free (messenger.c:822)
> ==29256==    by 0x9971583: messenger_cleanup (mod_amqp.c:314)
> ==29256==    by 0x58C3F0D: run_cleanups (apr_pools.c:2352)
> ==29256==    by 0x58C3F0D: apr_pool_destroy (apr_pools.c:814)
> ==29256==    by 0x58C3EE4: apr_pool_destroy (apr_pools.c:811)
> ==29256==    by 0x58C4144: apr_pool_clear (apr_pools.c:769)
> ==29256==    by 0x13E70A: main (in /usr/sbin/httpd)
>
> Regards,
> Graham
> —
>
>
> ------------------------------------------------------------------------------
> _______________________________________________
> Valgrind-users mailing list
> Val...@li...
> https://lists.sourceforge.net/lists/listinfo/valgrind-users

[Valgrind-users] Two stacktraces printed: what is the relationship between them?

[Graham L. <mi...@sh...>]

Hi all,

I have a very strange case of a piece of code that crashes when run under valgrind, but doesn’t crash when run normally or under gdb. Obviously something is wrong, but I don’t understand the information valgrind is trying to tell me.

I get an error "Invalid read of size 1”, a stacktrace, a message about overlapping memory then a second stacktrace, and that’s it.

Can anyone explain what the relationship is between these two stacktraces, what is this message trying to tell me?

==29256== Invalid read of size 1
==29256==    at 0xA0148F0: pn_selectable_is_terminal (selectable.c:247)
==29256==    by 0x997599B: run_messenger_thread (mod_amqp.c:1900)
==29256==    by 0x5F21DF4: start_thread (in /usr/lib64/libpthread-2.17.so)
==29256==    by 0x64301AC: clone (in /usr/lib64/libc-2.17.so)
==29256==  Address 0x698e343 is 99 bytes inside a block of size 104 free'd
==29256==    at 0x4C2AD17: free (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
==29256==    by 0x9FF6BE5: pn_class_decref (object.c:103)
==29256==    by 0xA01067B: pn_messenger_free (messenger.c:822)
==29256==    by 0x9971583: messenger_cleanup (mod_amqp.c:314)
==29256==    by 0x58C3F0D: run_cleanups (apr_pools.c:2352)
==29256==    by 0x58C3F0D: apr_pool_destroy (apr_pools.c:814)
==29256==    by 0x58C3EE4: apr_pool_destroy (apr_pools.c:811)
==29256==    by 0x58C4144: apr_pool_clear (apr_pools.c:769)
==29256==    by 0x13E70A: main (in /usr/sbin/httpd)

Regards,
Graham
—

[Valgrind-users] Cachegrind - Tracing LLC misses

[martin <iom...@io...>]

Hello,

I'm new to Cachegrind (and cache simulation in general).

I'm trying to do a memory trace of my application, but only for  
operations that go to DRAM, that is, only if there was a LLC miss  
should I care. Is it possible to achieve that with Cachegrind? AFAICS,  
it only counts the number of events (and where they happened), but  
maybe it wouldn't be too hard to modify it to print the address every  
time a LLC miss happens. If anyone could point me to the right place  
to look, I would appreciate it.

Thank you,
Martin

Re: [Valgrind-users] Redux

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

> Is there any Users Guide to using the Valgrind option Redux. It creates static and dynamic data flow graphs. I need to know more about how to use it.

A web search for "valgrind redux" returns several documents.
The ones I saw were quite old, around 10 years or more.
See "gperftools" instead.

[Valgrind-users] Redux

[James Y. <jam...@gm...>]

Is there any Users Guide to using the Valgrind option Redux. It creates
static and dynamic data flow graphs. I need to know more about how to use
it.

I thought any documentation might help.

Respectfully,

James M. Yunker

[Valgrind-users] Valgrind-3.11.0 is available

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

We are pleased to announce a new release of Valgrind, version 3.11.0,
available from http://www.valgrind.org.

3.11.0 is a feature release with many improvements and the usual
collection of bug fixes.  This release adds full support for
X86/Solaris and AMD64/Solaris, improves support for Mac OS X 10.10
(Yosemite), and adds preliminary support for Mac OS X 10.11 (El
Capitan) and TileGX/Linux.  Intel AVX2 support is more complete (64
bit targets only).  There are many smaller refinements and new
features.

The release notes below give more details.

Our thanks to all those who contribute to Valgrind's development.
This release represents a great deal of time, energy and effort on the
part of many people.

Happy and productive debugging and profiling,

-- The Valgrind Developers



Release 3.11.0 (22 September 2015)
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

3.11.0 is a feature release with many improvements and the usual
collection of bug fixes.

This release supports X86/Linux, AMD64/Linux, ARM32/Linux,
ARM64/Linux, PPC32/Linux, PPC64BE/Linux, PPC64LE/Linux, S390X/Linux,
MIPS32/Linux, MIPS64/Linux, ARM/Android, ARM64/Android,
MIPS32/Android, X86/Android, X86/Solaris, AMD64/Solaris, X86/MacOSX
10.10 and AMD64/MacOSX 10.10.  There is also preliminary support for
X86/MacOSX 10.11, AMD64/MacOSX 10.11 and TILEGX/Linux.

* ================== PLATFORM CHANGES =================

* Support for Solaris/x86 and Solaris/amd64 has been added.

* Preliminary support for Mac OS X 10.11 (El Capitan) has been added.

* Preliminary support for the Tilera TileGX architecture has been added.

* s390x: It is now required for the host to have the "long displacement"
  facility.  The oldest supported machine model is z990.

* x86: on an SSE2 only host, Valgrind in 32 bit mode now claims to be a
  Pentium 4.  3.10.1 wrongly claimed to be a Core 2, which is SSSE3.

* The JIT's register allocator is significantly faster, making the JIT
  as a whole somewhat faster, so JIT-intensive activities, for example
  program startup, are modestly faster, around 5%.

* There have been changes to the default settings of several command
  line flags, as detailed below.

* Intel AVX2 support is more complete (64 bit targets only).  On AVX2
  capable hosts, the simulated CPUID will now indicate AVX2 support.

* ==================== TOOL CHANGES ====================

* Memcheck:

  - The default value for --leak-check-heuristics has been changed from
    "none" to "all". This helps to reduce the number of possibly
    lost blocks, in particular for C++ applications.

  - The default value for --keep-stacktraces has been changed from
    "malloc-then-free" to "malloc-and-free".  This has a small cost in
    memory (one word per malloc-ed block) but allows Memcheck to show the
    3 stacktraces of a dangling reference: where the block was allocated,
    where it was freed, and where it is acccessed after being freed.

  - The default value for --partial-loads-ok has been changed from "no" to
    "yes", so as to avoid false positive errors resulting from some kinds
    of vectorised loops.

  - A new monitor command 'xb <addr> <len>' shows the validity bits of
    <len> bytes at <addr>.  The monitor command 'xb' is easier to use
    than get_vbits when you need to associate byte data value with
    their corresponding validity bits.

  - The 'block_list' monitor command has been enhanced:
      o it can print a range of loss records
      o it now accepts an optional argument 'limited <max_blocks>'
        to control the number of blocks printed.
      o if a block has been found using a heuristic, then
        'block_list' now shows the heuristic after the block size.
      o the loss records/blocks to print can be limited to the blocks
        found via specified heuristics.

  - The C helper functions used to instrument loads on
    x86-{linux,solaris} and arm-linux (both 32-bit only) have been
    replaced by handwritten assembly sequences.  This gives speedups
    in the region of 0% to 7% for those targets only.

  - A new command line option, --expensive-definedness-checks=yes|no,
    has been added.  This is useful for avoiding occasional invalid
    uninitialised-value errors in optimised code.  Watch out for
    runtime degradation, as this can be up to 25%.  As always, though,
    the slowdown is highly application specific.  The default setting
    is "no".

* Massif:

  - A new monitor command 'all_snapshots <filename>' dumps all
    snapshots taken so far.

* Helgrind:

  - Significant memory reduction and moderate speedups for
    --history-level=full for applications accessing a lot of memory
    with many different stacktraces.

  - The default value for --conflict-cache-size=N has been doubled to
    2000000.  Users that were not using the default value should
    preferably also double the value they give.

    The default was changed due to the changes in the "full history"
    implementation.  Doubling the value gives on average a slightly more
    complete history and uses similar memory (or significantly less memory
    in the worst case) than the previous implementation.

  - The Helgrind monitor command 'info locks' now accepts an optional
    argument 'lock_addr', which shows information about the lock at the
    given address only.

  - When using --history-level=full, the new Helgrind monitor command
    'accesshistory <addr> [<len>]' will show the recorded accesses for
    <len> (or 1) bytes at <addr>.

* ==================== OTHER CHANGES ====================

* The default value for the --smc-check option has been changed from
  "stack" to "all-non-file" on targets that provide automatic D-I
  cache coherence (x86, amd64 and s390x).  The result is to provide,
  by default, transparent support for JIT generated and self-modifying
  code on all targets.

* Mac OS X only: the default value for the --dsymutil option has been
  changed from "no" to "yes", since any serious usage on Mac OS X
  always required it to be "yes".

* The command line options --db-attach and --db-command have been removed.
  They were deprecated in 3.10.0.

* When a process dies due to a signal, Valgrind now shows the signal
  and the stacktrace at default verbosity (i.e. verbosity 1).

* The address description logic used by Memcheck and Helgrind now
  describes addresses in anonymous segments, file mmap-ed segments,
  shared memory segments and the brk data segment.

* The new option --error-markers=<begin>,<end> can be used to mark the
  begin/end of errors in textual output mode, to facilitate
  searching/extracting errors in output files that mix valgrind errors
  with program output.

* The new option --max-threads=<number> can be used to change the number
  of threads valgrind can handle.  The default is 500 threads which
  should be more than enough for most applications.

* The new option --valgrind-stacksize=<number> can be used to change the
  size of the private thread stacks used by Valgrind.  This is useful
  for reducing memory use or increasing the stack size if Valgrind
  segfaults due to stack overflow.

* The new option --avg-transtab-entry-size=<number> can be used to specify
  the expected instrumented block size, either to reduce memory use or
  to avoid excessive retranslation.

* Valgrind can be built with Intel's ICC compiler, version 14.0 or later.

* New and modified GDB server monitor features:

  - When a signal is reported in GDB, you can now use the GDB convenience
    variable $_siginfo to examine detailed signal information.

  - Valgrind's gdbserver now allows the user to change the signal
    to deliver to the process.  So, use 'signal SIGNAL' to continue execution
    with SIGNAL instead of the signal reported to GDB. Use 'signal 0' to
    continue without passing the signal to the process.

  - With GDB >= 7.10, the command 'target remote'
    will automatically load the executable file of the process running
    under Valgrind. This means you do not need to specify the executable
    file yourself, GDB will discover it itself.  See GDB documentation about
    'qXfer:exec-file:read' packet for more info.

* ==================== FIXED BUGS ====================

The following bugs have been fixed or resolved.  Note that "n-i-bz"
stands for "not in bugzilla" -- that is, a bug that was reported to us
but never got a bugzilla entry.  We encourage you to file bugs in
bugzilla (https://bugs.kde.org/enter_bug.cgi?product=valgrind) rather
than mailing the developers (or mailing lists) directly -- bugs that
are not entered into bugzilla tend to get forgotten about or ignored.

To see details of a given bug, visit
  https://bugs.kde.org/show_bug.cgi?id=XXXXXX
where XXXXXX is the bug number as listed below.

116002  VG_(printf): Problems with justification of strings and integers
155125  avoid cutting away file:lineno after long function name
197259  Unsupported arch_prtctl PR_SET_GS option
201152  ppc64: Assertion in ppc32g_dirtyhelper_MFSPR_268_269
201216  Fix Valgrind does not support pthread_sigmask() on OS X
201435  Fix Darwin: -v does not show kernel version
208217  "Warning: noted but unhandled ioctl 0x2000747b" on Mac OS X
211256  Fixed an outdated comment regarding the default platform.
211529  Incomplete call stacks for code compiled by newer versions of MSVC
211926  Avoid compilation warnings in valgrind.h with -pedantic
212291  Fix unhandled syscall: unix:132 (mkfifo) on OS X
        == 263119
226609  Crediting upstream authors in man page
231257  Valgrind omits path when executing script from shebang line
254164  OS X task_info: UNKNOWN task message [id 3405, to mach_task_self() [..]
269360  s390x: Fix addressing mode selection for compare-and-swap
302630  Memcheck: Assertion failed: 'sizeof(UWord) == sizeof(UInt)'
        == 326797
312989  ioctl handling needs to do POST handling on generic ioctls and [..]
319274  Fix unhandled syscall: unix:410 (sigsuspend_nocancel) on OS X
324181  mmap does not handle MAP_32BIT (handle it now, rather than fail it)
327745  Fix valgrind 3.9.0 build fails on Mac OS X 10.6.8
330147  libmpiwrap PMPI_Get_count returns undefined value
333051  mmap of huge pages fails due to incorrect alignment
        == 339163
334802  valgrind does not always explain why a given option is bad
335618  mov.w rN, pc/sp (ARM32)
335785  amd64->IR 0xC4 0xE2 0x75 0x2F (vmaskmovpd)
        == 307399
        == 343175
        == 342740
        == 346912
335907  segfault when running wine's ddrawex/tests/surface.c under valgrind
338602  AVX2 bit in CPUID missing
338606  Strange message for scripts with invalid interpreter
338731  ppc: Fix testuite build for toolchains not supporting -maltivec
338995  shmat with hugepages (SHM_HUGETLB) fails with EINVAL
339045  Getting valgrind to compile and run on OS X Yosemite (10.10)
        == 340252
339156  gdbsrv not called for fatal signal
339215  Valgrind 3.10.0 contain 2013 in copyrights notice
339288  support Cavium Octeon MIPS specific BBIT*32 instructions
339636  Use fxsave64 and fxrstor64 mnemonics instead of old-school rex64 prefix
339442  Fix testsuite build failure on OS X 10.9
339542  Enable compilation with Intel's ICC compiler
339563  The DVB demux DMX_STOP ioctl doesn't have a wrapper
339688  Mac-specific ASM does not support .version directive (cpuid,
        tronical and pushfpopf tests)
339745  Valgrind crash when check Marmalade app (partial fix)
339755  Fix known deliberate memory leak in setenv() on Mac OS X 10.9
339778  Linux/TileGx platform support for Valgrind
339780  Fix known uninitialised read in pthread_rwlock_init() on Mac OS X 10.9
339789  Fix none/tests/execve test on Mac OS X 10.9
339808  Fix none/tests/rlimit64_nofile test on Mac OS X 10.9
339820  vex amd64->IR: 0x66 0xF 0x3A 0x63 0xA 0x42 0x74 0x9 (pcmpistri $0x42)
340115  Fix none/tests/cmdline[1|2] tests on systems which define TMPDIR
340392  Allow user to select more accurate definedness checking in memcheck
        to avoid invalid complaints on optimised code
340430  Fix some grammatical weirdness in the manual.
341238  Recognize GCC5/DWARFv5 DW_LANG constants (Go, C11, C++11, C++14)
341419  Signal handler ucontext_t not filled out correctly on OS X
341539  VG_(describe_addr) should not describe address as belonging to client
        segment if it is past the heap end
341613  Enable building of manythreads and thread-exits tests on Mac OS X
341615  Fix none/tests/darwin/access_extended test on Mac OS X
341698  Valgrind's AESKEYGENASSIST gives wrong result in words 0 and 2 [..]
341789  aarch64: shmat fails with valgrind on ARMv8
341997  MIPS64: Cavium OCTEON insns - immediate operand handled incorrectly
342008  valgrind.h needs type cast [..] for clang/llvm in 64-bit mode
342038  Unhandled syscalls on aarch64 (mbind/get/set_mempolicy)
342063  wrong format specifier for test mcblocklistsearch in gdbserver_tests
342117  Hang when loading PDB file for MSVC compiled Firefox under Wine
342221  socket connect false positive uninit memory for unknown af family
342353  Allow dumping full massif output while valgrind is still running
342571  Valgrind chokes on AVX compare intrinsic with _CMP_GE_QS
        == 346476
        == 348387
        == 350593
342603  Add I2C_SMBUS ioctl support
342635  OS X 10.10 (Yosemite) - missing system calls and fcntl code
342683  Mark memory past the initial brk limit as unaddressable
342783  arm: unhandled instruction 0xEEFE1ACA = "vcvt.s32.f32 s3, s3, #12"
342795  Internal glibc __GI_mempcpy call should be intercepted
342841  s390x: Support instructions fiebr(a) and fidbr(a)
343012  Unhandled syscall 319 (memfd_create)
343069  Patch updating v4l2 API support
343173  helgrind crash during stack unwind
343219  fix GET_STARTREGS for arm
343303  Fix known deliberate memory leak in setenv() on Mac OS X 10.10
343306  OS X 10.10: UNKNOWN mach_msg unhandled MACH_SEND_TRAILER option
343332  Unhandled instruction 0x9E310021 (fcvtmu) on aarch64
343335  unhandled instruction 0x1E638400 (fccmp) aarch64
343523  OS X mach_ports_register: UNKNOWN task message [id 3403, to [..]
343525  OS X host_get_special_port: UNKNOWN host message [id 412, to [..]
343597  ppc64le: incorrect use of offseof macro
343649  OS X host_create_mach_voucher: UNKNOWN host message [id 222, to [..]
343663  OS X 10.10  Memchecj always reports a leak regardless of [..]
343732  Unhandled syscall 144 (setgid) on aarch64
343733  Unhandled syscall 187 (msgctl and related) on aarch64
343802  s390x: False positive "conditional jump or move depends on [..]
343902  --vgdb=yes doesn't break when --xml=yes is used
343967  Don't warn about setuid/setgid/setcap executable for directories
343978  Recognize DWARF5/GCC5 DW_LANG_Fortran 2003 and 2008 constants
344007  accept4 syscall unhandled on arm64 (242) and ppc64 (344)
344033  Helgrind on ARM32 loses track of mutex state in pthread_cond_wait
344054  www - update info for Solaris/illumos
344416  'make regtest' does not work cleanly on OS X
344235  Remove duplicate include of pub_core_aspacemgr.h
344279  syscall sendmmsg on arm64 (269) and ppc32/64 (349) unhandled
344295  syscall recvmmsg on arm64 (243) and ppc32/64 (343) unhandled
344307  2 unhandled syscalls on aarch64/arm64: umount2(39), mount (40)
344314  callgrind_annotate ... warnings about commands containing newlines
344318  socketcall should wrap recvmmsg and sendmmsg
344337  Fix unhandled syscall: mach:41 (_kernelrpc_mach_port_guard_trap)
344416  Fix 'make regtest' does not work cleanly on OS X
344499  Fix compilation for Linux kernel >= 4.0.0
344512  OS X: unhandled syscall: unix:348 (__pthread_chdir),
        unix:349 (__pthread_fchdir)
344559  Garbage collection of unused segment names in address space manager
344560  Fix stack traces missing penultimate frame on OS X
344621  Fix memcheck/tests/err_disable4 test on OS X
344686  Fix suppression for pthread_rwlock_init on OS X 10.10
344702  Fix missing libobjc suppressions on OS X 10.10
        == 344543
344936  Fix unhandled syscall: unix:473 (readlinkat) on OS X 10.10
344939  Fix memcheck/tests/xml1 on OS X 10.10
345016  helgrind/tests/locked_vs_unlocked2 is failing sometimes
345079  Fix build problems in VEX/useful/test_main.c
345126  Incorrect handling of VIDIOC_G_AUDIO and G_AUDOUT
345177  arm64: prfm (reg) not implemented
345215  Performance improvements for the register allocator
345248  add support for Solaris OS in valgrind
345338  TIOCGSERIAL and TIOCSSERIAL ioctl support on Linux
345394  Fix memcheck/tests/strchr on OS X
345637  Fix memcheck/tests/sendmsg on OS X
345695  Add POWERPC support for AT_DCACHESIZE and HWCAP2
345824  Fix aspacem segment mismatch: seen with none/tests/bigcode
345887  Fix an assertion in the address space manager
345928  amd64: callstack only contains current function for small stacks
345984  disInstr(arm): unhandled instruction: 0xEE193F1E
345987  MIPS64: Implement cavium LHX instruction
346031  MIPS: Implement support for the CvmCount register (rhwr %0, 31)
346185  Fix typo saving altivec register v24
346267  Compiler warnings for PPC64 code on call to LibVEX_GuestPPC64_get_XER()
        and LibVEX_GuestPPC64_get_CR()
346270  Regression tests none/tests/jm_vec/isa_2_07 and
        none/tests/test_isa_2_07_part2 have failures on PPC64 little endian
346307  fuse filesystem syscall deadlocks
346324  PPC64 missing support for lbarx, lharx, stbcx and sthcx instructions
346411  MIPS: SysRes::_valEx handling is incorrect
346416  Add support for LL_IOC_PATH2FID and LL_IOC_GETPARENT Lustre ioctls
346474  PPC64 Power 8, spr TEXASRU register not supported
346487  Compiler generates "note" about a future ABI change for PPC64
346562  MIPS64: lwl/lwr instructions are performing 64bit loads
        and causing spurious "invalid read of size 8" warnings
346801  Fix link error on OS X: _vgModuleLocal_sf_maybe_extend_stack
347151  Fix suppression for pthread_rwlock_init on OS X 10.8
347233  Fix memcheck/tests/strchr on OS X 10.10 (Haswell)
347322  Power PC regression test cleanup
347379  valgrind --leak-check=full leak errors from system libs on OS X 10.8
        == 217236
347389  unhandled syscall: 373 (Linux ARM syncfs)
347686  Patch set to cleanup PPC64 regtests
347978  Remove bash dependencies where not needed
347982  OS X: undefined symbols for architecture x86_64: "_global" [..]
347988  Memcheck: the 'impossible' happened: unexpected size for Addr (OSX/wine)
        == 345929
348102  Patch updating v4l2 API support
348247  amd64 front end: jno jumps wrongly when overflow is not set
348269  Improve mmap MAP_HUGETLB support.
348334  (ppc) valgrind does not simulate dcbfl - then my program terminates
348345  Assertion fails for negative lineno
348377  Unsupported ARM instruction: yield
348565  Fix detection of command line option availability for clang
348574  vex amd64->IR pcmpistri SSE4.2 unsupported (pcmpistri $0x18)
348728  Fix broken check for VIDIOC_G_ENC_INDEX
348748  Fix redundant condition
348890  Fix clang warning about unsupported --param inline-unit-growth=900
348949  Bogus "ERROR: --ignore-ranges: suspiciously large range"
349034  Add Lustre ioctls LL_IOC_GROUP_LOCK and LL_IOC_GROUP_UNLOCK
349086  Fix UNKNOWN task message [id 3406, to mach_task_self(), [..]
349087  Fix UNKNOWN task message [id 3410, to mach_task_self(), [..]
349626  Implemented additional Xen hypercalls
349769  Clang/osx: ld: warning: -read_only_relocs cannot be used with x86_64
349790  Clean up of the hardware capability checking utilities.
349828  memcpy intercepts memmove causing src/dst overlap error (ppc64 ld.so)
349874  Fix typos in source code
349879  memcheck: add handwritten assembly for helperc_LOADV*
349941  di_notify_mmap might create wrong start/size DebugInfoMapping
350062  vex x86->IR: 0x66 0xF 0x3A 0xB (ROUNDSD) on OS X
350202  Add limited param to 'monitor block_list'
350290  s390x: Support instructions fixbr(a)
350359  memcheck/tests/x86/fxsave hangs indefinetely on OS X
350809  Fix none/tests/async-sigs for Solaris
350811  Remove reference to --db-attach which has been removed.
350813  Memcheck/x86: enable handwritten assembly helpers for x86/Solaris too
350854  hard-to-understand code in VG_(load_ELF)()
351140  arm64 syscalls setuid (146) and setresgid (149) not implemented
351386  Solaris: Cannot run ld.so.1 under Valgrind
351474  Fix VG_(iseqsigset) as obvious
351534  Fix incorrect header guard
351632  Fix UNKNOWN fcntl 97 on OS X 10.11
351756  Intercept platform_memchr$VARIANT$Haswell on OS X
351858  ldsoexec support on Solaris
351873  Newer gcc doesn't allow __builtin_tabortdc[i] in ppc32 mode
352130  helgrind reports false races for printfs using mempcpy on FILE* state
352284  s390: Conditional jump depends on uninitialised value(s) in vfprintf
352320  arm64 crash on none/tests/nestedfs
352765  Vbit test fails on Power 6
352768  The mbar instruction is missing from the Power PC support
352769  Power PC program priority register (PPR) is not supported
n-i-bz  Provide implementations of certain compiler builtins to support
        compilers that may not provide those
n-i-bz  Old STABS code is still being compiled, but never used. Remove it.
n-i-bz  Fix compilation on distros with glibc < 2.5
n-i-bz  (vex 3098) Avoid generation of Neon insns on non-Neon hosts
n-i-bz  Enable rt_sigpending syscall on ppc64 linux.
n-i-bz  mremap did not work properly on shared memory
n-i-bz  Fix incorrect sizeof expression in syswrap-xen.c reported by Coverity
n-i-bz  In VALGRIND_PRINTF write out thread name, if any, to xml

(3.11.0.TEST1:  8 September 2015, vex r3187, valgrind r15646)
(3.11.0.TEST2: 21 September 2015, vex r3193, valgrind r15667)
(3.11.0:       22 September 2015, vex r3195, valgrind r15674)

Re: [Valgrind-users] Strange (at least to me) valgrind messages

[Tyson W. <twh...@gm...>]

On September 21, 2015 23:16:58 Tyson Whitehead wrote:
> I'll check the make sure, but I'm 99.9% certain the code doesn't use any of  
> the valgrind API.
> 
> I'm nearly certain its first exposure to valgrind was me running it just  
> now to help them track down some memory leak issues.
> 
> The client request in coming from the MPI wrapper library that ships with  
> valgrind.

Correction to that.  Seems it's from the OpenMPI library itself compiled with valgrind support (via the --enable-memchecker option).

Guess it must be marking a bunch of areas as invalid as you suggested.  I'll have to take it up on their mailing list.  Sorry for the noise.

Cheers!  -Tyson

Re: [Valgrind-users] Strange (at least to me) valgrind messages

[Tyson W. <twh...@gm...>]

I'll check the make sure, but I'm 99.9% certain the code doesn't use any of
the valgrind API.

I'm nearly certain its first exposure to valgrind was me running it just
now to help them track down some memory leak issues.

The client request in coming from the MPI wrapper library that ships with
valgrind.

Thanks!  -Tyson

On Mon, Sep 21, 2015, 19:05 Tom Hughes <to...@co...> wrote:

> On 21/09/15 23:04, Tyson Whitehead wrote:
>
> > ==32704== Unaddressable byte(s) found during client check request
> > ...
> > ==32704==  Address 0x243e6040 is 16,384 bytes inside a block of size
> 1,048,576 alloc'd
> > ...
> >
> > and
> >
> > ==32704== Invalid read of size 8
> > ...
> > ==32704==  Address 0x22fe2040 is 0 bytes inside a block of size
> 1,048,576 alloc'd
> > ...
> >
> > and
> >
> > ==32704== Invalid write of size 8
> > ...
> > ==32704==  Address 0x22fe2048 is 8 bytes inside a block of size
> 1,048,576 alloc'd
> > ...
> >
> > and on and on and on ...
> >
> > Are these valid errors?  Everything I found online seemed to indicate
> that error addresses should not fall entirely inside allocated blocks.
>
> Why should they not be valid? It probably just means somebody has used a
> client request to mark that address as invalid.
>
> Tom
>
> --
> Tom Hughes (to...@co...)
> http://compton.nu/
>

Re: [Valgrind-users] Strange (at least to me) valgrind messages

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

On 21/09/15 23:04, Tyson Whitehead wrote:

> ==32704== Unaddressable byte(s) found during client check request
> ...
> ==32704==  Address 0x243e6040 is 16,384 bytes inside a block of size 1,048,576 alloc'd
> ...
>
> and
>
> ==32704== Invalid read of size 8
> ...
> ==32704==  Address 0x22fe2040 is 0 bytes inside a block of size 1,048,576 alloc'd
> ...
>
> and
>
> ==32704== Invalid write of size 8
> ...
> ==32704==  Address 0x22fe2048 is 8 bytes inside a block of size 1,048,576 alloc'd
> ...
>
> and on and on and on ...
>
> Are these valid errors?  Everything I found online seemed to indicate that error addresses should not fall entirely inside allocated blocks.

Why should they not be valid? It probably just means somebody has used a 
client request to mark that address as invalid.

Tom

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

Re: [Valgrind-users] Strange (at least to me) valgrind messages

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

> I've been working on debugging someone else's MPI code and am getting error messages that seem pretty strange to me
>
> ==32704== Memcheck, a memory error detector
> ==32704== Copyright (C) 2002-2013, and GNU GPL'd, by Julian Seward et al.
> ==32704== Using Valgrind-3.10.1 and LibVEX; rerun with -h for copyright info

Thank you for including the version number.  Next, what is the hardware architecture?

>
> ...
>
> ==32704== Unaddressable byte(s) found during client check request
> ...
> ==32704==  Address 0x243e6040 is 16,384 bytes inside a block of size 1,048,576 alloc'd

1,048,576 == (1<<20)  so somebody has flubbed the connection between malloc, mmap, and memcheck.

> ...
>
> and
>
> ==32704== Invalid read of size 8
> ...
> ==32704==  Address 0x22fe2040 is 0 bytes inside a block of size 1,048,576 alloc'd
> ...
>
> and
>
> ==32704== Invalid write of size 8
> ...
> ==32704==  Address 0x22fe2048 is 8 bytes inside a block of size 1,048,576 alloc'd

Please submit a bug report.  http://valgrind.org/support/bug_reports.html

[Valgrind-users] Strange (at least to me) valgrind messages

[Tyson W. <twh...@gm...>]

I've been working on debugging someone else's MPI code and am getting error messages that seem pretty strange to me

==32704== Memcheck, a memory error detector
==32704== Copyright (C) 2002-2013, and GNU GPL'd, by Julian Seward et al.
==32704== Using Valgrind-3.10.1 and LibVEX; rerun with -h for copyright info

...

==32704== Unaddressable byte(s) found during client check request
...
==32704==  Address 0x243e6040 is 16,384 bytes inside a block of size 1,048,576 alloc'd
...

and

==32704== Invalid read of size 8
...
==32704==  Address 0x22fe2040 is 0 bytes inside a block of size 1,048,576 alloc'd
...

and

==32704== Invalid write of size 8
...
==32704==  Address 0x22fe2048 is 8 bytes inside a block of size 1,048,576 alloc'd
...

and on and on and on ...

Are these valid errors?  Everything I found online seemed to indicate that error addresses should not fall entirely inside allocated blocks.

Thanks!  -Tyson

PS:  This was run with --track-origins=yes and --leak-check=yes.