valgrind-users — General discussion list for Valgrind users

[Valgrind-users] Callgrind

[Olaf L. <ol...@ic...>]

Hi everybody!

I am trying to use callgrind (3.8.0) to profile our simulation software
ESPResSo (http://espressomd.org) on Linux.

Unfortunately, callgrind seems to loose the information on where to find
the source files when running the binary.  When I use 'nm -lC Espresso' on
the binary file, I see that the binary does contain the source code
information, e.g.:

000000000049e605 W add_lj_pair_force(Particle*, Particle*, IA_parameters*,
double*, double, double*)
 /home/olenz/projects/espresso/src/src/core/lj.hpp:45

However, when I run the binary under callgrind, the output file does not
contain any of the symbols from the binary file, but only the addresses.

Interestingly, when I test callgrind on a simple test program, everything
works fine...

Steps to reproduce:
1. Download source code.
2. Compile with
> configure CXXFLAGS="-O0 -g"
> make
3. Check the binary file that it contains symbols:
> nm -lC Espresso | grep add_lj_pair_force
4. Run test with
> cd testsuite
> valgrind --tool=callgrind ../Espresso lj.tcl
5. Examine "callgrind.out.XXX": no symbols are contained.

Does anybody have an idea what goes wrong?

Olaf

-- 
Dr. rer. nat. Olaf Lenz
Institut für Computerphysik, Allmandring 3, D-70569 Stuttgart
Phone: +49-711-685-63607

[Valgrind-users] Valgrind does not support powerpcspe toolchains for e500v2

[Rajendra D. <raj...@br...>]

Hi,

I noticed that Valgrind-3.9.0 does not support the powerpc SPE based toolchains for e500v2 based platforms.  buildroot currently does not allow classic PowerPC ABI to be selectable for e500v2/e500v1 class of machines.

I do not want to switch to classic ABI as I want to build toolchains out of buildroot without any customizations. Is there any patch available for Valgrind to support SPE instructions.

Thanks,
Rajendra Dendukuri

Re: [Valgrind-users] Valgrind doesnot show any memory Leaks

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

I think we saw recently (last couple of months?) a case where Memcheck
didn't do any intercepts with uClibC, and it turned out that the problem
was that uClibc had not been built with LD_PRELOAD support.  So the
intercept .so never got loaded into the process.  I wonder if that is
the case here?

J

On 07/09/2014 12:43 PM, Philippe Waroquiers wrote:
> On Wed, 2014-07-09 at 15:58 +0530, Jonnavithula Sharma wrote:
>> Hi ,
>>
> ...
>> But somehow there were no leaks detected and the output is as
>> below(attached is the complete valgrind output)
>>         
> ...
>> Any suggestions or help is highly appreciated.
>>
>>
>> I am compiling my application with all debug options as well. I was
>> struck and not able to proceed ahead.
> 
> The most frequent source of this kind of problems is the fact
> that the malloc library is statically linked with your app.
> 
> You must then indicate that to valgrind, using the option
>    --soname-synonyms=...
> (see user manual for details).
> 
> If that is not the case, then the 2nd most frequent source of problem
> is that the redirection of the malloc etc symbols are not done
> due to the name of the library not being what is expected by valgrind.
> Use the options -v -v -v -d -d -d --trace-redir=yes
> and try to understand what is going wrong.
> 
> 
> Philippe
> 
> 
> 
> 
> ------------------------------------------------------------------------------
> Open source business process management suite built on Java and Eclipse
> Turn processes into business applications with Bonita BPM Community Edition
> Quickly connect people, data, and systems into organized workflows
> Winner of BOSSIE, CODIE, OW2 and Gartner awards
> http://p.sf.net/sfu/Bonitasoft
> _______________________________________________
> Valgrind-users mailing list
> Val...@li...
> https://lists.sourceforge.net/lists/listinfo/valgrind-users
> 

[Valgrind-users] valgrind-3.9.0 on MIPS64 fails to load any binary

[Filip B. <fil...@gm...>]

Hi, anyone can help with this problem of valgrind failure on an embedded
mips  platform?

Executing valgrind /bin/ls (as well as with any other binary) always fails
shortly after starting because of:

Inconsistency detected by ld.so: ../elf/dl-sysdep.c: 457:
_dl_important_hwcaps: Assertion `m == cnt' failed!

This is Linux version 2.6.27.39 (gcc version 4.3.2 ) #1 SMP PREEMPT Thu Mar
27 14:46:35 KST 2014 mips64 mips64 mips64 GNU/Linux

with glibc 2.8, ld-2.8.so

valgrind was cross compiled.

I have little experience with linux shared lib mechanics so not sure what
is needed to investigate this but I am willing to provide necessary
information if specific instructions are given.

Regards,
Filip

Re: [Valgrind-users] Memcheck with Jikes RVM

[Karl C. <ka...@cs...>]

On 07/08/2014 02:04 PM, Philippe Waroquiers wrote:
> On Tue, 2014-07-08 at 03:49 -0400, Karl Cronburg wrote:
>> Any idea as to what's going on, or how I might debug the problem further?
>> Any Valgrind flags or options I might be missing? The RVM runs fine
>> on its' own, as well as in Nulgrind (and cachegrind and callgrind):
> 
> From what I can see, the above happens when Valgrind is not able to
> track properly the stack used by a thread.
> The 'switching stacks' messages very probably indicate that the jikes
> rvm does something special with stack.
> If that is the case, then usually the problem can be solved by adding
> client requests in the application code (the various VALGRIND_STACK_*
> client requests in valgrind.h).
> 
> 
> This might also happen due to the use of sigaltstack.
> It is unclear to me how to properly inform Valgrind of such alternate
> stack.
> 
> In both case, basically, the problem is that valgrind believes that the
> stack goes from the current stack pointer value till the "last known
> stack base". When changing stack; this can include non addressable
> segments. The stack unwind code assumes however that everything is
> accessible between the current sp and the stack base.

You're right, this was the problem. I verified that the stack base pointer
was way to large (right next to the SIGSEGV address). I've also found that
everything runs fine when I add the "--keep-stacktraces=none" flag, which
is acceptable for now since I'm more interested in the Java stack traces
inside the RVM anyways.

Thanks!
-Karl-

Re: [Valgrind-users] Valgrind doesnot show any memory Leaks

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

On Wed, 2014-07-09 at 15:58 +0530, Jonnavithula Sharma wrote:
> Hi ,
> 
...
> But somehow there were no leaks detected and the output is as
> below(attached is the complete valgrind output)
>         
...
> Any suggestions or help is highly appreciated.
> 
> 
> I am compiling my application with all debug options as well. I was
> struck and not able to proceed ahead.

The most frequent source of this kind of problems is the fact
that the malloc library is statically linked with your app.

You must then indicate that to valgrind, using the option
   --soname-synonyms=...
(see user manual for details).

If that is not the case, then the 2nd most frequent source of problem
is that the redirection of the malloc etc symbols are not done
due to the name of the library not being what is expected by valgrind.
Use the options -v -v -v -d -d -d --trace-redir=yes
and try to understand what is going wrong.


Philippe

Re: [Valgrind-users] Valgrind doesnot show any memory Leaks

[Jonnavithula S. <sar...@gm...>]

Hi ,

Any suggestions or help is highly appreciated.

I am compiling my application with all debug options as well. I was struck
and not able to proceed ahead.

Please help!

Regards,
Sarma J


On Tue, Jul 1, 2014 at 7:48 PM, Jonnavithula Sharma <sar...@gm...>
wrote:

> Hi All,
>
> I succesfully compiled Openwrt valgrind for Mips architechture with Uclibc
> toolchain and able to run on target.
>
> But somehow there were no leaks detected and the output is as
> below(attached is the complete valgrind output)
>
> =3338==
> ==3338== HEAP SUMMARY:
> ==3338==     in use at exit: 0 bytes in 0 blocks
> ==3338==   total heap usage: 0 allocs, 0 frees, 0 bytes allocated
> ==3338==
> ==3338== All heap blocks were freed -- no leaks are possible
> ==3338==
> ==3338== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 30 from 4)
> --3338--
>
>
> Did anyone face this error? Or am i missing anything ? . Let me know if
> anyone tried valgrind on mips architechture with uClibc toolchain.
>
> Are there any other flags or options to be enabled?
>
> More info:
> Toolchain : toolchain-mips_r2_gcc-4.8-linaro_uClibc-0.9.33.2
>
> valgrind version : tried on 3.8.1 , 3.9.0 (taken from openwrt trunk)
>
> Linux Kernel Version : 3.10.12
>
> Cpu info is attached here as well.
>
> Please help!
>
> Thanks & Regards
> Sarma J
>
>

Re: [Valgrind-users] Memcheck with Jikes RVM

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

On Tue, 2014-07-08 at 16:14 -0400, Eliot Moss wrote:
> On 7/8/2014 3:47 PM, Karl Cronburg wrote:
> > On 07/08/2014 02:48 PM, Philippe Waroquiers wrote:
> >> On Tue, 2014-07-08 at 14:39 -0400, Eliot Moss wrote:
> >>> On 7/8/2014 2:04 PM, Philippe Waroquiers wrote:
> >>>> On Tue, 2014-07-08 at 03:49 -0400, Karl Cronburg wrote:
> 
> > We're interested in using malloc/free client requests to see if we can
> > get memcheck to tell us when the garbage collector is handling its'
> > own memory incorrectly.
> 
> That sounds like a radical change to Jikes RVM.  At present it
> doesn't really use malloc/free.  It mmaps big chunks and manages
> them all itself, both for the system (i.e., outside of the garbage
> collected universe) and for the GC'ed heap.
Valgrind has client requests that can be used to describe
"user managed pool".

These are a.o. used to run "valgrind in valgrind", so as to find
valgrind bugs with itself.

These requests are supposed to be general enough to describe most
"user defined" memory pools

Philippe

Re: [Valgrind-users] Memcheck with Jikes RVM

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

On 7/8/2014 3:47 PM, Karl Cronburg wrote:
> On 07/08/2014 02:48 PM, Philippe Waroquiers wrote:
>> On Tue, 2014-07-08 at 14:39 -0400, Eliot Moss wrote:
>>> On 7/8/2014 2:04 PM, Philippe Waroquiers wrote:
>>>> On Tue, 2014-07-08 at 03:49 -0400, Karl Cronburg wrote:

> We're interested in using malloc/free client requests to see if we can
> get memcheck to tell us when the garbage collector is handling its'
> own memory incorrectly.

That sounds like a radical change to Jikes RVM.  At present it
doesn't really use malloc/free.  It mmaps big chunks and manages
them all itself, both for the system (i.e., outside of the garbage
collected universe) and for the GC'ed heap.

Best wishes -- EM

Re: [Valgrind-users] Memcheck with Jikes RVM

[Karl C. <ka...@cs...>]

On 07/08/2014 02:48 PM, Philippe Waroquiers wrote:
> On Tue, 2014-07-08 at 14:39 -0400, Eliot Moss wrote:
>> On 7/8/2014 2:04 PM, Philippe Waroquiers wrote:
>>> On Tue, 2014-07-08 at 03:49 -0400, Karl Cronburg wrote:
>>
>> I can confirm that Jikes RVM does it own special allocation
>> of stacks, which might be involved here.
>>
>> I am wondering why anyone would think a tool like memcheck
>> would work with a Java virtual machine like JikesRVM, with
>> its own notion of object, garbage collection, etc.  For
>> example, JikesRVM almost certainly explicitly clears memory
>> before using it for objects, which would mean it is initialized,
>> and verified Java bytecode will never access an uninitialized
>> local variable.  I suppose you might get some mileage on
>> checking JNI / native code stuff, but I'm not sure.  So,
>> I am intrigued, but also wondering if maybe you're barking
>> up the wrong tree here ...
>>
>> Regards -- Eliot (Hi, Sam!)
> I guess memcheck could be useful for checking the RVM itself,
> not the Java code run by RVM.
> And maybe things like cachegrind/callgrind/helgrind might be useful ?
> 
> Note that I have since a long time on my list of things to never do
> to look at defining client requests allowing a JIT compiler to
> indicate to Valgrind how to unwind and so make a reasonable
> "source" stacktrace of the JIT-ed code.
> Might make Valgrind a lot more interesting for mixed JIT code and JNI
> and 'virtual machine implementation' follow up.
> 
> Philippe
> 
> 

We're interested in using malloc/free client requests to see if we can
get memcheck to tell us when the garbage collector is handling its'
own memory incorrectly.

-Karl-

Re: [Valgrind-users] Memcheck with Jikes RVM

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

On Tue, 2014-07-08 at 14:39 -0400, Eliot Moss wrote:
> On 7/8/2014 2:04 PM, Philippe Waroquiers wrote:
> > On Tue, 2014-07-08 at 03:49 -0400, Karl Cronburg wrote:
> 
> I can confirm that Jikes RVM does it own special allocation
> of stacks, which might be involved here.
> 
> I am wondering why anyone would think a tool like memcheck
> would work with a Java virtual machine like JikesRVM, with
> its own notion of object, garbage collection, etc.  For
> example, JikesRVM almost certainly explicitly clears memory
> before using it for objects, which would mean it is initialized,
> and verified Java bytecode will never access an uninitialized
> local variable.  I suppose you might get some mileage on
> checking JNI / native code stuff, but I'm not sure.  So,
> I am intrigued, but also wondering if maybe you're barking
> up the wrong tree here ...
> 
> Regards -- Eliot (Hi, Sam!)
I guess memcheck could be useful for checking the RVM itself,
not the Java code run by RVM.
And maybe things like cachegrind/callgrind/helgrind might be useful ?

Note that I have since a long time on my list of things to never do
to look at defining client requests allowing a JIT compiler to
indicate to Valgrind how to unwind and so make a reasonable
"source" stacktrace of the JIT-ed code.
Might make Valgrind a lot more interesting for mixed JIT code and JNI
and 'virtual machine implementation' follow up.

Philippe

Re: [Valgrind-users] Memcheck with Jikes RVM

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

On 7/8/2014 2:04 PM, Philippe Waroquiers wrote:
> On Tue, 2014-07-08 at 03:49 -0400, Karl Cronburg wrote:

I can confirm that Jikes RVM does it own special allocation
of stacks, which might be involved here.

I am wondering why anyone would think a tool like memcheck
would work with a Java virtual machine like JikesRVM, with
its own notion of object, garbage collection, etc.  For
example, JikesRVM almost certainly explicitly clears memory
before using it for objects, which would mean it is initialized,
and verified Java bytecode will never access an uninitialized
local variable.  I suppose you might get some mileage on
checking JNI / native code stuff, but I'm not sure.  So,
I am intrigued, but also wondering if maybe you're barking
up the wrong tree here ...

Regards -- Eliot (Hi, Sam!)

Re: [Valgrind-users] Memcheck with Jikes RVM

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

On Tue, 2014-07-08 at 03:49 -0400, Karl Cronburg wrote:
> Hello,
> 
> I am trying to get memcheck (valgrind-3.10.0.SVN) to run Jikes RVM (3.1.3+hg)
> on an x86_64-linux machine in 32-bit mode. However when I run:
> 
> WRAP="valgrind --smc-check=all --undef-value-errors=no --workaround-gcc296-bugs=yes"
> rvm -wrap "$WRAP" -X:gc:eagerMmapSpaces=true HelloWorld
> 
> I get a SIGSEGV in memcheck:
> 
> ==10692== Memcheck, a memory error detector
> ==10692== Copyright (C) 2002-2013, and GNU GPL'd, by Julian Seward et al.
> ==10692== Using Valgrind-3.10.0.SVN and LibVEX; rerun with -h for copyright info
> ==10692== Command: /home/karl/r/jikesrvm/dist/development_x86_64-linux/JikesRVM -X:ic=/home/karl/r/jikesrvm/dist/development_x86_64-linux/RVM.code.image -X:id=/home/karl/r/jikesrvm/dist/development_x86_64-linux/RVM.data.image -X:ir=/home/karl/r/jikesrvm/dist/development_x86_64-linux/RVM.rmap.image -X:vmClasses=/home/karl/r/jikesrvm/dist/development_x86_64-linux/jksvm.jar:/home/karl/r/jikesrvm/dist/development_x86_64-linux/rvmrt.jar -Duser.timezone=PDT -Djava.home=/home/karl/r/jikesrvm/dist/development_x86_64-linux -Dgnu.classpath.home.url=file:/home/karl/r/jikesrvm/dist/development_x86_64-linux -Dgnu.classpath.vm.shortname=JikesRVM -Duser.home=/home/karl -Duser.dir=/home/karl/r -Duser.name=karl -Dos.name=Linux -Dos.version=3.8.0-42-generic -Dos.arch=x86_64 -X:gc:eagerMmapSpaces=true HelloWorld
> ==10692== 
> ==10692== Warning: client switching stacks?  SP change: 0xfecf3a78 --> 0x42048468
> ==10692==          to suppress, use: --max-stackframe=1127565808 or greater
> ==10692== Warning: client switching stacks?  SP change: 0x4f522d8 --> 0x50c43000
> ==10692==          to suppress, use: --max-stackframe=1271860520 or greater
> ==10692== Warning: client switching stacks?  SP change: 0x57532d8 --> 0x50c87000
> ==10692==          to suppress, use: --max-stackframe=1263746344 or greater
> ==10692==          further instances of this message will not be shown.
> --10692-- VALGRIND INTERNAL ERROR: Valgrind received a signal 11 (SIGSEGV) - exiting
> --10692-- si_code=1;  Faulting address: 0x80000105;  sp: 0x82d10c7c
> 
> valgrind: the 'impossible' happened:
>    Killed by fatal signal
> 
> host stacktrace:
> ==10692==    at 0x380660F4: vgPlain_get_StackTrace_wrk (m_stacktrace.c:324)
> ==10692==    by 0x38066438: vgPlain_get_StackTrace (m_stacktrace.c:1441)
> ==10692==    by 0x3804992F: record_ExeContext_wrk (m_execontext.c:341)
> ==10692==    by 0x3801EFA4: vgMemCheck_set_allocated_at (mc_malloc_wrappers.c:305)
> ==10692==    by 0x3801F349: create_MC_Chunk (mc_malloc_wrappers.c:203)
> ==10692==    by 0x3801F69E: vgMemCheck_new_block (mc_malloc_wrappers.c:393)
> ==10692==    by 0x3801F875: vgMemCheck_malloc (mc_malloc_wrappers.c:412)
> ==10692==    by 0x380A7E5E: vgPlain_scheduler (scheduler.c:1783)
> ==10692==    by 0x380BA357: run_a_thread_NORETURN (syswrap-linux.c:103)

> Any idea as to what's going on, or how I might debug the problem further?
> Any Valgrind flags or options I might be missing? The RVM runs fine
> on its' own, as well as in Nulgrind (and cachegrind and callgrind):

>From what I can see, the above happens when Valgrind is not able to
track properly the stack used by a thread.
The 'switching stacks' messages very probably indicate that the jikes
rvm does something special with stack.
If that is the case, then usually the problem can be solved by adding
client requests in the application code (the various VALGRIND_STACK_*
client requests in valgrind.h).


This might also happen due to the use of sigaltstack.
It is unclear to me how to properly inform Valgrind of such alternate
stack.

In both case, basically, the problem is that valgrind believes that the
stack goes from the current stack pointer value till the "last known
stack base". When changing stack; this can include non addressable
segments. The stack unwind code assumes however that everything is
accessible between the current sp and the stack base.

You might try to confirm the above by changing in m_stacktraces.c
   const Bool   debug = False;
to
   const Bool   debug = True;

and then be patient till you see the crash (as this will trace a lot
for each unwind).

Philippe

[Valgrind-users] Memcheck with Jikes RVM

[Karl C. <ka...@cs...>]

Hello,

I am trying to get memcheck (valgrind-3.10.0.SVN) to run Jikes RVM (3.1.3+hg)
on an x86_64-linux machine in 32-bit mode. However when I run:

WRAP="valgrind --smc-check=all --undef-value-errors=no --workaround-gcc296-bugs=yes"
rvm -wrap "$WRAP" -X:gc:eagerMmapSpaces=true HelloWorld

I get a SIGSEGV in memcheck:

==10692== Memcheck, a memory error detector
==10692== Copyright (C) 2002-2013, and GNU GPL'd, by Julian Seward et al.
==10692== Using Valgrind-3.10.0.SVN and LibVEX; rerun with -h for copyright info
==10692== Command: /home/karl/r/jikesrvm/dist/development_x86_64-linux/JikesRVM -X:ic=/home/karl/r/jikesrvm/dist/development_x86_64-linux/RVM.code.image -X:id=/home/karl/r/jikesrvm/dist/development_x86_64-linux/RVM.data.image -X:ir=/home/karl/r/jikesrvm/dist/development_x86_64-linux/RVM.rmap.image -X:vmClasses=/home/karl/r/jikesrvm/dist/development_x86_64-linux/jksvm.jar:/home/karl/r/jikesrvm/dist/development_x86_64-linux/rvmrt.jar -Duser.timezone=PDT -Djava.home=/home/karl/r/jikesrvm/dist/development_x86_64-linux -Dgnu.classpath.home.url=file:/home/karl/r/jikesrvm/dist/development_x86_64-linux -Dgnu.classpath.vm.shortname=JikesRVM -Duser.home=/home/karl -Duser.dir=/home/karl/r -Duser.name=karl -Dos.name=Linux -Dos.version=3.8.0-42-generic -Dos.arch=x86_64 -X:gc:eagerMmapSpaces=true HelloWorld
==10692== 
==10692== Warning: client switching stacks?  SP change: 0xfecf3a78 --> 0x42048468
==10692==          to suppress, use: --max-stackframe=1127565808 or greater
==10692== Warning: client switching stacks?  SP change: 0x4f522d8 --> 0x50c43000
==10692==          to suppress, use: --max-stackframe=1271860520 or greater
==10692== Warning: client switching stacks?  SP change: 0x57532d8 --> 0x50c87000
==10692==          to suppress, use: --max-stackframe=1263746344 or greater
==10692==          further instances of this message will not be shown.
--10692-- VALGRIND INTERNAL ERROR: Valgrind received a signal 11 (SIGSEGV) - exiting
--10692-- si_code=1;  Faulting address: 0x80000105;  sp: 0x82d10c7c

valgrind: the 'impossible' happened:
   Killed by fatal signal

host stacktrace:
==10692==    at 0x380660F4: vgPlain_get_StackTrace_wrk (m_stacktrace.c:324)
==10692==    by 0x38066438: vgPlain_get_StackTrace (m_stacktrace.c:1441)
==10692==    by 0x3804992F: record_ExeContext_wrk (m_execontext.c:341)
==10692==    by 0x3801EFA4: vgMemCheck_set_allocated_at (mc_malloc_wrappers.c:305)
==10692==    by 0x3801F349: create_MC_Chunk (mc_malloc_wrappers.c:203)
==10692==    by 0x3801F69E: vgMemCheck_new_block (mc_malloc_wrappers.c:393)
==10692==    by 0x3801F875: vgMemCheck_malloc (mc_malloc_wrappers.c:412)
==10692==    by 0x380A7E5E: vgPlain_scheduler (scheduler.c:1783)
==10692==    by 0x380BA357: run_a_thread_NORETURN (syswrap-linux.c:103)

sched status:
  running_tid=1

Thread 1: status = VgTs_Runnable


Looking at /proc/PID/maps shows that the faulting address (0x80000105) is not
mapped, and is located right above the RVM's heap (which I hard coded to end
at 0x80000000):

ffcd5000-ffcf7000 rw-p 00000000 00:00 0 
fecf3000-fecf5000 rw-p 00000000 00:00 0 
85c12000-85e11000 rwxp 00000000 00:00 0 
82e04000-8591d000 rwxp 00000000 00:00 0 
82d11000-82d13000 ---p 00000000 00:00 0 
82c11000-82d11000 rwxp 00000000 00:00 0                                  [stack:10692]
82c0f000-82c11000 ---p 00000000 00:00 0 
829f6000-82c0f000 rwxp 00000000 00:00 0 
8290f000-82977000 rwxp 00000000 00:00 0 
8290e000-8290f000 rw-s 00000000 08:01 2756955                            /tmp/vgdb-pipe-shared-mem-vgdb-10692-by-karl-on-???
81e7b000-8290e000 rwxp 00000000 00:00 0 
77400000-80000000 rwxp 00000000 00:00 0 
50000000-77400000 rwxp 00000000 00:00 0 
47000000-47056000 r--p 00000000 08:01 2501782                            /home/karl/r/jikesrvm/dist/development_x86_64-linux/RVM.rmap.image
44000000-45062000 rwxp 00000000 08:01 2498986                            /home/karl/r/jikesrvm/dist/development_x86_64-linux/RVM.code.image
40000000-420b0000 rwxp 00000000 08:01 2501780                            /home/karl/r/jikesrvm/dist/development_x86_64-linux/RVM.data.image
38367000-39456000 rw-p 00000000 00:00 0 
38364000-38367000 rw-p 00363000 08:01 4334855                            /usr/local/lib/valgrind/memcheck-x86-linux
38000000-38364000 r-xp 00000000 08:01 4334855                            /usr/local/lib/valgrind/memcheck-x86-linux
08060000-08061000 rwxp 00000000 00:00 0 
0805f000-08060000 rw-p 00016000 08:01 2501798                            /home/karl/r/jikesrvm/dist/development_x86_64-linux/JikesRVM
0805d000-0805f000 r--p 00014000 08:01 2501798                            /home/karl/r/jikesrvm/dist/development_x86_64-linux/JikesRVM
08048000-0805d000 r-xp 00000000 08:01 2501798                            /home/karl/r/jikesrvm/dist/development_x86_64-linux/JikesRVM
04352000-04752000 rwxp 00000000 00:00 0 
0434d000-04352000 rw-p 00000000 00:00 0 
0434c000-0434d000 rw-p 001a6000 08:01 1442032                            /lib/i386-linux-gnu/libc-2.15.so
0434a000-0434c000 r--p 001a4000 08:01 1442032                            /lib/i386-linux-gnu/libc-2.15.so
041a6000-0434a000 r-xp 00000000 08:01 1442032                            /lib/i386-linux-gnu/libc-2.15.so
041a5000-041a6000 rw-p 0001c000 08:01 1442000                            /lib/i386-linux-gnu/libgcc_s.so.1
041a4000-041a5000 r--p 0001b000 08:01 1442000                            /lib/i386-linux-gnu/libgcc_s.so.1
04188000-041a4000 r-xp 00000000 08:01 1442000                            /lib/i386-linux-gnu/libgcc_s.so.1
04187000-04188000 rw-p 00000000 00:00 0 
04186000-04187000 rw-p 0002a000 08:01 1442027                            /lib/i386-linux-gnu/libm-2.15.so
04185000-04186000 r--p 00029000 08:01 1442027                            /lib/i386-linux-gnu/libm-2.15.so
0415b000-04185000 r-xp 00000000 08:01 1442027                            /lib/i386-linux-gnu/libm-2.15.so
04154000-0415b000 rw-p 00000000 00:00 0 
04153000-04154000 rw-p 000dc000 08:01 4070234                            /usr/lib32/libstdc++.so.6.0.16
0414f000-04153000 r--p 000d8000 08:01 4070234                            /usr/lib32/libstdc++.so.6.0.16
0414e000-0414f000 ---p 000d8000 08:01 4070234                            /usr/lib32/libstdc++.so.6.0.16
04076000-0414e000 r-xp 00000000 08:01 4070234                            /usr/lib32/libstdc++.so.6.0.16
04075000-04076000 rw-p 00001000 08:01 2501799                            /home/karl/r/jikesrvm/dist/development_x86_64-linux/librvm.so
04074000-04075000 r--p 00000000 08:01 2501799                            /home/karl/r/jikesrvm/dist/development_x86_64-linux/librvm.so
04073000-04074000 r-xp 00000000 08:01 2501799                            /home/karl/r/jikesrvm/dist/development_x86_64-linux/librvm.so
04072000-04073000 rw-p 00003000 08:01 1442031                            /lib/i386-linux-gnu/libdl-2.15.so
04071000-04072000 r--p 00002000 08:01 1442031                            /lib/i386-linux-gnu/libdl-2.15.so
0406e000-04071000 r-xp 00000000 08:01 1442031                            /lib/i386-linux-gnu/libdl-2.15.so
0406c000-0406e000 rw-p 00000000 00:00 0 
0406b000-0406c000 rw-p 00017000 08:01 1442021                            /lib/i386-linux-gnu/libpthread-2.15.so
0406a000-0406b000 r--p 00016000 08:01 1442021                            /lib/i386-linux-gnu/libpthread-2.15.so
04053000-0406a000 r-xp 00000000 08:01 1442021                            /lib/i386-linux-gnu/libpthread-2.15.so
04052000-04053000 rw-p 00000000 00:00 0 
04051000-04052000 rw-p 00007000 08:01 1442023                            /lib/i386-linux-gnu/librt-2.15.so
04050000-04051000 r--p 00006000 08:01 1442023                            /lib/i386-linux-gnu/librt-2.15.so
04049000-04050000 r-xp 00000000 08:01 1442023                            /lib/i386-linux-gnu/librt-2.15.so
04036000-04037000 rw-p 0000e000 08:01 4334857                            /usr/local/lib/valgrind/vgpreload_memcheck-x86-linux.so
04035000-04036000 r--p 0000d000 08:01 4334857                            /usr/local/lib/valgrind/vgpreload_memcheck-x86-linux.so
04027000-04035000 r-xp 00000000 08:01 4334857                            /usr/local/lib/valgrind/vgpreload_memcheck-x86-linux.so
04026000-04027000 rw-p 00001000 08:01 4334750                            /usr/local/lib/valgrind/vgpreload_core-x86-linux.so
04025000-04026000 r--p 00000000 08:01 4334750                            /usr/local/lib/valgrind/vgpreload_core-x86-linux.so
04024000-04025000 r-xp 00000000 08:01 4334750                            /usr/local/lib/valgrind/vgpreload_core-x86-linux.so
04022000-04024000 rw-p 00000000 00:00 0 
04021000-04022000 rw-p 00020000 08:01 1442022                            /lib/i386-linux-gnu/ld-2.15.so
04020000-04021000 r--p 0001f000 08:01 1442022                            /lib/i386-linux-gnu/ld-2.15.so
04000000-04020000 r-xp 00000000 08:01 1442022                            /lib/i386-linux-gnu/ld-2.15.so

Any idea as to what's going on, or how I might debug the problem further?
Any Valgrind flags or options I might be missing? The RVM runs fine
on its' own, as well as in Nulgrind (and cachegrind and callgrind):

$ WRAP="valgrind --tool=none"
$ rvm -wrap "$WRAP" -X:gc:eagerMmapSpaces=true HelloWorld
==10877== Nulgrind, the minimal Valgrind tool
==10877== Copyright (C) 2002-2013, and GNU GPL'd, by Nicholas Nethercote.
==10877== Using Valgrind-3.10.0.SVN and LibVEX; rerun with -h for copyright info
==10877== Command: /home/karl/r/jikesrvm/dist/development_x86_64-linux/JikesRVM -X:ic=/home/karl/r/jikesrvm/dist/development_x86_64-linux/RVM.code.image -X:id=/home/karl/r/jikesrvm/dist/development_x86_64-linux/RVM.data.image -X:ir=/home/karl/r/jikesrvm/dist/development_x86_64-linux/RVM.rmap.image -X:vmClasses=/home/karl/r/jikesrvm/dist/development_x86_64-linux/jksvm.jar:/home/karl/r/jikesrvm/dist/development_x86_64-linux/rvmrt.jar -Duser.timezone=PDT -Djava.home=/home/karl/r/jikesrvm/dist/development_x86_64-linux -Dgnu.classpath.home.url=file:/home/karl/r/jikesrvm/dist/development_x86_64-linux -Dgnu.classpath.vm.shortname=JikesRVM -Duser.home=/home/karl -Duser.dir=/home/karl/r -Duser.name=karl -Dos.name=Linux -Dos.version=3.8.0-42-generic -Dos.arch=x86_64 -X:gc:eagerMmapSpaces=true HelloWorld
==10877== 
Hello, World
==10877==

Also, when I turn back on undef-value-errors in memcheck, it reports an
invalid memory access / SIGSEGV:

[ ... numerous "uninitialised values" in the RVM code image ... ]
JikesRVM: TROUBLE.  Got a signal (Segmentation fault; #11) from outside the VM's address space in thread 0x4350cc0.
JikesRVM: UNRECOVERABLE trapped signal 11 (Segmentation fault)
handler stack 41e84ab
si->si_addr   0xccccccd1
cs            0x00000023
ds            0x0000002b
es            0x0000002b
fs            0x00000000
gs            0x0000000b
ss            0x0000002b
edi           0x04301a40
esi -- PR/VP  0x4203d277
ebp           0xcccccccd
esp -- SP     0x4203cd40
ebx           0x0434bff4
edx           0x00000000
ecx           0x00000000
eax           0x04301a40
eip           0x041e84ab
trapno        0x0000000e
err           0x00000004
eflags        0x00000044
fpregs        4355f04
oldmask       0x00000000
cr2           0xccccccd1
fp0 0x00000000000000000000
fp1 0x00000000000000000000
fp2 0x00000000000000000000
fp3 0x00000000000000000000
fp4 0x00000000000000000000
fp5 0x00000000000000000000
fp6 0x00000000000000000000
fp7 0x00000000000000000000
JikesRVM: internal error
==11293== 
==11293== Process terminating with default action of signal 11 (SIGSEGV)
==11293==  Access not within mapped region at address 0xCCCCCCD1

Thanks,
-Karl Cronburg-

NB: This is a follow up to posting to the Jikes RVM mailing list
(http://sourceforge.net/p/jikesrvm/mailman/message/32577482/)
which led to the problem described in this email.

Re: [Valgrind-users] valgrind gives error for HelloWorld program

[jody <jod...@gm...>]

Hi

I usually compile my source with "-g" to have the symbols,
  gcc -o main -g main.c
That way the valgrind output may become a bit clearer.

I call valgrind like this
  valgrind -v --leak-check=full --track-origins=yes --show-reachable=yes
./main
if iwant full information about errors and leaks,
or like this
  valgrind -v ./main
if am only interested in  the errors.

Hope this helps
  Jody


On Mon, Jul 7, 2014 at 4:33 PM, Ying Zhang <zh...@hp...> wrote:

> Hello,
>
> I'm testing valgrind with a very simple C program:
>
> #include <stdio.h>
>
> int main()
> {
>    printf ("Hello world\n");
>    return 0;
> }
>
> After compile and run it with valgrind
>
> gcc -o main main.c
> valgrind --tool=memcheck --track-origins=yes ./main
>
> I got the following errors. I don't quite understand why there are 54
> errors from 12 contexts (suppressed: 6 from 6) from a simple program. I'd
> appreciate if anyone could give me some insights.
>
> Thank you,
>
> Ying
>
> ----------------------
>
> ==49780== Memcheck, a memory error detector
> ==49780== Copyright (C) 2002-2013, and GNU GPL'd, by Julian Seward et al.
> ==49780== Using Valgrind-3.9.0 and LibVEX; rerun with -h for copyright info
> ==49780== Command: ./main
> ==49780==
> ==49780== Conditional jump or move depends on uninitialised value(s)
> ==49780==    at 0x4F58D05: ??? (in /lib64/libc-2.12.so)
> ==49780==    by 0x9F8E5D7: ???
> ==49780==    by 0x422200F: ???
> ==49780==    by 0xFFEFFF387: ???
> ==49780==    by 0xFFEFFF37F: ???
> ==49780==    by 0xFFEFFF477: ???
> ==49780==    by 0x1D: ???
> ==49780==    by 0x9D7CD90: ??? (in /lib64/libselinux.so.1)
> ==49780==    by 0xC1: ???
> ==49780==    by 0xFFEFFF33D: ???
> ==49780==    by 0xEF52: ???
> ==49780==    by 0xFFF: ???
> ==49780==  Uninitialised value was created
> ==49780==    at 0x4F0F91A: ??? (in /lib64/libc-2.12.so)
> ==49780==    by 0x4F0F9C4: ??? (in /lib64/libc-2.12.so)
> ==49780==    by 0x51BDE7F: ???
> ==49780==    by 0x51BDED7: ???
> ==49780==    by 0x51BDED7: ???
> ==49780==    by 0x4EAC918: ??? (in /lib64/libc-2.12.so)
> ==49780==    by 0x23F: ???
> ==49780==    by 0x4EA9029: ??? (in /lib64/libc-2.12.so)
> ==49780==    by 0x566704E3E3A7: ???
> ==49780==    by 0x237: ???
> ==49780==    by 0x20FFF: ???
> ==49780==    by 0x4E3F73F: ??? (in /lib64/libc-2.12.so)
> ==49780==
> ==49780== Conditional jump or move depends on uninitialised value(s)
> ==49780==    at 0x4F58D3C: ??? (in /lib64/libc-2.12.so)
> ==49780==    by 0x9F8E5D7: ???
> ==49780==    by 0x422200F: ???
> ==49780==    by 0xFFEFFF387: ???
> ==49780==    by 0xFFEFFF37F: ???
> ==49780==    by 0xFFEFFF477: ???
> ==49780==    by 0x1D: ???
> ==49780==    by 0x9D7CD90: ??? (in /lib64/libselinux.so.1)
> ==49780==    by 0xC1: ???
> ==49780==    by 0xFFEFFF33D: ???
> ==49780==    by 0xEF52: ???
> ==49780==    by 0xFFF: ???
> ==49780==  Uninitialised value was created
> ==49780==    at 0x4F0F91A: ??? (in /lib64/libc-2.12.so)
> ==49780==    by 0x4F0F9C4: ??? (in /lib64/libc-2.12.so)
> ==49780==    by 0x51BDE7F: ???
> ==49780==    by 0x51BDED7: ???
> ==49780==    by 0x51BDED7: ???
> ==49780==    by 0x4EAC918: ??? (in /lib64/libc-2.12.so)
> ==49780==    by 0x23F: ???
> ==49780==    by 0x4EA9029: ??? (in /lib64/libc-2.12.so)
> ==49780==    by 0x566704E3E3A7: ???
> ==49780==    by 0x237: ???
> ==49780==    by 0x20FFF: ???
> ==49780==    by 0x4E3F73F: ??? (in /lib64/libc-2.12.so)
> ==49780==
> ==49780== Conditional jump or move depends on uninitialised value(s)
> ==49780==    at 0x4F5976F: ??? (in /lib64/libc-2.12.so)
> ==49780==    by 0x9F8E5D7: ???
> ==49780==    by 0x422200F: ???
> ==49780==    by 0xFFEFFF387: ???
> ==49780==    by 0xFFEFFF37F: ???
> ==49780==    by 0xFFEFFF477: ???
> ==49780==    by 0x1D: ???
> ==49780==    by 0x9D7CD90: ??? (in /lib64/libselinux.so.1)
> ==49780==    by 0xC1: ???
> ==49780==    by 0xFFEFFF33D: ???
> ==49780==    by 0xEF52: ???
> ==49780==    by 0xFFF: ???
> ==49780==  Uninitialised value was created
> ==49780==    at 0x4F0F91A: ??? (in /lib64/libc-2.12.so)
> ==49780==    by 0x4F0F9C4: ??? (in /lib64/libc-2.12.so)
> ==49780==    by 0x51BDE7F: ???
> ==49780==    by 0x51BDED7: ???
> ==49780==    by 0x51BDED7: ???
> ==49780==    by 0x4EAC918: ??? (in /lib64/libc-2.12.so)
> ==49780==    by 0x23F: ???
> ==49780==    by 0x4EA9029: ??? (in /lib64/libc-2.12.so)
> ==49780==    by 0x566704E3E3A7: ???
> ==49780==    by 0x237: ???
> ==49780==    by 0x20FFF: ???
> ==49780==    by 0x4E3F73F: ??? (in /lib64/libc-2.12.so)
> ==49780==
> ==49780== Conditional jump or move depends on uninitialised value(s)
> ==49780==    at 0x4F597EC: ??? (in /lib64/libc-2.12.so)
> ==49780==    by 0x9F8E5D7: ???
> ==49780==    by 0x422200F: ???
> ==49780==    by 0xFFEFFF387: ???
> ==49780==    by 0xFFEFFF37F: ???
> ==49780==    by 0xFFEFFF477: ???
> ==49780==    by 0x1D: ???
> ==49780==    by 0x9D7CD90: ??? (in /lib64/libselinux.so.1)
> ==49780==    by 0xC1: ???
> ==49780==    by 0xFFEFFF33D: ???
> ==49780==    by 0xEF52: ???
> ==49780==    by 0xFFF: ???
> ==49780==  Uninitialised value was created
> ==49780==    at 0x4F0F91A: ??? (in /lib64/libc-2.12.so)
> ==49780==    by 0x4F0F9C4: ??? (in /lib64/libc-2.12.so)
> ==49780==    by 0x51BDE7F: ???
> ==49780==    by 0x51BDED7: ???
> ==49780==    by 0x51BDED7: ???
> ==49780==    by 0x4EAC918: ??? (in /lib64/libc-2.12.so)
> ==49780==    by 0x23F: ???
> ==49780==    by 0x4EA9029: ??? (in /lib64/libc-2.12.so)
> ==49780==    by 0x566704E3E3A7: ???
> ==49780==    by 0x237: ???
> ==49780==    by 0x20FFF: ???
> ==49780==    by 0x4E3F73F: ??? (in /lib64/libc-2.12.so)
> ==49780==
> ==49780== Conditional jump or move depends on uninitialised value(s)
> ==49780==    at 0x4F5939A: ??? (in /lib64/libc-2.12.so)
> ==49780==    by 0x9F8E5D7: ???
> ==49780==    by 0x422200F: ???
> ==49780==    by 0xFFEFFF387: ???
> ==49780==    by 0xFFEFFF37F: ???
> ==49780==    by 0xFFEFFF477: ???
> ==49780==    by 0x1D: ???
> ==49780==    by 0x9D7CD90: ??? (in /lib64/libselinux.so.1)
> ==49780==    by 0xC1: ???
> ==49780==    by 0xFFEFFF33D: ???
> ==49780==    by 0xEF52: ???
> ==49780==    by 0xFFF: ???
> ==49780==  Uninitialised value was created
> ==49780==    at 0x4F0F91A: ??? (in /lib64/libc-2.12.so)
> ==49780==    by 0x4F0F9C4: ??? (in /lib64/libc-2.12.so)
> ==49780==    by 0x51BDE7F: ???
> ==49780==    by 0x51BDED7: ???
> ==49780==    by 0x51BDED7: ???
> ==49780==    by 0x4EAC918: ??? (in /lib64/libc-2.12.so)
> ==49780==    by 0x23F: ???
> ==49780==    by 0x4EA9029: ??? (in /lib64/libc-2.12.so)
> ==49780==    by 0x566704E3E3A7: ???
> ==49780==    by 0x237: ???
> ==49780==    by 0x20FFF: ???
> ==49780==    by 0x4E3F73F: ??? (in /lib64/libc-2.12.so)
> ==49780==
> ==49780== Conditional jump or move depends on uninitialised value(s)
> ==49780==    at 0x4F597E4: ??? (in /lib64/libc-2.12.so)
> ==49780==    by 0x9F8E5D7: ???
> ==49780==    by 0x422200F: ???
> ==49780==    by 0xFFEFFF387: ???
> ==49780==    by 0xFFEFFF37F: ???
> ==49780==    by 0xFFEFFF477: ???
> ==49780==    by 0x1D: ???
> ==49780==    by 0x9D7CD90: ??? (in /lib64/libselinux.so.1)
> ==49780==    by 0xC1: ???
> ==49780==    by 0xFFEFFF33D: ???
> ==49780==    by 0xEF52: ???
> ==49780==    by 0xFFF: ???
> ==49780==  Uninitialised value was created
> ==49780==    at 0x4F0F91A: ??? (in /lib64/libc-2.12.so)
> ==49780==    by 0x4F0F9C4: ??? (in /lib64/libc-2.12.so)
> ==49780==    by 0x51BDE7F: ???
> ==49780==    by 0x51BDED7: ???
> ==49780==    by 0x51BDED7: ???
> ==49780==    by 0x4EAC918: ??? (in /lib64/libc-2.12.so)
> ==49780==    by 0x23F: ???
> ==49780==    by 0x4EA9029: ??? (in /lib64/libc-2.12.so)
> ==49780==    by 0x566704E3E3A7: ???
> ==49780==    by 0x237: ???
> ==49780==    by 0x20FFF: ???
> ==49780==    by 0x4E3F73F: ??? (in /lib64/libc-2.12.so)
> ==49780==
> ==49780== Conditional jump or move depends on uninitialised value(s)
> ==49780==    at 0x4F597E8: ??? (in /lib64/libc-2.12.so)
> ==49780==    by 0x9F8E5D7: ???
> ==49780==    by 0x422200F: ???
> ==49780==    by 0xFFEFFF387: ???
> ==49780==    by 0xFFEFFF37F: ???
> ==49780==    by 0xFFEFFF477: ???
> ==49780==    by 0x1D: ???
> ==49780==    by 0x9D7CD90: ??? (in /lib64/libselinux.so.1)
> ==49780==    by 0xC1: ???
> ==49780==    by 0xFFEFFF33D: ???
> ==49780==    by 0xEF52: ???
> ==49780==    by 0xFFF: ???
> ==49780==  Uninitialised value was created
> ==49780==    at 0x4F0F91A: ??? (in /lib64/libc-2.12.so)
> ==49780==    by 0x4F0F9C4: ??? (in /lib64/libc-2.12.so)
> ==49780==    by 0x51BDE7F: ???
> ==49780==    by 0x51BDED7: ???
> ==49780==    by 0x51BDED7: ???
> ==49780==    by 0x4EAC918: ??? (in /lib64/libc-2.12.so)
> ==49780==    by 0x23F: ???
> ==49780==    by 0x4EA9029: ??? (in /lib64/libc-2.12.so)
> ==49780==    by 0x566704E3E3A7: ???
> ==49780==    by 0x237: ???
> ==49780==    by 0x20FFF: ???
> ==49780==    by 0x4E3F73F: ??? (in /lib64/libc-2.12.so)
> ==49780==
> ==49780== Conditional jump or move depends on uninitialised value(s)
> ==49780==    at 0x4EB037B: ??? (in /lib64/libc-2.12.so)
> ==49780==    by 0x636F: ???
> ==49780==  Uninitialised value was created by a stack allocation
> ==49780==    at 0x88DB3FB: ??? (in /usr/lib64/libinfinipath.so.4.0)
> ==49780==
> ==49780== Conditional jump or move depends on uninitialised value(s)
> ==49780==    at 0x4EB9C7E: ??? (in /lib64/libc-2.12.so)
> ==49780==    by 0xA30203A0971: ???
> ==49780==    by 0x8AE4FFF: ??? (in /usr/lib64/libinfinipath.so.4.0)
> ==49780==    by 0x8DECBCF: ???
> ==49780==    by 0x8DD483F: ??? (in
> /opt/gnu/gcc/4.7.2/lib64/libstdc++.so.6.0.17)
> ==49780==    by 0x8DD1C8F: ??? (in
> /opt/gnu/gcc/4.7.2/lib64/libstdc++.so.6.0.17)
> ==49780==  Uninitialised value was created by a stack allocation
> ==49780==    at 0x679F8FB: ??? (in /opt/mellanox/mxm/lib/libmxm.so.0.0.0)
> ==49780==
> ==49780== Conditional jump or move depends on uninitialised value(s)
> ==49780==    at 0x4EB9C93: ??? (in /lib64/libc-2.12.so)
> ==49780==    by 0x68747541203A0963: ???
> ==49780==    by 0x444D416369746E64: ???
> ==49780==    by 0x8DE0009: ???
> ==49780==    by 0x8DD483F: ??? (in
> /opt/gnu/gcc/4.7.2/lib64/libstdc++.so.6.0.17)
> ==49780==    by 0x8DD1C8F: ??? (in
> /opt/gnu/gcc/4.7.2/lib64/libstdc++.so.6.0.17)
> ==49780==  Uninitialised value was created by a stack allocation
> ==49780==    at 0x679F8FB: ??? (in /opt/mellanox/mxm/lib/libmxm.so.0.0.0)
> ==49780==
> ==49780== Conditional jump or move depends on uninitialised value(s)
> ==49780==    at 0x4EB9C93: ??? (in /lib64/libc-2.12.so)
> ==49780==    by 0xA3132203A09796B: ???
> ==49780==    by 0x444D416369746DFF: ???
> ==49780==    by 0x8DE0009: ???
> ==49780==    by 0x8DD483F: ??? (in
> /opt/gnu/gcc/4.7.2/lib64/libstdc++.so.6.0.17)
> ==49780==    by 0x8DD1C8F: ??? (in
> /opt/gnu/gcc/4.7.2/lib64/libstdc++.so.6.0.17)
> ==49780==  Uninitialised value was created by a stack allocation
> ==49780==    at 0x679F8FB: ??? (in /opt/mellanox/mxm/lib/libmxm.so.0.0.0)
> ==49780==
> ==49780== Conditional jump or move depends on uninitialised value(s)
> ==49780==    at 0x4EB9C93: ??? (in /lib64/libc-2.12.so)
> ==49780==    by 0x444D41203A09656C: ???
> ==49780==    by 0x6E6F726574704F1F: ???
> ==49780==    by 0x6F725020296D7427: ???
> ==49780==    by 0x3620726F73736562: ???
> ==49780==    by 0x2020202020383732: ???
> ==49780==    by 0x202020202020201F: ???
> ==49780==    by 0xA2020201F: ???
> ==49780==    by 0x8DD3C3F: ??? (in
> /opt/gnu/gcc/4.7.2/lib64/libstdc++.so.6.0.17)
> ==49780==    by 0x8B4272C: ??? (in
> /opt/gnu/gcc/4.7.2/lib64/libstdc++.so.6.0.17)
> ==49780==    by 0x8DECBCF: ???
> ==49780==    by 0xFFEFFF2BF: ???
> ==49780==  Uninitialised value was created by a stack allocation
> ==49780==    at 0x679F8FB: ??? (in /opt/mellanox/mxm/lib/libmxm.so.0.0.0)
> ==49780==
> ==49780== Warning: ignored attempt to set SIGKILL handler in sigaction();
> ==49780==          the SIGKILL signal is uncatchable
> Hello world
> ==49780==
> ==49780== HEAP SUMMARY:
> ==49780==     in use at exit: 0 bytes in 0 blocks
> ==49780==   total heap usage: 0 allocs, 0 frees, 0 bytes allocated
> ==49780==
> ==49780== All heap blocks were freed -- no leaks are possible
> ==49780==
> ==49780== For counts of detected and suppressed errors, rerun with: -v
> ==49780== ERROR SUMMARY: 54 errors from 12 contexts (suppressed: 6 from 6)
>
> ------------------------------------------------------------------------------
> Open source business process management suite built on Java and Eclipse
> Turn processes into business applications with Bonita BPM Community Edition
> Quickly connect people, data, and systems into organized workflows
> Winner of BOSSIE, CODIE, OW2 and Gartner awards
> http://p.sf.net/sfu/Bonitasoft
> _______________________________________________
> Valgrind-users mailing list
> Val...@li...
> https://lists.sourceforge.net/lists/listinfo/valgrind-users
>

[Valgrind-users] valgrind gives error for HelloWorld program

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

Hello, 

I'm testing valgrind with a very simple C program:

#include <stdio.h>

int main()
{
   printf ("Hello world\n");
   return 0;
}

After compile and run it with valgrind

gcc -o main main.c
valgrind --tool=memcheck --track-origins=yes ./main

I got the following errors. I don't quite understand why there are 54 errors from 12 contexts (suppressed: 6 from 6) from a simple program. I'd appreciate if anyone could give me some insights. 

Thank you,

Ying

----------------------

==49780== Memcheck, a memory error detector
==49780== Copyright (C) 2002-2013, and GNU GPL'd, by Julian Seward et al.
==49780== Using Valgrind-3.9.0 and LibVEX; rerun with -h for copyright info
==49780== Command: ./main
==49780== 
==49780== Conditional jump or move depends on uninitialised value(s)
==49780==    at 0x4F58D05: ??? (in /lib64/libc-2.12.so)
==49780==    by 0x9F8E5D7: ???
==49780==    by 0x422200F: ???
==49780==    by 0xFFEFFF387: ???
==49780==    by 0xFFEFFF37F: ???
==49780==    by 0xFFEFFF477: ???
==49780==    by 0x1D: ???
==49780==    by 0x9D7CD90: ??? (in /lib64/libselinux.so.1)
==49780==    by 0xC1: ???
==49780==    by 0xFFEFFF33D: ???
==49780==    by 0xEF52: ???
==49780==    by 0xFFF: ???
==49780==  Uninitialised value was created
==49780==    at 0x4F0F91A: ??? (in /lib64/libc-2.12.so)
==49780==    by 0x4F0F9C4: ??? (in /lib64/libc-2.12.so)
==49780==    by 0x51BDE7F: ???
==49780==    by 0x51BDED7: ???
==49780==    by 0x51BDED7: ???
==49780==    by 0x4EAC918: ??? (in /lib64/libc-2.12.so)
==49780==    by 0x23F: ???
==49780==    by 0x4EA9029: ??? (in /lib64/libc-2.12.so)
==49780==    by 0x566704E3E3A7: ???
==49780==    by 0x237: ???
==49780==    by 0x20FFF: ???
==49780==    by 0x4E3F73F: ??? (in /lib64/libc-2.12.so)
==49780== 
==49780== Conditional jump or move depends on uninitialised value(s)
==49780==    at 0x4F58D3C: ??? (in /lib64/libc-2.12.so)
==49780==    by 0x9F8E5D7: ???
==49780==    by 0x422200F: ???
==49780==    by 0xFFEFFF387: ???
==49780==    by 0xFFEFFF37F: ???
==49780==    by 0xFFEFFF477: ???
==49780==    by 0x1D: ???
==49780==    by 0x9D7CD90: ??? (in /lib64/libselinux.so.1)
==49780==    by 0xC1: ???
==49780==    by 0xFFEFFF33D: ???
==49780==    by 0xEF52: ???
==49780==    by 0xFFF: ???
==49780==  Uninitialised value was created
==49780==    at 0x4F0F91A: ??? (in /lib64/libc-2.12.so)
==49780==    by 0x4F0F9C4: ??? (in /lib64/libc-2.12.so)
==49780==    by 0x51BDE7F: ???
==49780==    by 0x51BDED7: ???
==49780==    by 0x51BDED7: ???
==49780==    by 0x4EAC918: ??? (in /lib64/libc-2.12.so)
==49780==    by 0x23F: ???
==49780==    by 0x4EA9029: ??? (in /lib64/libc-2.12.so)
==49780==    by 0x566704E3E3A7: ???
==49780==    by 0x237: ???
==49780==    by 0x20FFF: ???
==49780==    by 0x4E3F73F: ??? (in /lib64/libc-2.12.so)
==49780== 
==49780== Conditional jump or move depends on uninitialised value(s)
==49780==    at 0x4F5976F: ??? (in /lib64/libc-2.12.so)
==49780==    by 0x9F8E5D7: ???
==49780==    by 0x422200F: ???
==49780==    by 0xFFEFFF387: ???
==49780==    by 0xFFEFFF37F: ???
==49780==    by 0xFFEFFF477: ???
==49780==    by 0x1D: ???
==49780==    by 0x9D7CD90: ??? (in /lib64/libselinux.so.1)
==49780==    by 0xC1: ???
==49780==    by 0xFFEFFF33D: ???
==49780==    by 0xEF52: ???
==49780==    by 0xFFF: ???
==49780==  Uninitialised value was created
==49780==    at 0x4F0F91A: ??? (in /lib64/libc-2.12.so)
==49780==    by 0x4F0F9C4: ??? (in /lib64/libc-2.12.so)
==49780==    by 0x51BDE7F: ???
==49780==    by 0x51BDED7: ???
==49780==    by 0x51BDED7: ???
==49780==    by 0x4EAC918: ??? (in /lib64/libc-2.12.so)
==49780==    by 0x23F: ???
==49780==    by 0x4EA9029: ??? (in /lib64/libc-2.12.so)
==49780==    by 0x566704E3E3A7: ???
==49780==    by 0x237: ???
==49780==    by 0x20FFF: ???
==49780==    by 0x4E3F73F: ??? (in /lib64/libc-2.12.so)
==49780== 
==49780== Conditional jump or move depends on uninitialised value(s)
==49780==    at 0x4F597EC: ??? (in /lib64/libc-2.12.so)
==49780==    by 0x9F8E5D7: ???
==49780==    by 0x422200F: ???
==49780==    by 0xFFEFFF387: ???
==49780==    by 0xFFEFFF37F: ???
==49780==    by 0xFFEFFF477: ???
==49780==    by 0x1D: ???
==49780==    by 0x9D7CD90: ??? (in /lib64/libselinux.so.1)
==49780==    by 0xC1: ???
==49780==    by 0xFFEFFF33D: ???
==49780==    by 0xEF52: ???
==49780==    by 0xFFF: ???
==49780==  Uninitialised value was created
==49780==    at 0x4F0F91A: ??? (in /lib64/libc-2.12.so)
==49780==    by 0x4F0F9C4: ??? (in /lib64/libc-2.12.so)
==49780==    by 0x51BDE7F: ???
==49780==    by 0x51BDED7: ???
==49780==    by 0x51BDED7: ???
==49780==    by 0x4EAC918: ??? (in /lib64/libc-2.12.so)
==49780==    by 0x23F: ???
==49780==    by 0x4EA9029: ??? (in /lib64/libc-2.12.so)
==49780==    by 0x566704E3E3A7: ???
==49780==    by 0x237: ???
==49780==    by 0x20FFF: ???
==49780==    by 0x4E3F73F: ??? (in /lib64/libc-2.12.so)
==49780== 
==49780== Conditional jump or move depends on uninitialised value(s)
==49780==    at 0x4F5939A: ??? (in /lib64/libc-2.12.so)
==49780==    by 0x9F8E5D7: ???
==49780==    by 0x422200F: ???
==49780==    by 0xFFEFFF387: ???
==49780==    by 0xFFEFFF37F: ???
==49780==    by 0xFFEFFF477: ???
==49780==    by 0x1D: ???
==49780==    by 0x9D7CD90: ??? (in /lib64/libselinux.so.1)
==49780==    by 0xC1: ???
==49780==    by 0xFFEFFF33D: ???
==49780==    by 0xEF52: ???
==49780==    by 0xFFF: ???
==49780==  Uninitialised value was created
==49780==    at 0x4F0F91A: ??? (in /lib64/libc-2.12.so)
==49780==    by 0x4F0F9C4: ??? (in /lib64/libc-2.12.so)
==49780==    by 0x51BDE7F: ???
==49780==    by 0x51BDED7: ???
==49780==    by 0x51BDED7: ???
==49780==    by 0x4EAC918: ??? (in /lib64/libc-2.12.so)
==49780==    by 0x23F: ???
==49780==    by 0x4EA9029: ??? (in /lib64/libc-2.12.so)
==49780==    by 0x566704E3E3A7: ???
==49780==    by 0x237: ???
==49780==    by 0x20FFF: ???
==49780==    by 0x4E3F73F: ??? (in /lib64/libc-2.12.so)
==49780== 
==49780== Conditional jump or move depends on uninitialised value(s)
==49780==    at 0x4F597E4: ??? (in /lib64/libc-2.12.so)
==49780==    by 0x9F8E5D7: ???
==49780==    by 0x422200F: ???
==49780==    by 0xFFEFFF387: ???
==49780==    by 0xFFEFFF37F: ???
==49780==    by 0xFFEFFF477: ???
==49780==    by 0x1D: ???
==49780==    by 0x9D7CD90: ??? (in /lib64/libselinux.so.1)
==49780==    by 0xC1: ???
==49780==    by 0xFFEFFF33D: ???
==49780==    by 0xEF52: ???
==49780==    by 0xFFF: ???
==49780==  Uninitialised value was created
==49780==    at 0x4F0F91A: ??? (in /lib64/libc-2.12.so)
==49780==    by 0x4F0F9C4: ??? (in /lib64/libc-2.12.so)
==49780==    by 0x51BDE7F: ???
==49780==    by 0x51BDED7: ???
==49780==    by 0x51BDED7: ???
==49780==    by 0x4EAC918: ??? (in /lib64/libc-2.12.so)
==49780==    by 0x23F: ???
==49780==    by 0x4EA9029: ??? (in /lib64/libc-2.12.so)
==49780==    by 0x566704E3E3A7: ???
==49780==    by 0x237: ???
==49780==    by 0x20FFF: ???
==49780==    by 0x4E3F73F: ??? (in /lib64/libc-2.12.so)
==49780== 
==49780== Conditional jump or move depends on uninitialised value(s)
==49780==    at 0x4F597E8: ??? (in /lib64/libc-2.12.so)
==49780==    by 0x9F8E5D7: ???
==49780==    by 0x422200F: ???
==49780==    by 0xFFEFFF387: ???
==49780==    by 0xFFEFFF37F: ???
==49780==    by 0xFFEFFF477: ???
==49780==    by 0x1D: ???
==49780==    by 0x9D7CD90: ??? (in /lib64/libselinux.so.1)
==49780==    by 0xC1: ???
==49780==    by 0xFFEFFF33D: ???
==49780==    by 0xEF52: ???
==49780==    by 0xFFF: ???
==49780==  Uninitialised value was created
==49780==    at 0x4F0F91A: ??? (in /lib64/libc-2.12.so)
==49780==    by 0x4F0F9C4: ??? (in /lib64/libc-2.12.so)
==49780==    by 0x51BDE7F: ???
==49780==    by 0x51BDED7: ???
==49780==    by 0x51BDED7: ???
==49780==    by 0x4EAC918: ??? (in /lib64/libc-2.12.so)
==49780==    by 0x23F: ???
==49780==    by 0x4EA9029: ??? (in /lib64/libc-2.12.so)
==49780==    by 0x566704E3E3A7: ???
==49780==    by 0x237: ???
==49780==    by 0x20FFF: ???
==49780==    by 0x4E3F73F: ??? (in /lib64/libc-2.12.so)
==49780== 
==49780== Conditional jump or move depends on uninitialised value(s)
==49780==    at 0x4EB037B: ??? (in /lib64/libc-2.12.so)
==49780==    by 0x636F: ???
==49780==  Uninitialised value was created by a stack allocation
==49780==    at 0x88DB3FB: ??? (in /usr/lib64/libinfinipath.so.4.0)
==49780== 
==49780== Conditional jump or move depends on uninitialised value(s)
==49780==    at 0x4EB9C7E: ??? (in /lib64/libc-2.12.so)
==49780==    by 0xA30203A0971: ???
==49780==    by 0x8AE4FFF: ??? (in /usr/lib64/libinfinipath.so.4.0)
==49780==    by 0x8DECBCF: ???
==49780==    by 0x8DD483F: ??? (in /opt/gnu/gcc/4.7.2/lib64/libstdc++.so.6.0.17)
==49780==    by 0x8DD1C8F: ??? (in /opt/gnu/gcc/4.7.2/lib64/libstdc++.so.6.0.17)
==49780==  Uninitialised value was created by a stack allocation
==49780==    at 0x679F8FB: ??? (in /opt/mellanox/mxm/lib/libmxm.so.0.0.0)
==49780== 
==49780== Conditional jump or move depends on uninitialised value(s)
==49780==    at 0x4EB9C93: ??? (in /lib64/libc-2.12.so)
==49780==    by 0x68747541203A0963: ???
==49780==    by 0x444D416369746E64: ???
==49780==    by 0x8DE0009: ???
==49780==    by 0x8DD483F: ??? (in /opt/gnu/gcc/4.7.2/lib64/libstdc++.so.6.0.17)
==49780==    by 0x8DD1C8F: ??? (in /opt/gnu/gcc/4.7.2/lib64/libstdc++.so.6.0.17)
==49780==  Uninitialised value was created by a stack allocation
==49780==    at 0x679F8FB: ??? (in /opt/mellanox/mxm/lib/libmxm.so.0.0.0)
==49780== 
==49780== Conditional jump or move depends on uninitialised value(s)
==49780==    at 0x4EB9C93: ??? (in /lib64/libc-2.12.so)
==49780==    by 0xA3132203A09796B: ???
==49780==    by 0x444D416369746DFF: ???
==49780==    by 0x8DE0009: ???
==49780==    by 0x8DD483F: ??? (in /opt/gnu/gcc/4.7.2/lib64/libstdc++.so.6.0.17)
==49780==    by 0x8DD1C8F: ??? (in /opt/gnu/gcc/4.7.2/lib64/libstdc++.so.6.0.17)
==49780==  Uninitialised value was created by a stack allocation
==49780==    at 0x679F8FB: ??? (in /opt/mellanox/mxm/lib/libmxm.so.0.0.0)
==49780== 
==49780== Conditional jump or move depends on uninitialised value(s)
==49780==    at 0x4EB9C93: ??? (in /lib64/libc-2.12.so)
==49780==    by 0x444D41203A09656C: ???
==49780==    by 0x6E6F726574704F1F: ???
==49780==    by 0x6F725020296D7427: ???
==49780==    by 0x3620726F73736562: ???
==49780==    by 0x2020202020383732: ???
==49780==    by 0x202020202020201F: ???
==49780==    by 0xA2020201F: ???
==49780==    by 0x8DD3C3F: ??? (in /opt/gnu/gcc/4.7.2/lib64/libstdc++.so.6.0.17)
==49780==    by 0x8B4272C: ??? (in /opt/gnu/gcc/4.7.2/lib64/libstdc++.so.6.0.17)
==49780==    by 0x8DECBCF: ???
==49780==    by 0xFFEFFF2BF: ???
==49780==  Uninitialised value was created by a stack allocation
==49780==    at 0x679F8FB: ??? (in /opt/mellanox/mxm/lib/libmxm.so.0.0.0)
==49780== 
==49780== Warning: ignored attempt to set SIGKILL handler in sigaction();
==49780==          the SIGKILL signal is uncatchable
Hello world
==49780== 
==49780== HEAP SUMMARY:
==49780==     in use at exit: 0 bytes in 0 blocks
==49780==   total heap usage: 0 allocs, 0 frees, 0 bytes allocated
==49780== 
==49780== All heap blocks were freed -- no leaks are possible
==49780== 
==49780== For counts of detected and suppressed errors, rerun with: -v
==49780== ERROR SUMMARY: 54 errors from 12 contexts (suppressed: 6 from 6)

Re: [Valgrind-users] my cache factoring saga continues

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

Am 07.07.2014 01:28, schrieb Jerry Scharf:
> Hi again,
> 
> This is just such an awful thing to be doing but such are the cards I get handed.
> 
> The program I am trying to measure the cache performance on is actually a win32 progran that I am running under wine on redhat linux. I thought for a while the problem might have been that I had a stripped version of the program and that was causing a problem. After much aggravation, wine is now built locally with -g -O so I can debug if really necessary.
> 
> When I run it under cachegrind, it doesn't seem to generate the statistics.

I definitely do not want to just run the "wine" binary within the
simulator, as this is most
probable just a startup wrapper. Try with "--trace-children=yes".
This should give you an output file for every process started during the
program run.

Josef


> 
> here is the wine program:
> $ file `which wine`
> /usr/local/bin/wine: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.18, not stripped
> 
> here is the run:
> $ valgrind --tool=cachegrind --LL=16777216,16,64 wine ../../../../Program\ Files/LTC/LTspiceIV/scad3.exe -wine -b xxx.cir 
> ==13347== Cachegrind, a cache and branch-prediction profiler
> ==13347== Copyright (C) 2002-2012, and GNU GPL'd, by Nicholas Nethercote et al.
> ==13347== Using Valgrind-3.8.1 and LibVEX; rerun with -h for copyright info
> ==13347== Command: wine ../../../../Program\ Files/LTC/LTspiceIV/scad3.exe -wine -b xxx.cir
> ==13347== 
> --13347-- warning: Unknown Intel cache config value (0x63), ignoring
> --13347-- warning: L3 cache found, using its data for the LL simulation.
> ==13347== Auto-detected LL cache configuration not supported: Cache set count is not a power of two.
> ==13347==   LL: 26,214,400 B, 20-way, 64 B lines
> 
> that's the end of the output. On other programs, there is the stats and miss percentage.
>  valgrind --tool=cachegrind --LL=16777216,16,64 pwd
> ==13662== Cachegrind, a cache and branch-prediction profiler
> ==13662== Copyright (C) 2002-2012, and GNU GPL'd, by Nicholas Nethercote et al.
> ==13662== Using Valgrind-3.8.1 and LibVEX; rerun with -h for copyright info
> ==13662== Command: pwd
> ==13662== 
> --13662-- warning: Unknown Intel cache config value (0x63), ignoring
> --13662-- warning: L3 cache found, using its data for the LL simulation.
> ==13662== Auto-detected LL cache configuration not supported: Cache set count is not a power of two.
> ==13662==   LL: 26,214,400 B, 20-way, 64 B lines
> /yyy/.wine/drive_c/users/root/phitest/release
> ==13662== 
> ==13662== I   refs:      196,379
> ==13662== I1  misses:      1,003
> ==13662== LLi misses:        990
> ==13662== I1  miss rate:    0.51%
> ==13662== LLi miss rate:    0.50%
> ==13662== 
> ==13662== D   refs:       66,222  (50,912 rd   + 15,310 wr)
> ==13662== D1  misses:      2,464  ( 2,099 rd   +    365 wr)
> ==13662== LLd misses:      1,936  ( 1,603 rd   +    333 wr)
> ==13662== D1  miss rate:     3.7% (   4.1%     +    2.3%  )
> ==13662== LLd miss rate:     2.9% (   3.1%     +    2.1%  )
> ==13662== 
> ==13662== LL refs:         3,467  ( 3,102 rd   +    365 wr)
> ==13662== LL misses:       2,926  ( 2,593 rd   +    333 wr)
> ==13662== LL miss rate:      1.1% (   1.0%     +    2.1%  )
> 
> This works with both 32 and 64 bit executables I have tested, but not wine. The program has successfully run and generated the right output.
> 
> 
> what can I do?
> 
> thanks,
> jerry
> 
> ------------------------------------------------------------------------------
> Open source business process management suite built on Java and Eclipse
> Turn processes into business applications with Bonita BPM Community Edition
> Quickly connect people, data, and systems into organized workflows
> Winner of BOSSIE, CODIE, OW2 and Gartner awards
> http://p.sf.net/sfu/Bonitasoft
> _______________________________________________
> Valgrind-users mailing list
> Val...@li...
> https://lists.sourceforge.net/lists/listinfo/valgrind-users
> 

[Valgrind-users] my cache factoring saga continues

[Jerry S. <js...@fi...>]

Hi again,

This is just such an awful thing to be doing but such are the cards I get handed.

The program I am trying to measure the cache performance on is actually a win32 progran that I am running under wine on redhat linux. I thought for a while the problem might have been that I had a stripped version of the program and that was causing a problem. After much aggravation, wine is now built locally with -g -O so I can debug if really necessary.

When I run it under cachegrind, it doesn't seem to generate the statistics.

here is the wine program:
$ file `which wine`
/usr/local/bin/wine: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.18, not stripped

here is the run:
$ valgrind --tool=cachegrind --LL=16777216,16,64 wine ../../../../Program\ Files/LTC/LTspiceIV/scad3.exe -wine -b xxx.cir 
==13347== Cachegrind, a cache and branch-prediction profiler
==13347== Copyright (C) 2002-2012, and GNU GPL'd, by Nicholas Nethercote et al.
==13347== Using Valgrind-3.8.1 and LibVEX; rerun with -h for copyright info
==13347== Command: wine ../../../../Program\ Files/LTC/LTspiceIV/scad3.exe -wine -b xxx.cir
==13347== 
--13347-- warning: Unknown Intel cache config value (0x63), ignoring
--13347-- warning: L3 cache found, using its data for the LL simulation.
==13347== Auto-detected LL cache configuration not supported: Cache set count is not a power of two.
==13347==   LL: 26,214,400 B, 20-way, 64 B lines

that's the end of the output. On other programs, there is the stats and miss percentage.
 valgrind --tool=cachegrind --LL=16777216,16,64 pwd
==13662== Cachegrind, a cache and branch-prediction profiler
==13662== Copyright (C) 2002-2012, and GNU GPL'd, by Nicholas Nethercote et al.
==13662== Using Valgrind-3.8.1 and LibVEX; rerun with -h for copyright info
==13662== Command: pwd
==13662== 
--13662-- warning: Unknown Intel cache config value (0x63), ignoring
--13662-- warning: L3 cache found, using its data for the LL simulation.
==13662== Auto-detected LL cache configuration not supported: Cache set count is not a power of two.
==13662==   LL: 26,214,400 B, 20-way, 64 B lines
/yyy/.wine/drive_c/users/root/phitest/release
==13662== 
==13662== I   refs:      196,379
==13662== I1  misses:      1,003
==13662== LLi misses:        990
==13662== I1  miss rate:    0.51%
==13662== LLi miss rate:    0.50%
==13662== 
==13662== D   refs:       66,222  (50,912 rd   + 15,310 wr)
==13662== D1  misses:      2,464  ( 2,099 rd   +    365 wr)
==13662== LLd misses:      1,936  ( 1,603 rd   +    333 wr)
==13662== D1  miss rate:     3.7% (   4.1%     +    2.3%  )
==13662== LLd miss rate:     2.9% (   3.1%     +    2.1%  )
==13662== 
==13662== LL refs:         3,467  ( 3,102 rd   +    365 wr)
==13662== LL misses:       2,926  ( 2,593 rd   +    333 wr)
==13662== LL miss rate:      1.1% (   1.0%     +    2.1%  )

This works with both 32 and 64 bit executables I have tested, but not wine. The program has successfully run and generated the right output.


what can I do?

thanks,
jerry

Re: [Valgrind-users] cachegrind for Xeon e5-2643v2

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

Am 04.07.2014 10:00, schrieb Josef Weidendorfer:
> However, if you have multithreaded code: cachegrind currently does not
> simulate shared L3 for multithreaded
> code, but expects the full hierarchy to be private for each thread.

Sorry, that's wrong.
Cachegrind only maintains one hierarchy, and all threads go through the
same single hierarchy.

We probably should change something here.

Josef

> 
>> It's a bit daunting when someone says I want millions of simulations running as fast as possible. That is a good hard challenge. I've done work on long lasting compute bound jobs, but this has a bunch more moving parts than just the sparse matrix solver and forward error tests.
> 
> At least it sounds embarrasing parallel. Not too bad.
> 
> Josef
> 
>>
>> jerry
>>
>> ----- Original Message -----
>> | From: "Tom Hughes" <to...@co...>
>> | To: "Jerry Scharf" <js...@fi...>, Val...@li...
>> | Sent: Thursday, July 3, 2014 12:32:59 AM
>> | Subject: Re: cachegrind for Xeon e5-2643v2
>> | 
>> | On 03/07/14 07:06, Jerry Scharf wrote:
>> | 
>> | > Why is it insisting that the numbers be powers of 2? If I use --LL
>> | > with the real numbers it refuses to start. If I round these down
>> | > to the next lower power of 2 (16M and 16 associations) it doesn't
>> | > complain but it still doesn't run.
>> | 
>> | The internal design of the data structures used by cachegrind assumes
>> | that sizes will be powers of two and that it can compute indexes by
>> | bit
>> | masking.
>> | 
>> | That is, as you have found, no longer true for modern processors, but
>> | to
>> | date nobody has stepped up to fix cachegrind. On top of that it isn't
>> | clear that there is a good fix that wouldn't produce a loss of
>> | performance.
>> | 
>> | Tom
>> | 
>> | --
>> | Tom Hughes (to...@co...)
>> | http://compton.nu/
>> | 
>>
>> ------------------------------------------------------------------------------
>> Open source business process management suite built on Java and Eclipse
>> Turn processes into business applications with Bonita BPM Community Edition
>> Quickly connect people, data, and systems into organized workflows
>> Winner of BOSSIE, CODIE, OW2 and Gartner awards
>> http://p.sf.net/sfu/Bonitasoft
>> _______________________________________________
>> Valgrind-users mailing list
>> Val...@li...
>> https://lists.sourceforge.net/lists/listinfo/valgrind-users
>>
> 
> ------------------------------------------------------------------------------
> Open source business process management suite built on Java and Eclipse
> Turn processes into business applications with Bonita BPM Community Edition
> Quickly connect people, data, and systems into organized workflows
> Winner of BOSSIE, CODIE, OW2 and Gartner awards
> http://p.sf.net/sfu/Bonitasoft
> _______________________________________________
> Valgrind-users mailing list
> Val...@li...
> https://lists.sourceforge.net/lists/listinfo/valgrind-users
> 

Re: [Valgrind-users] cachegrind for Xeon e5-2643v2

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

Am 03.07.2014 19:22, schrieb Jerry Scharf:
> Tom and Josef,
> 
> Thank you for your speedy responses.
> 
> Is cachegrind an instrumentation of the real system or a simulation of the processor cache based on the code executed? From your responses, it sounds like the later.

Yes.

For the first, use perf/PAPI/oprofile/VTUNE/... which use performance
counters of your processor.


> If so, this is actually better for what I want to do.
> 
> Because of the fact that the cache is shared among the cores, it is hard to tell from single runs what it will be like with concurrent jobs. If it is simulated and I can just set the cache size to whatever I want, I can run a job with different cache parameters and find at least a first order guess of how the job responds to cache size. This is the most useful thing for me right now.

That's true. If you want to run 6 seperate processes on your 6-core, and
you have 25MB L3, you should check
how one process works with 25MB /6 L3, ie. around 4MB. As processes do
not share address space.

However, if you have multithreaded code: cachegrind currently does not
simulate shared L3 for multithreaded
code, but expects the full hierarchy to be private for each thread.

> It's a bit daunting when someone says I want millions of simulations running as fast as possible. That is a good hard challenge. I've done work on long lasting compute bound jobs, but this has a bunch more moving parts than just the sparse matrix solver and forward error tests.

At least it sounds embarrasing parallel. Not too bad.

Josef

> 
> jerry
> 
> ----- Original Message -----
> | From: "Tom Hughes" <to...@co...>
> | To: "Jerry Scharf" <js...@fi...>, Val...@li...
> | Sent: Thursday, July 3, 2014 12:32:59 AM
> | Subject: Re: cachegrind for Xeon e5-2643v2
> | 
> | On 03/07/14 07:06, Jerry Scharf wrote:
> | 
> | > Why is it insisting that the numbers be powers of 2? If I use --LL
> | > with the real numbers it refuses to start. If I round these down
> | > to the next lower power of 2 (16M and 16 associations) it doesn't
> | > complain but it still doesn't run.
> | 
> | The internal design of the data structures used by cachegrind assumes
> | that sizes will be powers of two and that it can compute indexes by
> | bit
> | masking.
> | 
> | That is, as you have found, no longer true for modern processors, but
> | to
> | date nobody has stepped up to fix cachegrind. On top of that it isn't
> | clear that there is a good fix that wouldn't produce a loss of
> | performance.
> | 
> | Tom
> | 
> | --
> | Tom Hughes (to...@co...)
> | http://compton.nu/
> | 
> 
> ------------------------------------------------------------------------------
> Open source business process management suite built on Java and Eclipse
> Turn processes into business applications with Bonita BPM Community Edition
> Quickly connect people, data, and systems into organized workflows
> Winner of BOSSIE, CODIE, OW2 and Gartner awards
> http://p.sf.net/sfu/Bonitasoft
> _______________________________________________
> Valgrind-users mailing list
> Val...@li...
> https://lists.sourceforge.net/lists/listinfo/valgrind-users
> 

Re: [Valgrind-users] cachegrind for Xeon e5-2643v2

[Jerry S. <js...@fi...>]

Tom and Josef,

Thank you for your speedy responses.

Is cachegrind an instrumentation of the real system or a simulation of the processor cache based on the code executed? From your responses, it sounds like the later. If so, this is actually better for what I want to do.

Because of the fact that the cache is shared among the cores, it is hard to tell from single runs what it will be like with concurrent jobs. If it is simulated and I can just set the cache size to whatever I want, I can run a job with different cache parameters and find at least a first order guess of how the job responds to cache size. This is the most useful thing for me right now.

It's a bit daunting when someone says I want millions of simulations running as fast as possible. That is a good hard challenge. I've done work on long lasting compute bound jobs, but this has a bunch more moving parts than just the sparse matrix solver and forward error tests.

jerry

----- Original Message -----
| From: "Tom Hughes" <to...@co...>
| To: "Jerry Scharf" <js...@fi...>, Val...@li...
| Sent: Thursday, July 3, 2014 12:32:59 AM
| Subject: Re: cachegrind for Xeon e5-2643v2
| 
| On 03/07/14 07:06, Jerry Scharf wrote:
| 
| > Why is it insisting that the numbers be powers of 2? If I use --LL
| > with the real numbers it refuses to start. If I round these down
| > to the next lower power of 2 (16M and 16 associations) it doesn't
| > complain but it still doesn't run.
| 
| The internal design of the data structures used by cachegrind assumes
| that sizes will be powers of two and that it can compute indexes by
| bit
| masking.
| 
| That is, as you have found, no longer true for modern processors, but
| to
| date nobody has stepped up to fix cachegrind. On top of that it isn't
| clear that there is a good fix that wouldn't produce a loss of
| performance.
| 
| Tom
| 
| --
| Tom Hughes (to...@co...)
| http://compton.nu/
| 

Re: [Valgrind-users] cachegrind for Xeon e5-2643v2

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

Am 03.07.2014 09:32, schrieb Tom Hughes:
> On 03/07/14 07:06, Jerry Scharf wrote:
> 
>> Why is it insisting that the numbers be powers of 2? If I use --LL with the real numbers it refuses to start. If I round these down to the next lower power of 2 (16M and 16 associations) it doesn't complain but it still doesn't run.

What's the output of "it still doesn't run"?

> The internal design of the data structures used by cachegrind assumes 
> that sizes will be powers of two and that it can compute indexes by bit 
> masking.

The cache size does not have to be a power of two, only the number of
sets has to,
to do the bit masking trick. E.g. 25MB with assoc 25, e.g.
"--LL=26214400,25,64"
works here. It probably does not make much difference between assoc of
20 or 25.

Of course we could use modulo instead of the bit mask trick, but this
gives around
a factor of 2 slowdown, also for the original fast power-of-two cases.

BTW, if you have a test system anyway, real performance measurements
should be
more important to you. Cachegrind mainly helps finding the code to
optimize for
reducing cache misses, and makes comparisons easier due to reproducability.

> That is, as you have found, no longer true for modern processors, but to 
> date nobody has stepped up to fix cachegrind.

The best way to fix this may just be to always find a good approximation of
parameters (keeping cache size is more important), which make the number
of sets a
power of two, and run simulation with these. Cachegrind results are an
approximation
anyway (no hardware prefetcher simulation, LRU may not be really correct).

Josef


> On top of that it isn't
> clear that there is a good fix that wouldn't produce a loss of performance.
> 
> Tom
> 

Re: [Valgrind-users] cachegrind for Xeon e5-2643v2

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

On 03/07/14 07:06, Jerry Scharf wrote:

> Why is it insisting that the numbers be powers of 2? If I use --LL with the real numbers it refuses to start. If I round these down to the next lower power of 2 (16M and 16 associations) it doesn't complain but it still doesn't run.

The internal design of the data structures used by cachegrind assumes 
that sizes will be powers of two and that it can compute indexes by bit 
masking.

That is, as you have found, no longer true for modern processors, but to 
date nobody has stepped up to fix cachegrind. On top of that it isn't 
clear that there is a good fix that wouldn't produce a loss of performance.

Tom

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

[Valgrind-users] cachegrind for Xeon e5-2643v2

[Jerry S. <js...@fi...>]

Hi,

I'm new to the list. A quick look at the archives found a number of people asking and not much clear guidance. If there is a document or thread that I need to look at, could you please point the way?

I have a critical need to understand the cache use and memory access for a circuit simulation situation. We are doing circuit simulation and need to run months of simulation for a particular project. I am the person tasked with building up the compute platform for this and I am trying to decide how to balance processor speed, cache size and cost to get the most simulation runs for our budget. The number of sims is near infinite, so it really about getting the most done for the buck.

As an added twist, one of the apps is a vendor supplied 32 bit app so I have needed to get 32 bit apps and libraries on my 64 bit machine to get cachegrind to run.

One of my test platforms that I build for another project has a pair of Intel Xeon e5-2643v2 processors. These have 6 cores and 25MB of L3 cache, so it gives me a great test for a high cache per core case. When I run cachegrind with no options, I get the right numbers back on the amount of memory and line width (64). I am guessing the number of associations (20) is right but I don't have specs to compare to.

Why is it insisting that the numbers be powers of 2? If I use --LL with the real numbers it refuses to start. If I round these down to the next lower power of 2 (16M and 16 associations) it doesn't complain but it still doesn't run.

What do I have to do to get this to work for me? What is the general solution for all the modern chips that have nothing bound to powers of 2? This seems to be a fundamental issue with modern processors.

thanks in advance,
jerry

Re: [Valgrind-users] 答复: valgrind3.9.0 does not work with my application.

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

> uname -a:
> Linux TB2SEE1 2.6.16.46-0.12-smp #1 SMP Thu May 17 14:00:09 UTC 2007 x86_64 x86_64 x86_64 GNU/Linux
> 
> rpm -q glibc:
> glibc-2.4.31.43.6.PTE.473402.0
> 
> /lib64/libc.so.6->libc.2.4.so

That information shows that the software environment is about 7 years old.
While valgrind-3.9.0 is the latest release, and problems with the latest
release always are relevant, the old age of the user application environment likely
will make it more difficult to catch and hold the attention of valgrind developers.

Here are two things that can be done to increase interest:

1) Construct a small test case which reproduces the problem.  Extract code
from the application, or write a new program.  Something like 50 to 100 lines
should be enough.  In some cases using 'strace' on the application (or on
valgrind running the application) may provide hints about what is important
just before the error.  In other cases using a debugger such as 'gdb'
may give insights about what is happening.  Pay particular attention
to signals, threading (if any), and other less-common events.

2) Reproduce the problem using recent glibc.  Determine the shared libraries
that the application uses by running "ldd ./my_application".  Intersect
that with the shared libraries provided by glibc, which are listed by: "rpm -ql glibc".
Then go to another machine that has recent glibc installed,
and copy the intersected shared libraries from the newer glibc installation
onto a new directory $NEWDIR on the _old_ machine.  In that new directory $NEWDIR
on the old machine, also create any symbolic links that are relevant,
such as libc.so -> libc-2.NN.so.

Then run valgrind running the old application using the newer glibc by:
	$NEWDIR/ld-linux-x86-64.so.2 --library-path $NEWDIR:$LD_LIBRARY_PATH \
	   valgrind _valgrind_options_  ./my_application _application_arguments_
Read the hints given by:
	$NEWDIR/ld-linux-x86-64.so.2
You can test the shared library dependencies using
	$NEWDIR/ld-linux-x86-64.so.2 --library-path $NEWDIR:$LD_LIBRARY_PATH --list ./my_application
to verify that all the shared libraries are coming from the correct directories.

If the problem persists when using current glibc, then that increases the motivation
of valgrind developers to investigate.  If the problem goes away when using current glibc,
then a) you have a running valgrind on the application, and b) why not install the newer glibc?