valgrind-users — General discussion list for Valgrind users

[Valgrind-users] Multi threading

[Dor B. D. <dor...@am...>]

Hi,

I am running valgrind in order to get a call graph, I am running top and I keep seeing only one thread 100% cpu working for valgrind.

Does valgrind have any parameters that I can set for him, so it will use all my machine cores (16 for example) ?

Regards,
Dor Ben Dov

This message and the information contained herein is proprietary and confidential and subject to the Amdocs policy statement,
you may review at http://www.amdocs.com/email_disclaimer.asp

[Valgrind-users] (no subject)

[Dor B. D. <dor...@am...>]

This message and the information contained herein is proprietary and confidential and subject to the Amdocs policy statement,
you may review at http://www.amdocs.com/email_disclaimer.asp

Re: [Valgrind-users] valgrind installation failed

[Alla _ <mod...@gm...>]

Thank you for your help!
I have installed it using sudo make install. It works now.

On Tue, Mar 15, 2016 at 4:04 PM, Alexander Potapenko <gl...@go...>
wrote:

> It will be accessible, but you'll have to provide the full path to the
> binary, e.g.
>  $ /path/to/valgrind/source/inst/bin/valgrind ./your_program
>
> If you want to just type `valgrind`, you'll need to either install it
> to /usr/local, or add  /path/to/valgrind/source/inst/bin/ to your
> PATH:
>  $ export PATH="$PATH:/path/to/valgrind/source/inst/bin/"
>
> HTH
>
> On Tue, Mar 15, 2016 at 12:30 PM, Alla _ <mod...@gm...> wrote:
> > Alexander,
> > Thank you very much for your answer.
> >
> > One more question:
> >
> > if I have the Valgrind package stored within my local directory together
> > with usual documents and study programs, and if I manage to successfully
> > install Valgrind (I will follow your advice now), do I understand
> correctly
> > that
> > it will be accessible from the Terminal, i.e. it doesn't matter where the
> > original
> > package is stored?
> >
> > Thank you!
> > Best,
> > Alla
> >
> > On Tue, Mar 15, 2016 at 3:12 PM, Alexander Potapenko <gl...@go...>
> > wrote:
> >>
> >> Looks like you're trying to install to /usr/local with insufficient
> >> privileges.
> >> You can either run `sudo make install` to install as root, or
> >> configure the build to put the binaries into a local directory:
> >>  $ ./autogen.sh
> >>  $ ./configure --prefix=`pwd`/inst
> >>  $ make && make install
> >>
> >> On Tue, Mar 15, 2016 at 11:41 AM, Alla _ <mod...@gm...>
> wrote:
> >> > Hello!
> >> >
> >> > I am a newbie, learning C programming. Have just tried to install
> >> > Valgrind,
> >> > following instructions in the README. Installation failed. My system:
> >> > Mac OS
> >> > X 10.7.5
> >> >
> >> > Here are the steps I made:
> >> >
> >> > installed
> >> >
> >> > curl -OL http://ftpmirror.gnu.org/autoconf/autoconf-latest.tar.gz
> >> > tar -xzf autoconf-latest.tar.gz
> >> > cd autoconf-[x.xx]
> >> > ./configure && make && sudo make install
> >> >
> >> > curl -OL http://ftpmirror.gnu.org/automake/automake-1.15.tar.gz
> >> > tar -xzf automake-1.15.tar.gz
> >> > cd automake-1.15
> >> > ./configure && make && sudo make install
> >> >
> >> > cd valgrind-3.11.0
> >> > ./autogen.sh
> >> > ./configure
> >> >
> >> > make
> >> >
> >> > make install
> >> >
> >> > Here is the message I got in Terminal after make install command:
> >> > make  install-recursive
> >> > Making install in include
> >> > make[3]: Nothing to be done for `install-exec-am'.
> >> >  .././install-sh -c -d '/usr/local/include/valgrind'
> >> > mkdir: /usr/local/include/valgrind: Permission denied
> >> > make[3]: *** [install-nobase_pkgincludeHEADERS] Error 1
> >> > make[2]: *** [install-am] Error 2
> >> > make[1]: *** [install-recursive] Error 1
> >> > make: *** [install] Error 2
> >> >
> >> >
> >> >
> >> > Respectfully,
> >> > Alla
> >> >
> >> >
> >> >
> >> >
> ------------------------------------------------------------------------------
> >> > Transform Data into Opportunity.
> >> > Accelerate data analysis in your applications with
> >> > Intel Data Analytics Acceleration Library.
> >> > Click to learn more.
> >> > http://pubads.g.doubleclick.net/gampad/clk?id=278785231&iu=/4140
> >> > _______________________________________________
> >> > Valgrind-users mailing list
> >> > Val...@li...
> >> > https://lists.sourceforge.net/lists/listinfo/valgrind-users
> >> >
> >>
> >>
> >>
> >> --
> >> Alexander Potapenko
> >> Software Engineer
> >>
> >> Google Germany GmbH
> >> Erika-Mann-Straße, 33
> >> 80636 München
> >>
> >> Geschäftsführer: Matthew Scott Sucherman, Paul Terence Manicle
> >> Registergericht und -nummer: Hamburg, HRB 86891
> >> Sitz der Gesellschaft: Hamburg
> >
> >
> >
> >
> > --
> > Respectfully,
> > Alla
> >
>
>
>
> --
> Alexander Potapenko
> Software Engineer
>
> Google Germany GmbH
> Erika-Mann-Straße, 33
> 80636 München
>
> Geschäftsführer: Matthew Scott Sucherman, Paul Terence Manicle
> Registergericht und -nummer: Hamburg, HRB 86891
> Sitz der Gesellschaft: Hamburg
>



-- 

*Respectfully,*
*Alla*

Re: [Valgrind-users] valgrind installation failed

[Alexander P. <gl...@go...>]

It will be accessible, but you'll have to provide the full path to the
binary, e.g.
 $ /path/to/valgrind/source/inst/bin/valgrind ./your_program

If you want to just type `valgrind`, you'll need to either install it
to /usr/local, or add  /path/to/valgrind/source/inst/bin/ to your
PATH:
 $ export PATH="$PATH:/path/to/valgrind/source/inst/bin/"

HTH

On Tue, Mar 15, 2016 at 12:30 PM, Alla _ <mod...@gm...> wrote:
> Alexander,
> Thank you very much for your answer.
>
> One more question:
>
> if I have the Valgrind package stored within my local directory together
> with usual documents and study programs, and if I manage to successfully
> install Valgrind (I will follow your advice now), do I understand correctly
> that
> it will be accessible from the Terminal, i.e. it doesn't matter where the
> original
> package is stored?
>
> Thank you!
> Best,
> Alla
>
> On Tue, Mar 15, 2016 at 3:12 PM, Alexander Potapenko <gl...@go...>
> wrote:
>>
>> Looks like you're trying to install to /usr/local with insufficient
>> privileges.
>> You can either run `sudo make install` to install as root, or
>> configure the build to put the binaries into a local directory:
>>  $ ./autogen.sh
>>  $ ./configure --prefix=`pwd`/inst
>>  $ make && make install
>>
>> On Tue, Mar 15, 2016 at 11:41 AM, Alla _ <mod...@gm...> wrote:
>> > Hello!
>> >
>> > I am a newbie, learning C programming. Have just tried to install
>> > Valgrind,
>> > following instructions in the README. Installation failed. My system:
>> > Mac OS
>> > X 10.7.5
>> >
>> > Here are the steps I made:
>> >
>> > installed
>> >
>> > curl -OL http://ftpmirror.gnu.org/autoconf/autoconf-latest.tar.gz
>> > tar -xzf autoconf-latest.tar.gz
>> > cd autoconf-[x.xx]
>> > ./configure && make && sudo make install
>> >
>> > curl -OL http://ftpmirror.gnu.org/automake/automake-1.15.tar.gz
>> > tar -xzf automake-1.15.tar.gz
>> > cd automake-1.15
>> > ./configure && make && sudo make install
>> >
>> > cd valgrind-3.11.0
>> > ./autogen.sh
>> > ./configure
>> >
>> > make
>> >
>> > make install
>> >
>> > Here is the message I got in Terminal after make install command:
>> > make  install-recursive
>> > Making install in include
>> > make[3]: Nothing to be done for `install-exec-am'.
>> >  .././install-sh -c -d '/usr/local/include/valgrind'
>> > mkdir: /usr/local/include/valgrind: Permission denied
>> > make[3]: *** [install-nobase_pkgincludeHEADERS] Error 1
>> > make[2]: *** [install-am] Error 2
>> > make[1]: *** [install-recursive] Error 1
>> > make: *** [install] Error 2
>> >
>> >
>> >
>> > Respectfully,
>> > Alla
>> >
>> >
>> >
>> > ------------------------------------------------------------------------------
>> > Transform Data into Opportunity.
>> > Accelerate data analysis in your applications with
>> > Intel Data Analytics Acceleration Library.
>> > Click to learn more.
>> > http://pubads.g.doubleclick.net/gampad/clk?id=278785231&iu=/4140
>> > _______________________________________________
>> > Valgrind-users mailing list
>> > Val...@li...
>> > https://lists.sourceforge.net/lists/listinfo/valgrind-users
>> >
>>
>>
>>
>> --
>> Alexander Potapenko
>> Software Engineer
>>
>> Google Germany GmbH
>> Erika-Mann-Straße, 33
>> 80636 München
>>
>> Geschäftsführer: Matthew Scott Sucherman, Paul Terence Manicle
>> Registergericht und -nummer: Hamburg, HRB 86891
>> Sitz der Gesellschaft: Hamburg
>
>
>
>
> --
> Respectfully,
> Alla
>



-- 
Alexander Potapenko
Software Engineer

Google Germany GmbH
Erika-Mann-Straße, 33
80636 München

Geschäftsführer: Matthew Scott Sucherman, Paul Terence Manicle
Registergericht und -nummer: Hamburg, HRB 86891
Sitz der Gesellschaft: Hamburg

Re: [Valgrind-users] valgrind installation failed

[Alla _ <mod...@gm...>]

Alexander,
Thank you very much for your answer.

One more question:

if I have the Valgrind package stored within my local directory together
with usual documents and study programs, and if I manage to successfully
install Valgrind (I will follow your advice now), do I understand correctly
that
it will be accessible from the Terminal, i.e. it doesn't matter where the
original
package is stored?

Thank you!
Best,
Alla

On Tue, Mar 15, 2016 at 3:12 PM, Alexander Potapenko <gl...@go...>
wrote:

> Looks like you're trying to install to /usr/local with insufficient
> privileges.
> You can either run `sudo make install` to install as root, or
> configure the build to put the binaries into a local directory:
>  $ ./autogen.sh
>  $ ./configure --prefix=`pwd`/inst
>  $ make && make install
>
> On Tue, Mar 15, 2016 at 11:41 AM, Alla _ <mod...@gm...> wrote:
> > Hello!
> >
> > I am a newbie, learning C programming. Have just tried to install
> Valgrind,
> > following instructions in the README. Installation failed. My system:
> Mac OS
> > X 10.7.5
> >
> > Here are the steps I made:
> >
> > installed
> >
> > curl -OL http://ftpmirror.gnu.org/autoconf/autoconf-latest.tar.gz
> > tar -xzf autoconf-latest.tar.gz
> > cd autoconf-[x.xx]
> > ./configure && make && sudo make install
> >
> > curl -OL http://ftpmirror.gnu.org/automake/automake-1.15.tar.gz
> > tar -xzf automake-1.15.tar.gz
> > cd automake-1.15
> > ./configure && make && sudo make install
> >
> > cd valgrind-3.11.0
> > ./autogen.sh
> > ./configure
> >
> > make
> >
> > make install
> >
> > Here is the message I got in Terminal after make install command:
> > make  install-recursive
> > Making install in include
> > make[3]: Nothing to be done for `install-exec-am'.
> >  .././install-sh -c -d '/usr/local/include/valgrind'
> > mkdir: /usr/local/include/valgrind: Permission denied
> > make[3]: *** [install-nobase_pkgincludeHEADERS] Error 1
> > make[2]: *** [install-am] Error 2
> > make[1]: *** [install-recursive] Error 1
> > make: *** [install] Error 2
> >
> >
> >
> > Respectfully,
> > Alla
> >
> >
> >
> ------------------------------------------------------------------------------
> > Transform Data into Opportunity.
> > Accelerate data analysis in your applications with
> > Intel Data Analytics Acceleration Library.
> > Click to learn more.
> > http://pubads.g.doubleclick.net/gampad/clk?id=278785231&iu=/4140
> > _______________________________________________
> > Valgrind-users mailing list
> > Val...@li...
> > https://lists.sourceforge.net/lists/listinfo/valgrind-users
> >
>
>
>
> --
> Alexander Potapenko
> Software Engineer
>
> Google Germany GmbH
> Erika-Mann-Straße, 33
> 80636 München
>
> Geschäftsführer: Matthew Scott Sucherman, Paul Terence Manicle
> Registergericht und -nummer: Hamburg, HRB 86891
> Sitz der Gesellschaft: Hamburg
>



-- 

*Respectfully,*
*Alla*

Re: [Valgrind-users] valgrind installation failed

[Alexander P. <gl...@go...>]

Looks like you're trying to install to /usr/local with insufficient privileges.
You can either run `sudo make install` to install as root, or
configure the build to put the binaries into a local directory:
 $ ./autogen.sh
 $ ./configure --prefix=`pwd`/inst
 $ make && make install

On Tue, Mar 15, 2016 at 11:41 AM, Alla _ <mod...@gm...> wrote:
> Hello!
>
> I am a newbie, learning C programming. Have just tried to install Valgrind,
> following instructions in the README. Installation failed. My system: Mac OS
> X 10.7.5
>
> Here are the steps I made:
>
> installed
>
> curl -OL http://ftpmirror.gnu.org/autoconf/autoconf-latest.tar.gz
> tar -xzf autoconf-latest.tar.gz
> cd autoconf-[x.xx]
> ./configure && make && sudo make install
>
> curl -OL http://ftpmirror.gnu.org/automake/automake-1.15.tar.gz
> tar -xzf automake-1.15.tar.gz
> cd automake-1.15
> ./configure && make && sudo make install
>
> cd valgrind-3.11.0
> ./autogen.sh
> ./configure
>
> make
>
> make install
>
> Here is the message I got in Terminal after make install command:
> make  install-recursive
> Making install in include
> make[3]: Nothing to be done for `install-exec-am'.
>  .././install-sh -c -d '/usr/local/include/valgrind'
> mkdir: /usr/local/include/valgrind: Permission denied
> make[3]: *** [install-nobase_pkgincludeHEADERS] Error 1
> make[2]: *** [install-am] Error 2
> make[1]: *** [install-recursive] Error 1
> make: *** [install] Error 2
>
>
>
> Respectfully,
> Alla
>
>
> ------------------------------------------------------------------------------
> Transform Data into Opportunity.
> Accelerate data analysis in your applications with
> Intel Data Analytics Acceleration Library.
> Click to learn more.
> http://pubads.g.doubleclick.net/gampad/clk?id=278785231&iu=/4140
> _______________________________________________
> Valgrind-users mailing list
> Val...@li...
> https://lists.sourceforge.net/lists/listinfo/valgrind-users
>



-- 
Alexander Potapenko
Software Engineer

Google Germany GmbH
Erika-Mann-Straße, 33
80636 München

Geschäftsführer: Matthew Scott Sucherman, Paul Terence Manicle
Registergericht und -nummer: Hamburg, HRB 86891
Sitz der Gesellschaft: Hamburg

[Valgrind-users] valgrind installation failed

[Alla _ <mod...@gm...>]

Hello!

I am a newbie, learning C programming. Have just tried to install Valgrind,
following instructions in the README. Installation failed. My system: Mac
OS X 10.7.5

Here are the steps I made:

installed

curl -OL http://ftpmirror.gnu.org/autoconf/autoconf-latest.tar.gz
tar -xzf autoconf-latest.tar.gz
cd autoconf-[x.xx]
./configure && make && sudo make install

curl -OL http://ftpmirror.gnu.org/automake/automake-1.15.tar.gz
tar -xzf automake-1.15.tar.gz
cd automake-1.15
./configure && make && sudo make install

cd valgrind-3.11.0
./autogen.sh
./configure

make

make install

Here is the message I got in Terminal after make install command:
make  install-recursive
Making install in include
make[3]: Nothing to be done for `install-exec-am'.
 .././install-sh -c -d '/usr/local/include/valgrind'
mkdir: /usr/local/include/valgrind: Permission denied
make[3]: *** [install-nobase_pkgincludeHEADERS] Error 1
make[2]: *** [install-am] Error 2
make[1]: *** [install-recursive] Error 1
make: *** [install] Error 2




*Respectfully,*
*Alla*

Re: [Valgrind-users] can memchecker mark memory as read-only ?

[Christoph N. <nie...@hl...>]

Hi,

Regarding your question about marking memory read only and using this for MPI Message checking I would recommend, you read the following paper from a former colleque of mine:

Memory Debugging of MPI-Parallel Applications in Open MPI
Rainer Keller, Shiqing Fan, and Michael Resch

I'm currently re-evaluating the implementation with respect to a major Open MPI version update.
If you are interested in it do not hesitate to contact me.

Best regards
Christoph Niethammer

--

Christoph Niethammer
High Performance Computing Center Stuttgart (HLRS)
Nobelstrasse 19
70569 Stuttgart

Tel: ++49(0)711-685-87203
email: nie...@hl...
http://www.hlrs.de/people/niethammer


----- Original Message -----
From: "John Reiser" <jr...@bi...>
To: "valgrind-users" <val...@li...>
Sent: Wednesday, March 9, 2016 5:25:25 PM
Subject: Re: [Valgrind-users] can memchecker mark memory as read-only ?

> Currently, my understanding is that valgrind memchecker can mark a
> memory area as non accessible via the VALGRIND_MAKE_MEM_NOACCESS()
> macro, but there is currently no way to mark it as read-only.

Yes. READ_ONLY is not a recognized state.

> if yes, is there any plan to develop such a feature ?

No.  The accounting bits are organized into two phases: is the address legal
at all, and is the byte writable and initialized.  Adding a new state
READ_ONLY would be a large task with significant runtime costs.
It might be best applied to the first phase, but complications
regarding overlap [or splitting] between existing regions and new READ_ONLY
regions, plus granularity assumptions (pages now, bytes for READ_ONLY)
probably would be messy.

>>From an OpenMPI developer point of view, it would be nice to mark the send
> buffer as read-only between MPI_Isend() and MPI_Wait() so valgrind can trap
> incorrect user code that modifies the send buffer when it is not allowed.

Use LD_PRELOAD to intercept MPI_Isend() [etc.].  Allocate a new buffer,
copy the message into it, mark the original buffer as NOACCESS, call the
original MPI_Isend on the new buffer. Reverse the effects after
the original MPI_Isend() is complete, waited, and checked.
See the manual page for "man dlsym" and the RTLD_NEXT functionality.
Search the web, too.





------------------------------------------------------------------------------
Transform Data into Opportunity.
Accelerate data analysis in your applications with
Intel Data Analytics Acceleration Library.
Click to learn more.
http://pubads.g.doubleclick.net/gampad/clk?id=278785111&iu=/4140
_______________________________________________
Valgrind-users mailing list
Val...@li...
https://lists.sourceforge.net/lists/listinfo/valgrind-users

[Valgrind-users] Bug review

[Vasantha G. K <vas...@tu...>]

Hello all,
  I filed a bug and added a patch to the same, this is my first patch. Please 
review it. Thanks in advance.
Here is the link: https://bugs.kde.org/show_bug.cgi?id=360429
Vasantha Ganesh K

[Valgrind-users] Helgrind mutex_is_valid assert

[Tony P. <tp...@as...>]

I just ran helgrind on one of our internal apps and the mutex_is_valid
assert is firing when pthread_cond_timedwait is called.  I don't see any
problem with our code as far as I can tell.  The mutex is locked by the
calling thread when pthread_cond_timedwait() is invoked.  I was reading the
docs and it mentioned something about dynamic condition/mutex bindings
being a potential problem.  Can anyone explain this?

The gist of the code flagging the problem is that we have three threads
calling pthread_cond_timedwait with a half-second delay.  A fourth thread
will broadcast the condition.  All four threads share the same mutex and
lock it while in use.

I brought-up gdbserver and everything looks OK with the mutex when
pthread_cond_timedwait is called.  What other conditions can flag this
error?

Tony

Re: [Valgrind-users] Will the BBV tool support ARMv7 and ARMv8?

[Florian K. <fl...@ei...>]

The BBV developer has long left. There are no plans to enhance that
tool's functionality to support other platforms.

   Florian

On 09.03.2016 07:35, Lennox Wu wrote:
> Hi all,
> According to the document of BBV tool, ARM is not supported currently.
> Is there any plan to support ARMv7 and ARMv8?
> 
> Best,
> Lennox
> 
> 
> 
> ------------------------------------------------------------------------------
> Transform Data into Opportunity.
> Accelerate data analysis in your applications with
> Intel Data Analytics Acceleration Library.
> Click to learn more.
> http://pubads.g.doubleclick.net/gampad/clk?id=278785111&iu=/4140
> 
> 
> 
> _______________________________________________
> Valgrind-users mailing list
> Val...@li...
> https://lists.sourceforge.net/lists/listinfo/valgrind-users
> 

Re: [Valgrind-users] can memchecker mark memory as read-only ?

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

> Currently, my understanding is that valgrind memchecker can mark a
> memory area as non accessible via the VALGRIND_MAKE_MEM_NOACCESS()
> macro, but there is currently no way to mark it as read-only.

Yes. READ_ONLY is not a recognized state.

> if yes, is there any plan to develop such a feature ?

No.  The accounting bits are organized into two phases: is the address legal
at all, and is the byte writable and initialized.  Adding a new state
READ_ONLY would be a large task with significant runtime costs.
It might be best applied to the first phase, but complications
regarding overlap [or splitting] between existing regions and new READ_ONLY
regions, plus granularity assumptions (pages now, bytes for READ_ONLY)
probably would be messy.

>>From an OpenMPI developer point of view, it would be nice to mark the send
> buffer as read-only between MPI_Isend() and MPI_Wait() so valgrind can trap
> incorrect user code that modifies the send buffer when it is not allowed.

Use LD_PRELOAD to intercept MPI_Isend() [etc.].  Allocate a new buffer,
copy the message into it, mark the original buffer as NOACCESS, call the
original MPI_Isend on the new buffer. Reverse the effects after
the original MPI_Isend() is complete, waited, and checked.
See the manual page for "man dlsym" and the RTLD_NEXT functionality.
Search the web, too.

[Valgrind-users] can memchecker mark memory as read-only ?

[Gilles G. <gil...@gm...>]

Folks,

Currently, my understanding is that valgrind memchecker can mark a
memory area as non accessible via the VALGRIND_MAKE_MEM_NOACCESS()
macro,
but there is currently no way to mark it as read-only.

am i right ?
if yes, is there any plan to develop such a feature ?

Thanks,

Gilles

FWIW, here is the context.
in MPI http://www.mpi-forum.org/, the MPI_Isend() function can be used
for a non blocking send. Today's standard mandates the send buffer
remains accessible during the send operation, but the end user should
not modify it unless the send is complete (for example after
MPI_Wait() returns).
>From an OpenMPI developer point of view, it would be nice to mark the send
buffer as read-only between MPI_Isend() and MPI_Wait() so valgrind can trap
incorrect user code that modifies the send buffer when it is not allowed.

[Valgrind-users] Will the BBV tool support ARMv7 and ARMv8?

[Lennox Wu <len...@gm...>]

Hi all,
According to the document of BBV tool, ARM is not supported currently.
Is there any plan to support ARMv7 and ARMv8?

Best,
Lennox

[Valgrind-users] valgrind + MPI: What's causing these reported errors?

[Florian L. <mai...@xg...>]

Hello,

I'm using valgrind 3.11.0 with openmpi 1.10.2. Distribution is Arch, valgrind is properly built with MPI support.

I compile with:

mpicxx -std=c++11 -g -O0 -Wall mpi.cpp 

and execute:

LD_PRELOAD=/usr/lib/valgrind/libmpiwrap-amd64-linux.so mpirun -n 2 valgrind ./a.out

Valgrind reports a number of invalid reads and I have no idea why it is so or whether they are false positives...

I appreciate any help!

Thanks,
Florian


CODE mpi.cpp

#include <mpi.h>
#include <iostream>
#include <string>

using namespace std;


void receive(int rankSender) {
  int length = 0;
  MPI_Status status;
  MPI_Probe(rankSender, 0, MPI_COMM_WORLD, &status);
  MPI_Get_count(&status, MPI_CHAR, &length);
  cout << "Stringlength = " << length << endl;
  char cstr[length];
  MPI_Recv(&cstr,
           length,
           MPI_CHAR,
           rankSender,
           0,
           MPI_COMM_WORLD,
           MPI_STATUS_IGNORE);
  cout << cstr << endl;
}

void send(int rankReceiver) {
  std::string s = "Hallo";
  MPI_Send(s.c_str(),
           s.size() + 1,
           MPI_CHAR,
           rankReceiver,
           0,
           MPI_COMM_WORLD);
}



int main(int argc, char* argv[])
{
  int rank;
  MPI_Init(&argc, &argv);

  MPI_Comm_rank(MPI_COMM_WORLD, &rank);
  if (rank == 0)
    send(1);
  else {
    receive(0);
  }
  MPI_Finalize();
  return 0;
}



VALGRIND OUTPUT

% LD_PRELOAD=/usr/lib/valgrind/libmpiwrap-amd64-linux.so mpirun -n 2 valgrind ./a.out
==11513== Memcheck, a memory error detector
==11513== Copyright (C) 2002-2015, and GNU GPL'd, by Julian Seward et al.
==11513== Using Valgrind-3.11.0 and LibVEX; rerun with -h for copyright info
==11513== Command: ./a.out
==11513== 
==11514== Memcheck, a memory error detector
==11514== Copyright (C) 2002-2015, and GNU GPL'd, by Julian Seward et al.
==11514== Using Valgrind-3.11.0 and LibVEX; rerun with -h for copyright info
==11514== Command: ./a.out
==11514== 
valgrind MPI wrappers 11514: Active for pid 11514
valgrind MPI wrappers 11514: Try MPIWRAP_DEBUG=help for possible options
valgrind MPI wrappers 11513: Active for pid 11513
valgrind MPI wrappers 11513: Try MPIWRAP_DEBUG=help for possible options
Stringlength = 6
==11514== Invalid read of size 1
==11514==    at 0x4C2DBA2: strlen (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==11514==    by 0x56852D8: length (char_traits.h:267)
==11514==    by 0x56852D8: std::basic_ostream<char, std::char_traits<char> >& std::operator<< <std::char_traits<char> >(std::basic_ostream<char, std::char_traits<char> >&, char const*) (ostream:562)
==11514==    by 0x408A3C: receive(int) (mpi.cpp:22)
==11514==    by 0x408B69: main (mpi.cpp:46)
==11514==  Address 0xffefff860 is on thread 1's stack
==11514==  in frame #2, created by receive(int) (mpi.cpp:8)
==11514== 
==11514== Invalid read of size 1
==11514==    at 0x4C2DBB4: strlen (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==11514==    by 0x56852D8: length (char_traits.h:267)
==11514==    by 0x56852D8: std::basic_ostream<char, std::char_traits<char> >& std::operator<< <std::char_traits<char> >(std::basic_ostream<char, std::char_traits<char> >&, char const*) (ostream:562)
==11514==    by 0x408A3C: receive(int) (mpi.cpp:22)
==11514==    by 0x408B69: main (mpi.cpp:46)
==11514==  Address 0xffefff861 is on thread 1's stack
==11514==  in frame #2, created by receive(int) (mpi.cpp:8)
==11514== 
==11514== Invalid read of size 1
==11514==    at 0x60A0FF1: _IO_file_xsputn@@GLIBC_2.2.5 (in /usr/lib/libc-2.23.so)
==11514==    by 0x6096D1A: fwrite (in /usr/lib/libc-2.23.so)
==11514==    by 0x5684F75: sputn (streambuf:451)
==11514==    by 0x5684F75: __ostream_write<char, std::char_traits<char> > (ostream_insert.h:50)
==11514==    by 0x5684F75: std::basic_ostream<char, std::char_traits<char> >& std::__ostream_insert<char, std::char_traits<char> >(std::basic_ostream<char, std::char_traits<char> >&, char const*, long) (ostream_insert.h:101)
==11514==    by 0x56852E6: std::basic_ostream<char, std::char_traits<char> >& std::operator<< <std::char_traits<char> >(std::basic_ostream<char, std::char_traits<char> >&, char const*) (ostream:561)
==11514==    by 0x408A3C: receive(int) (mpi.cpp:22)
==11514==    by 0x408B69: main (mpi.cpp:46)
==11514==  Address 0xffefff864 is on thread 1's stack
==11514==  in frame #4, created by receive(int) (mpi.cpp:8)
==11514== 
==11514== Invalid read of size 1
==11514==    at 0x60A100D: _IO_file_xsputn@@GLIBC_2.2.5 (in /usr/lib/libc-2.23.so)
==11514==    by 0x6096D1A: fwrite (in /usr/lib/libc-2.23.so)
==11514==    by 0x5684F75: sputn (streambuf:451)
==11514==    by 0x5684F75: __ostream_write<char, std::char_traits<char> > (ostream_insert.h:50)
==11514==    by 0x5684F75: std::basic_ostream<char, std::char_traits<char> >& std::__ostream_insert<char, std::char_traits<char> >(std::basic_ostream<char, std::char_traits<char> >&, char const*, long) (ostream_insert.h:101)
==11514==    by 0x56852E6: std::basic_ostream<char, std::char_traits<char> >& std::operator<< <std::char_traits<char> >(std::basic_ostream<char, std::char_traits<char> >&, char const*) (ostream:561)
==11514==    by 0x408A3C: receive(int) (mpi.cpp:22)
==11514==    by 0x408B69: main (mpi.cpp:46)
==11514==  Address 0xffefff863 is on thread 1's stack
==11514==  in frame #4, created by receive(int) (mpi.cpp:8)
==11514== 
==11514== Invalid read of size 2
==11514==    at 0x4C2F9C0: __GI_memcpy (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==11514==    by 0x60A0F3A: _IO_file_xsputn@@GLIBC_2.2.5 (in /usr/lib/libc-2.23.so)
==11514==    by 0x6096D1A: fwrite (in /usr/lib/libc-2.23.so)
==11514==    by 0x5684F75: sputn (streambuf:451)
==11514==    by 0x5684F75: __ostream_write<char, std::char_traits<char> > (ostream_insert.h:50)
==11514==    by 0x5684F75: std::basic_ostream<char, std::char_traits<char> >& std::__ostream_insert<char, std::char_traits<char> >(std::basic_ostream<char, std::char_traits<char> >&, char const*, long) (ostream_insert.h:101)
==11514==    by 0x56852E6: std::basic_ostream<char, std::char_traits<char> >& std::operator<< <std::char_traits<char> >(std::basic_ostream<char, std::char_traits<char> >&, char const*) (ostream:561)
==11514==    by 0x408A3C: receive(int) (mpi.cpp:22)
==11514==    by 0x408B69: main (mpi.cpp:46)
==11514==  Address 0xffefff860 is on thread 1's stack
==11514==  in frame #5, created by receive(int) (mpi.cpp:8)
==11514== 
==11514== Invalid read of size 1
==11514==    at 0x4C2F9F8: __GI_memcpy (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==11514==    by 0x60A0F3A: _IO_file_xsputn@@GLIBC_2.2.5 (in /usr/lib/libc-2.23.so)
==11514==    by 0x6096D1A: fwrite (in /usr/lib/libc-2.23.so)
==11514==    by 0x5684F75: sputn (streambuf:451)
==11514==    by 0x5684F75: __ostream_write<char, std::char_traits<char> > (ostream_insert.h:50)
==11514==    by 0x5684F75: std::basic_ostream<char, std::char_traits<char> >& std::__ostream_insert<char, std::char_traits<char> >(std::basic_ostream<char, std::char_traits<char> >&, char const*, long) (ostream_insert.h:101)
==11514==    by 0x56852E6: std::basic_ostream<char, std::char_traits<char> >& std::operator<< <std::char_traits<char> >(std::basic_ostream<char, std::char_traits<char> >&, char const*) (ostream:561)
==11514==    by 0x408A3C: receive(int) (mpi.cpp:22)
==11514==    by 0x408B69: main (mpi.cpp:46)
==11514==  Address 0xffefff864 is on thread 1's stack
==11514==  in frame #5, created by receive(int) (mpi.cpp:8)
==11514== 
Hallo
==11514== 
==11514== HEAP SUMMARY:
==11514==     in use at exit: 96,351 bytes in 247 blocks
==11514==   total heap usage: 15,025 allocs, 14,778 frees, 13,362,600 bytes allocated
==11514== 
==11514== LEAK SUMMARY:
==11514==    definitely lost: 9,154 bytes in 39 blocks
==11514==    indirectly lost: 4,008 bytes in 22 blocks
==11514==      possibly lost: 0 bytes in 0 blocks
==11514==    still reachable: 83,189 bytes in 186 blocks
==11514==         suppressed: 0 bytes in 0 blocks
==11514== Rerun with --leak-check=full to see details of leaked memory
==11514== 
==11514== For counts of detected and suppressed errors, rerun with: -v
==11514== ERROR SUMMARY: 14 errors from 6 contexts (suppressed: 0 from 0)
==11513== 
==11513== HEAP SUMMARY:
==11513==     in use at exit: 96,351 bytes in 247 blocks
==11513==   total heap usage: 15,023 allocs, 14,776 frees, 13,370,262 bytes allocated
==11513== 
==11513== LEAK SUMMARY:
==11513==    definitely lost: 9,154 bytes in 39 blocks
==11513==    indirectly lost: 4,008 bytes in 22 blocks
==11513==      possibly lost: 0 bytes in 0 blocks
==11513==    still reachable: 83,189 bytes in 186 blocks
==11513==         suppressed: 0 bytes in 0 blocks
==11513== Rerun with --leak-check=full to see details of leaked memory
==11513== 
==11513== For counts of detected and suppressed errors, rerun with: -v
==11513== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)
florian@asaru ~/scratch (git)-[master] % 

Re: [Valgrind-users] Segfault, Assertion 'bad_scanned_addr >= VG_ROUNDUP (MPI / pthread program)

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

On Mon, 2016-02-22 at 22:16 -0500, Jim wrote:

> 2. run with --leak-check=no
>   do we still see a SEGV ?
> 
>   Yes, problem still persists. Still a SEGV with the same error stack
> track from memcheck.
So, this indicates that what you see is not related to the bug 353891
which was solved with revision 15716 : this bug could only be
triggered when doing a leak search.

Is the SEGV also produced when using other tools ?
(e.g.  --tool=none ? --tool=lackey ? --tool=helgrind ?
 --tool=callgrind ?)


> 
> 3. run with more tracing i.e. with
>    -v -v -v -d -d -d --vgdb-stop-at=valgrindabexit
>   valgrind should stop and wait for vgdb when encountering the assert.
>   Then in another shell window, do
>      vgdb  v.info memory aspacemgr
>   Valgrind will produce the memory mapping.
>   We can then see if the address causing the SEGV is somewhat special
>   (e.g. what is the segment of this address ? Was this a thread stack ?
>   ...)
> 
> ==> this didn't work for me; ended with an error instead of waiting.
> see attached file for the full output.
vgdb is supposed to work on MacOs but last time I tested was something
like 4 years ago so status is unknown :(.

Nevertheless, the trace has given the aspacemgr mapping.

The log only contains the valgrind trace, not the 'normal output'.
But assuming the same address causes the SEGV (0x7000036B2C1C),
then this is really strange: this address is inside the segment:
--68920:1: aspacem 203: ANON 7000035bc000-7000036bbfff 1048576 rwx--
which is the valgrind stack of the thread tid 6 ???

The trace shows other not understandable entries such as:
--68920:2: stacks   no addressable segment for SP 0x70000373EF80

So, it looks like at thread startup time or very quickly after
thread startup, we have a SP which is outside any segment
as maintained by valgrind aspacemgr.
This is all very strange/not understandable.

Maybe you could try to increase the valgrind stack size, just
to experiment. Try e.g. with--valgrind-stacksize=8388608.
If you can control the user thread stacksize, maybe also try
to increase it.
   
At this stage, I have not much idea, and without a reproducer
on linux, not much chance to to find the problem with
mail remote debugging :(.

Philippe

[Valgrind-users] How to use valgrind with Python+Numpy+Theano

[Wenjie <wen...@gm...>]

Hi,

How to use valgrind to check Python + Numpy + Theano program?
Do I need to recompile python numpy and theano?

Thanks,
Wenjie

Re: [Valgrind-users] Segfault, Assertion 'bad_scanned_addr >= VG_ROUNDUP (MPI / pthread program)

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

On Mon, 2016-02-22 at 13:26 -0500, Jim wrote:
> I'd appreciate any input on helping me track this error down. Is this
> a problem with valgrind, or with my program? Please let me know if
> there's more information I should post.
Can you do the following 4 trials and attach the resulting logs
to the bug 349128, which maybe/probably is the best matching bug ?

When looking at the log of your program, I am not very sure
that the 'initial problem' is linked to the leak search.
The bug 353891 fixed in revision 15716 had the following symptoms:
  program running normally, no SEGV encountered
  leak search starting
  SEGV during leak search due to heuristic dereferences  not protected
  assert failing as there was no specific handler for heuristic dereferences

While in your case, we first see a SEGV,
followed by a leak search which then causes a similar assert.

So, I suspect what you see is a 'client' SEGV, causing a termination
of the program. This termination implies a leak search, and during
the leak search, we encounter a 'second bug', which is in any case
unexpected, as revision 15716 is supposed to have fixed all that :(.

The initial SEGV is maybe the indication of something strange
happening during thread termination, causing after
the SEGV and/or leak search problem. See helgrind/tests/stackteardown.c
for a somewhat strange way in which android terminates a thread.
Maybe something similar happens on MacOS and/or with MPI.
E.g. maybe MPI uses shared memory in a special way ?

With the below 4 trials, we might have a better idea of the bug origin.

Thanks
Philippe

Trials to do:

1. run with --leak-check-heuristics=none
   If the problem is fixed, then do:
     for h in stdstring length64 newarray multipleinheritance
     do
       run with --leak-check-heuristics=$h
     done
   to find which heuristic causes the problem.

2. run with --leak-check=no
  do we still see a SEGV ?

3. run with more tracing i.e. with
   -v -v -v -d -d -d --vgdb-stop-at=valgrindabexit
  valgrind should stop and wait for vgdb when encountering the assert.
  Then in another shell window, do
     vgdb  v.info memory aspacemgr
  Valgrind will produce the memory mapping.
  We can then see if the address causing the SEGV is somewhat special
  (e.g. what is the segment of this address ? Was this a thread stack ?
  ...)

4. Would it be possible to translate the below host addresses in
   sourcefile + linenr ?
On linux, the host stacktrace is symbolic. No idea why on MacOS it is
not the case. I guess MacOS has a tool that can translate these
addresses, which are in the memcheck executable so something like
    memcheck-amd64-darwin.
(or I suppose gdb will be able to translate these addresses)


> Memcheck: mc_leakcheck.c:1106 (void lc_scan_memory(Addr, SizeT, Bool,
> Int, Int, Addr, SizeT)): Assertion 'bad_scanned_addr >=
> VG_ROUNDUP(start, sizeof(Addr))' failed.
> 
> host stacktrace:
> ==59226==    at 0x23804F24E: ???
> ==59226==    by 0x23804F66C: ???
> ==59226==    by 0x23804F64A: ???
> ==59226==    by 0x238003953: ???
> ==59226==    by 0x238003135: ???
> ==59226==    by 0x238001D17: ???
> ==59226==    by 0x23801482D: ???
> ==59226==    by 0x23805C0F2: ???
> ==59226==    by 0x2380EE752: ???


The best is to attach all the produced output/log files to the bug
349128.


Thanks 

Philippe

[Valgrind-users] Segfault, Assertion 'bad_scanned_addr >= VG_ROUNDUP (MPI / pthread program)

[Jim <jps...@gm...>]

Hi, I'm using valgrind to debug some memory issues in a parallel
runtime system and program that uses both MPI and C++11 threads. I am
hitting an issue that, I believe, is the same as Valgrind Bug 349128
(https://bugs.kde.org/show_bug.cgi?id=349128). However, I upgraded to
valgrind-3.12.0.SVN, which I was hoping would fix the issue as per
philippe's commit r15716 in October. Despite running the latest from
svn, I'm still hitting this bug. It's quite possible, though, that I'm
hitting a different bug (either mine or Valgrind's). So, I'm writing
in to see if anyone can help me out with this issue.

Overview: I'm building a new parallel runtime system, and the valgrind
error (segfault -- details below) shows up when the threads are done
running (almost) and are joining back to the parent thread. I'm able
to run many different other tests using my runtime system on valgrind
without this error (and, memcheck doesn't detect any issues with my
runtime system -- the valgrind logs are empty except for the
metadata). However, it's quite possible that there are some memory
issues in my program that the other tests are not detecting.

I can't easily post my source code, as it's hundreds of files, but
here's the basic structure of the test that is failing:

* system: OSX 10.11
* Valgrind valgrind-3.12.0.SVN
* compiler:
  * Configured with:
--prefix=/Applications/Xcode.app/Contents/Developer/usr
--with-gxx-include-dir=/usr/include/c++/4.2.1
  * Apple LLVM version 7.0.0 (clang-700.0.72)
  * Target: x86_64-apple-darwin15.0.0
  * Thread model: posix
* 2 MPI processes
* 4 C++11 threads per MPI process (8 threads total)
* each process forks 4 threads with a very minimal function. function
runs and returns.
* threads go to join back to the main thread, and somewhere in
_pthread_join_cleanup (in /usr/lib/system/libsystem_pthread.dylib)
* program runs to completion *without segfault* when I don't run using
valgrind. segfault only arises when I run with valgrind.
* I'm running valgrind on both MPI processes and get valgrind output
for both of the processes. Both processes die with the same error
(segfault on _pthread_join_cleanup)
* valgrind log below

I'd appreciate any input on helping me track this error down. Is this
a problem with valgrind, or with my program? Please let me know if
there's more information I should post.

Thank you!

Jim



Here's the valgrind log:

==59226== Memcheck, a memory error detector
==59226== Copyright (C) 2002-2015, and GNU GPL'd, by Julian Seward et al.
==59226== Using Valgrind-3.12.0.SVN and LibVEX; rerun with -h for copyright info
==59226== Command: specific_bundle_test 1
==59226== Parent PID: 59224
==59226==
--59226--
--59226-- Valgrind options:
--59226--    -v
--59226--    --trace-children=yes
--59226--    --log-file=valgrind/memcheck-%p.valgrind
--59226--    --tool=memcheck
--59226--    --leak-check=yes
--59226--    --dsymutil=yes
--59226--    --extra-debuginfo-path=/Users/jim/Documents/Research/projects/hybrid_programming/pure/test/../lib
--59226-- Output from sysctl({CTL_KERN,KERN_VERSION}):
--59226--   Darwin Kernel Version 15.0.0: Wed Aug 26 16:57:32 PDT
2015; root:xnu-3247.1.106~1/RELEASE_X86_64
--59226-- Arch and hwcaps: AMD64, LittleEndian, amd64-cx16-rdtscp-sse3
--59226-- Page sizes: currently 4096, max supported 4096
--59226-- Valgrind library directory: /Users/jim/local/lib/valgrind
--59226-- ./specific_bundle_test (rx at 0x100000000, rw at 0x1000ca000)
--59226--    reading syms   from primary file (583 6949)
--59226--    dSYM=
./specific_bundle_test.dSYM/Contents/Resources/DWARF/specific_bundle_test
--59226--    reading dwarf3 from dsyms file
--59226-- /usr/lib/dyld (rx at 0x7fff5fc00000, rw at 0x7fff5fc37000)
--59226--    reading syms   from primary file (6 1226)
--59226-- Scheduler: using generic scheduler lock implementation.
--59226-- Reading suppressions file: /Users/jim/local/lib/valgrind/default.supp
==59226== embedded gdbserver: reading from
/var/folders/c1/vxvr6h9x10b8dbsxhh6nx05h0000gn/T//vgdb-pipe-from-vgdb-to-59226-by-jim-on-???
==59226== embedded gdbserver: writing to
/var/folders/c1/vxvr6h9x10b8dbsxhh6nx05h0000gn/T//vgdb-pipe-to-vgdb-from-59226-by-jim-on-???
==59226== embedded gdbserver: shared mem
/var/folders/c1/vxvr6h9x10b8dbsxhh6nx05h0000gn/T//vgdb-pipe-shared-mem-vgdb-59226-by-jim-on-???
==59226==
==59226== TO CONTROL THIS PROCESS USING vgdb (which you probably
==59226== don't want to do, unless you know exactly what you're doing,
==59226== or are doing some strange experiment):
==59226==   /Users/jim/local/lib/valgrind/../../bin/vgdb --pid=59226
...command...
==59226==
==59226== TO DEBUG THIS PROCESS USING GDB: start GDB like this
==59226==   /path/to/gdb specific_bundle_test
==59226== and then give GDB the following command
==59226==   target remote |
/Users/jim/local/lib/valgrind/../../bin/vgdb --pid=59226
==59226== --pid is optional if only one valgrind process is running
==59226==
--59226-- REDIR: 0x7fff5fc1e5b9 (dyld:arc4random) redirected to
0x23806e30e (???)
--59226-- REDIR: 0x7fff5fc24780 (dyld:strcmp) redirected to 0x23806e270 (???)
--59226-- REDIR: 0x7fff5fc1e380 (dyld:strlen) redirected to 0x23806e23f (???)
--59226-- REDIR: 0x7fff5fc1e2e0 (dyld:strcpy) redirected to 0x23806e28c (???)
--59226-- REDIR: 0x7fff5fc21cdf (dyld:strcat) redirected to 0x23806e250 (???)
--59226-- REDIR: 0x7fff5fc21d1f (dyld:strlcat) redirected to 0x23806e2a9 (???)
--59226-- /Users/jim/local/lib/valgrind/vgpreload_core-amd64-darwin.so
(rx at 0x100139000, rw at 0x10013b000)
--59226--    reading syms   from primary file (3 42)
--59226--    dSYM=
/Users/jim/local/lib/valgrind/vgpreload_core-amd64-darwin.so.dSYM/Contents/Resources/DWARF/vgpreload_core-amd64-darwin.so
--59226--    reading dwarf3 from dsyms file
--59226-- /Users/jim/local/lib/valgrind/vgpreload_memcheck-amd64-darwin.so
(rx at 0x10013d000, rw at 0x100143000)
--59226--    reading syms   from primary file (72 356)
--59226--    dSYM=
/Users/jim/local/lib/valgrind/vgpreload_memcheck-amd64-darwin.so.dSYM/Contents/Resources/DWARF/vgpreload_memcheck-amd64-darwin.so
--59226--    reading dwarf3 from dsyms file
--59226-- /usr/local/Cellar/mpich/3.1.4_1/lib/libmpi.12.dylib (rx at
0x100148000, rw at 0x100220000)
--59226--    reading syms   from primary file (595 736)
--59226-- /usr/lib/libSystem.B.dylib (rx at 0x100241000, rw at 0x100243000)
--59226--    reading syms   from primary file (31 5)
--59226-- /usr/local/Cellar/mpich/3.1.4_1/lib/libmpicxx.12.dylib (rx
at 0x100248000, rw at 0x100251000)
--59226--    reading syms   from primary file (329 285)
--59226-- /usr/local/Cellar/mpich/3.1.4_1/lib/libpmpi.12.dylib (rx at
0x100262000, rw at 0x100463000)
--59226--    reading syms   from primary file (2070 4514)
--59226-- /usr/lib/libc++.1.dylib (rx at 0x100506000, rw at 0x10055a000)
--59226--    reading syms   from primary file (1960 1590)
--59226-- /usr/local/Cellar/gcc/5.2.0/lib/gcc/5/libgfortran.3.dylib
(rx at 0x1005b6000, rw at 0x1006d0000)
--59226--    reading syms   from primary file (1327 10741)
--59226-- /usr/local/Cellar/gcc/5.2.0/lib/gcc/5/libgcc_s.1.dylib (rx
at 0x10073a000, rw at 0x100750000)
--59226--    reading syms   from primary file (159 1046)
--59226-- /usr/local/Cellar/gcc/5.2.0/lib/gcc/5/libquadmath.0.dylib
(rx at 0x10075a000, rw at 0x100792000)
--59226--    reading syms   from primary file (98 1394)
--59226-- /usr/lib/system/libcache.dylib (rx at 0x1007a0000, rw at 0x1007a5000)
--59226--    reading syms   from primary file (32 30)
--59226-- /usr/lib/system/libcommonCrypto.dylib (rx at 0x1007aa000, rw
at 0x1007b6000)
--59226--    reading syms   from primary file (214 188)
--59226-- /usr/lib/system/libcompiler_rt.dylib (rx at 0x1007c3000, rw
at 0x1007cb000)
--59226--    reading syms   from primary file (510 8)
--59226-- /usr/lib/system/libcopyfile.dylib (rx at 0x1007d8000, rw at
0x1007e1000)
--59226--    reading syms   from primary file (13 35)
--59226-- /usr/lib/system/libcorecrypto.dylib (rx at 0x1007e7000, rw
at 0x10085f000)
--59226--    reading syms   from primary file (428 602)
--59226-- /usr/lib/system/libdispatch.dylib (rx at 0x100877000, rw at
0x1008a5000)
--59226--    reading syms   from primary file (215 832)
--59226-- /usr/lib/system/libdyld.dylib (rx at 0x1008ce000, rw at 0x1008d2000)
--59226--    reading syms   from primary file (80 109)
--59226-- /usr/lib/system/libkeymgr.dylib (rx at 0x1008d9000, rw at 0x1008da000)
--59226--    reading syms   from primary file (12 3)
--59226-- /usr/lib/system/libmacho.dylib (rx at 0x1008e5000, rw at 0x1008eb000)
--59226--    reading syms   from primary file (97 1)
--59226-- /usr/lib/system/libquarantine.dylib (rx at 0x1008f1000, rw
at 0x1008f4000)
--59226--    reading syms   from primary file (67 32)
--59226-- /usr/lib/system/libremovefile.dylib (rx at 0x1008fa000, rw
at 0x1008fc000)
--59226--    reading syms   from primary file (15 4)
--59226-- /usr/lib/system/libsystem_asl.dylib (rx at 0x100901000, rw
at 0x100919000)
--59226--    reading syms   from primary file (222 225)
--59226-- /usr/lib/system/libsystem_blocks.dylib (rx at 0x100926000,
rw at 0x100928000)
--59226--    reading syms   from primary file (25 22)
--59226-- /usr/lib/system/libsystem_c.dylib (rx at 0x10092c000, rw at
0x1009ba000)
--59226--    reading syms   from primary file (1308 746)
--59226-- /usr/lib/system/libsystem_configuration.dylib (rx at
0x1009e5000, rw at 0x1009e8000)
--59226--    reading syms   from primary file (28 58)
--59226-- /usr/lib/system/libsystem_coreservices.dylib (rx at
0x1009ee000, rw at 0x1009f1000)
--59226--    reading syms   from primary file (13 30)
--59226-- /usr/lib/system/libsystem_coretls.dylib (rx at 0x1009f6000,
rw at 0x100a0b000)
--59226--    reading syms   from primary file (115 241)
--59226-- /usr/lib/system/libsystem_dnssd.dylib (rx at 0x100a14000, rw
at 0x100a1d000)
--59226--    reading syms   from primary file (68 33)
--59226-- /usr/lib/system/libsystem_info.dylib (rx at 0x100a23000, rw
at 0x100a4d000)
--59226--    reading syms   from primary file (526 527)
--59226-- /usr/lib/system/libsystem_kernel.dylib (rx at 0x100a62000,
rw at 0x100a81000)
--59226--    reading syms   from primary file (1046 83)
--59226-- /usr/lib/system/libsystem_m.dylib (rx at 0x100a96000, rw at
0x100ac6000)
--59226--    reading syms   from primary file (593 1)
--59226-- /usr/lib/system/libsystem_malloc.dylib (rx at 0x100ad2000,
rw at 0x100aef000)
--59226--    reading syms   from primary file (102 201)
--59226-- /usr/lib/system/libsystem_network.dylib (rx at 0x100af8000,
rw at 0x100b57000)
--59226--    reading syms   from primary file (664 1939)
--59226-- /usr/lib/system/libsystem_networkextension.dylib (rx at
0x100b8c000, rw at 0x100b95000)
--59226--    reading syms   from primary file (82 235)
--59226-- /usr/lib/system/libsystem_notify.dylib (rx at 0x100ba0000,
rw at 0x100baa000)
--59226--    reading syms   from primary file (136 53)
--59226-- /usr/lib/system/libsystem_platform.dylib (rx at 0x100bb2000,
rw at 0x100bbb000)
--59226--    reading syms   from primary file (142 158)
--59226-- /usr/lib/system/libsystem_pthread.dylib (rx at 0x100bc3000,
rw at 0x100bcd000)
--59226--    reading syms   from primary file (163 70)
--59226-- /usr/lib/system/libsystem_sandbox.dylib (rx at 0x100bda000,
rw at 0x100bde000)
--59226--    reading syms   from primary file (79 7)
--59226-- /usr/lib/system/libsystem_secinit.dylib (rx at 0x100be4000,
rw at 0x100be6000)
--59226--    reading syms   from primary file (3 6)
--59226-- /usr/lib/system/libsystem_trace.dylib (rx at 0x100beb000, rw
at 0x100bfd000)
--59226--    reading syms   from primary file (94 351)
--59226-- /usr/lib/system/libunwind.dylib (rx at 0x100c0f000, rw at 0x100c15000)
--59226--    reading syms   from primary file (102 52)
--59226-- /usr/lib/system/libxpc.dylib (rx at 0x100c1c000, rw at 0x100c46000)
--59226--    reading syms   from primary file (503 833)
--59226-- /usr/lib/libobjc.A.dylib (rx at 0x100c64000, rw at 0x100fcf000)
--59226--    reading syms   from primary file (347 935)
--59226-- /usr/lib/libauto.dylib (rx at 0x1010af000, rw at 0x1010f6000)
--59226--    reading syms   from primary file (68 658)
--59226-- /usr/lib/libc++abi.dylib (rx at 0x10110b000, rw at 0x101135000)
--59226--    reading syms   from primary file (337 181)
--59226-- /usr/lib/libDiagnosticMessagesClient.dylib (rx at
0x101143000, rw at 0x101145000)
--59226--    reading syms   from primary file (21 14)
--59226-- REDIR: 0x100bb2ac0
(libsystem_platform.dylib:_platform_memchr$VARIANT$Generic) redirected
to 0x100140910 (_platform_memchr$VARIANT$Generic)
--59226-- REDIR: 0x100bb2c80
(libsystem_platform.dylib:_platform_memcmp) redirected to 0x100140f10
(_platform_memcmp)
--59226-- REDIR: 0x100bb3220
(libsystem_platform.dylib:_platform_strncmp) redirected to 0x1001407b0
(_platform_strncmp)
--59226-- REDIR: 0x100ad30b2 (libsystem_malloc.dylib:malloc)
redirected to 0x10013de00 (malloc)
--59226-- REDIR: 0x10092cd20 (libsystem_c.dylib:strlen) redirected to
0x100140340 (strlen)
--59226-- REDIR: 0x100bb3800
(libsystem_platform.dylib:_platform_strcmp) redirected to 0x100140870
(_platform_strcmp)
--59226-- REDIR: 0x100ad5ea8 (libsystem_malloc.dylib:free) redirected
to 0x10013e3b0 (free)
--59226-- REDIR: 0x100ad8441 (libsystem_malloc.dylib:calloc)
redirected to 0x10013e790 (calloc)
--59226-- REDIR: 0x100ad7949
(libsystem_malloc.dylib:malloc_default_zone) redirected to 0x10013fde0
(malloc_default_zone)
--59226-- REDIR: 0x100ad456a
(libsystem_malloc.dylib:malloc_zone_malloc) redirected to 0x10013e170
(malloc_zone_malloc)
--59226-- REDIR: 0x100ad7968
(libsystem_malloc.dylib:malloc_zone_calloc) redirected to 0x10013ea50
(malloc_zone_calloc)
--59226-- REDIR: 0x100ad7a22
(libsystem_malloc.dylib:malloc_zone_from_ptr) redirected to
0x10013fe30 (malloc_zone_from_ptr)
--59226-- REDIR: 0x100bb3380
(libsystem_platform.dylib:_platform_strchr$VARIANT$Generic) redirected
to 0x100140190 (_platform_strchr$VARIANT$Generic)
--59226-- REDIR: 0x100ad8644 (libsystem_malloc.dylib:realloc)
redirected to 0x10013ecb0 (realloc)
--59226-- REDIR: 0x100ada9f0
(libsystem_malloc.dylib:malloc_zone_memalign) redirected to
0x10013f7f0 (malloc_zone_memalign)
--59226-- REDIR: 0x10092cd80 (libsystem_c.dylib:strncpy) redirected to
0x100140540 (strncpy)
--59226-- UNKNOWN mach_msg unhandled MACH_SEND_TRAILER option
--59226-- UNKNOWN mach_msg unhandled MACH_SEND_TRAILER option (repeated 2 times)
--59226-- UNKNOWN mach_msg unhandled MACH_SEND_TRAILER option (repeated 4 times)
--59226-- UNKNOWN mach_msg unhandled MACH_SEND_TRAILER option (repeated 8 times)
==59226==
==59226== Process terminating with default action of signal 11 (SIGSEGV)
==59226==  Access not within mapped region at address 0x7000036B2C1C
==59226==    at 0x100BC8873: _pthread_join_cleanup (in
/usr/lib/system/libsystem_pthread.dylib)
==59226==    by 0x100BC87D7: pthread_join (in
/usr/lib/system/libsystem_pthread.dylib)
==59226==    by 0x10054BE94: std::__1::thread::join() (in
/usr/lib/libc++.1.dylib)
==59226==    by 0x1000A76DE: PureProcess::RunPureThreads(int, char**)
(pure_process.cpp:128)
==59226==    by 0x1000B63AC: PureRT::Pure::Run(int, char**) (pure.cpp:53)
==59226==    by 0x1000B6431: main (pure.cpp:62)
==59226==  If you believe this happened as a result of a stack
==59226==  overflow in your program's main thread (unlikely but
==59226==  possible), you can try to increase the size of the
==59226==  main thread stack using the --main-stacksize= flag.
==59226==  The main thread stack size used in this run was 8388608.
==59226==
==59226== HEAP SUMMARY:
==59226==     in use at exit: 112,031 bytes in 651 blocks
==59226==   total heap usage: 875 allocs, 224 frees, 178,835 bytes allocated
==59226==
==59226== Searching for pointers to 651 not-freed blocks

Memcheck: mc_leakcheck.c:1106 (void lc_scan_memory(Addr, SizeT, Bool,
Int, Int, Addr, SizeT)): Assertion 'bad_scanned_addr >=
VG_ROUNDUP(start, sizeof(Addr))' failed.

host stacktrace:
==59226==    at 0x23804F24E: ???
==59226==    by 0x23804F66C: ???
==59226==    by 0x23804F64A: ???
==59226==    by 0x238003953: ???
==59226==    by 0x238003135: ???
==59226==    by 0x238001D17: ???
==59226==    by 0x23801482D: ???
==59226==    by 0x23805C0F2: ???
==59226==    by 0x2380EE752: ???

sched status:
  running_tid=1


Note: see also the FAQ in the source distribution.
It contains workarounds to several common problems.
In particular, if Valgrind aborted or crashed after
identifying problems in your program, there's a good chance
that fixing those problems will prevent Valgrind aborting or
crashing, especially if it happened in m_mallocfree.c.

If that doesn't help, please report this bug to: www.valgrind.org

In the bug report, send all the above text, the valgrind
version, and what OS and version you are using.  Thanks.

Re: [Valgrind-users] why miss rate decrease but number of misses increase in ubuntu 12 in vmware player 12 ?

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

Am 16.02.2016 um 09:36 schrieb Mandy Martino:
> Hi,
> 
> when no -O2 or -O3
> the blocking version has 166 million data access , original version without blocking it has 10 million data access. 
> 
> After run with gcc -O3 -o mar5ti mar5ti.c,
> 
> 1.there are nearly no difference in the result. Why no difference?

No idea. You have to dig deeper.
You can see a split-up using cg_annotate or the q/kcachegrind GUI.
If you use callgrind, you can get annotation on the machine instruction
level (--dump-instr=yes).
But I would imagine that your workload/data is too small, and
perhaps the numbers are dominated by startup stuff which has
nothing to do with your code. You do not show initialization of
the used arrays. If you really do not initialize, your benchmark
is screwed.

> 2. does it mean that compiler has already done cache optimization? no need to consider cache optimization in c language programming any more nowadays?

Some compilers try to be smart, but usually they cannot do much
as the data sizes are not known at compile time. You could compare
the resulting machine code.

Cheers,
Josef

> 
> #define min(a,b) (((a)<(b))?(a):(b))
> #define max(a,b) (((a)>(b))?(a):(b))
> int main()
> {
>  int x[100][100];
>  int y[100][100];
>  int z[100][100];
>  int i=0;
>  int j=0;
>  int k=0;
>  int N=100;
>  int r=0;
>  int jj=0;
>  int kk=0;
>  int B = 5;
> /*
>  for(i=0;i<N;++i)
>  {
>   for(j=0;j<N;++j)
>   {
>    r=0;
>    for(k=0;k<N;++k)
>    {
>      r=r+y[i][k]*z[k][j];
>    }
>    x[i][j]=r;
>   }
>  }
> */
>  for(jj=0;jj<N;jj=jj+B)
>  for(kk=0;kk<N;kk=kk+B)
>  for(i=0;i<N;++i)
>  {
>   for(j=0;j<min(jj+B,N);++j)
>   {
>    r=0;
>    for(k=kk;k<min(kk+B,N);++k)
>    {
>      r=r+y[i][k]*z[k][j];
>    }
>    x[i][j]=x[i][j]+r;
>   }
>  }
> 
>  return 0;
> }
> /*
>  for(i=0;i<N;++i)
>  {
>   for(j=0;j<N;++j)
>   {
>    r=0;
>    for(k=0;k<N;++k)
>    {
>      r=r+y[i][k]*z[k][j];
>    }
>    x[i][j]=r;
>   }
>  }
> martin@ubuntu:~$ valgrind --tool=cachegrind ./mar5ti
> ==2934== Cachegrind, a cache and branch-prediction profiler
> ==2934== Copyright (C) 2002-2011, and GNU GPL'd, by Nicholas Nethercote et al.
> ==2934== Using Valgrind-3.7.0 and LibVEX; rerun with -h for copyright info
> ==2934== Command: ./mar5ti
> ==2934== 
> --2934-- warning: L3 cache found, using its data for the LL simulation.
> ==2934== 
> ==2934== I   refs:      113,272
> ==2934== I1  misses:        686
> ==2934== LLi misses:        681
> ==2934== I1  miss rate:    0.60%
> ==2934== LLi miss rate:    0.60%
> ==2934== 
> ==2934== D   refs:       52,724  (37,442 rd   + 15,282 wr)
> ==2934== D1  misses:      1,075  (   930 rd   +    145 wr)
> ==2934== LLd misses:        982  (   847 rd   +    135 wr)
> ==2934== D1  miss rate:     2.0% (   2.4%     +    0.9%  )
> ==2934== LLd miss rate:     1.8% (   2.2%     +    0.8%  )
> ==2934== 
> ==2934== LL refs:         1,761  ( 1,616 rd   +    145 wr)
> ==2934== LL misses:       1,663  ( 1,528 rd   +    135 wr)
> ==2934== LL miss rate:      1.0% (   1.0%     +    0.8%  )
> 
>  for(jj=0;jj<N;jj=jj+B)
>  for(kk=0;kk<N;kk=kk+B)
>  for(i=0;i<N;++i)
>  {
>   for(j=0;j<min(jj+B,N);++j)
>   {
>    r=0;
>    for(k=kk;k<min(kk+B,N);++k)
>    {
>      r=r+y[i][k]*z[k][j];
>    }
>    x[i][j]=x[i][j]+r;
>   }
>  }
> 
> martin@ubuntu:~$ valgrind --tool=cachegrind ./mar5ti
> ==3047== Cachegrind, a cache and branch-prediction profiler
> ==3047== Copyright (C) 2002-2011, and GNU GPL'd, by Nicholas Nethercote et al.
> ==3047== Using Valgrind-3.7.0 and LibVEX; rerun with -h for copyright info
> ==3047== Command: ./mar5ti
> ==3047== 
> --3047-- warning: L3 cache found, using its data for the LL simulation.
> ==3047== 
> ==3047== I   refs:      113,268
> ==3047== I1  misses:        686
> ==3047== LLi misses:        681
> ==3047== I1  miss rate:    0.60%
> ==3047== LLi miss rate:    0.60%
> ==3047== 
> ==3047== D   refs:       52,724  (37,442 rd   + 15,282 wr)
> ==3047== D1  misses:      1,075  (   930 rd   +    145 wr)
> ==3047== LLd misses:        982  (   847 rd   +    135 wr)
> ==3047== D1  miss rate:     2.0% (   2.4%     +    0.9%  )
> ==3047== LLd miss rate:     1.8% (   2.2%     +    0.8%  )
> ==3047== 
> ==3047== LL refs:         1,761  ( 1,616 rd   +    145 wr)
> ==3047== LL misses:       1,663  ( 1,528 rd   +    135 wr)
> ==3047== LL miss rate:      1.0% (   1.0%     +    0.8%  )
> 
> */
> 
> Regards,
> 
> Martin
> 
> ________________________________________
> From: Josef Weidendorfer <Jos...@gm...>
> Sent: Tuesday, February 16, 2016 6:37
> To: val...@li...
> Subject: Re: [Valgrind-users] why miss rate decrease but number of misses increase in ubuntu 12 in vmware player 12 ?
> 
> Am 15.02.2016 um 11:25 schrieb Mandy Martino:
>> why
>>
>> I1 misses increase, LLi misses increase, LL misses increase, D1 misses
>> increase
>> though miss rate decrease at this row 0.1%     +       0.0% ?
>>
>> which indicator show the correct number that can show the improvement
>> after optimization?
> 
> I see you do blocking in the 2nd version. However, the number of data
> accesses is 166 million vs. 10 million in your 1st version. I assume
> this is because you did not compile with -O2 or -O3 ?
> 
> Miss rate is a relative number, based on total number of accesses.
> A comparison is meaningless if the number of accesses is so different.
> 
> Josef
> 
> 
>>
>>
>> #define min(a,b) (((a)<(b))?(a):(b))
>> #define max(a,b) (((a)>(b))?(a):(b))
>> int main()
>> {
>>  int x[100][100];
>>  int y[100][100];
>>  int z[100][100];
>>  int i=0;
>>  int j=0;
>>  int k=0;
>>  int N=100;
>>  int r=0;
>>  int jj=0;
>>  int kk=0;
>>  int B = 5;
>> /*
>>  for(i=0;i<N;++i)
>>  {
>>   for(j=0;j<N;++j)
>>   {
>>    r=0;
>>    for(k=0;k<N;++k)
>>    {
>>      r=r+y[i][k]*z[k][j];
>>    }
>>    x[i][j]=r;
>>   }
>>  }
>> */
>>  for(jj=0;jj<N;jj=jj+B)
>>  for(kk=0;kk<N;kk=kk+B)
>>  for(i=0;i<N;++i)
>>  {
>>   for(j=0;j<min(jj+B,N);++j)
>>   {
>>    r=0;
>>    for(k=kk;k<min(kk+B,N);++k)
>>    {
>>      r=r+y[i][k]*z[k][j];
>>    }
>>    x[i][j]=x[i][j]+r;
>>   }
>>  }
>>  return 0;
>> }
>> /*
>>  for(i=0;i<N;++i)
>>  {
>>   for(j=0;j<N;++j)
>>   {
>>    r=0;
>>    for(k=0;k<N;++k)
>>    {
>>      r=r+y[i][k]*z[k][j];
>>    }
>>    x[i][j]=r;
>>   }
>>  }
>>
>> martin@ubuntu:~$ valgrind --tool=cachegrind ./mar5ti
>> ==4602== Cachegrind, a cache and branch-prediction profiler
>> ==4602== Copyright (C) 2002-2011, and GNU GPL'd, by Nicholas Nethercote
>> et al.
>> ==4602== Using Valgrind-3.7.0 and LibVEX; rerun with -h for copyright info
>> ==4602== Command: ./mar5ti
>> ==4602==
>> --4602-- warning: L3 cache found, using its data for the LL simulation.
>> ==4602==
>> ==4602== I   refs:      14,264,184
>> ==4602== I1  misses:           689
>> ==4602== LLi misses:           684
>> ==4602== I1  miss rate:       0.00%
>> ==4602== LLi miss rate:       0.00%
>> ==4602==
>> ==4602== D   refs:      10,163,336  (10,117,945 rd   + 45,391 wr)
>> ==4602== D1  misses:        64,978  (    64,200 rd   +    778 wr)
>> ==4602== LLd misses:         2,823  (     2,063 rd   +    760 wr)
>> ==4602== D1  miss rate:        0.6% (       0.6%     +    1.7%  )
>> ==4602== LLd miss rate:        0.0% (       0.0%     +    1.6%  )
>> ==4602==
>> ==4602== LL refs:           65,667  (    64,889 rd   +    778 wr)
>> ==4602== LL misses:          3,507  (     2,747 rd   +    760 wr)
>> ==4602== LL miss rate:         0.0% (       0.0%     +    1.6%  )
>>
>>  for(jj=0;jj<N;jj=jj+B)
>>  for(kk=0;kk<N;kk=kk+B)
>>  for(i=0;i<N;++i)
>>  {
>>   for(j=0;j<min(jj+B,N);++j)
>>   {
>>    r=0;
>>    for(k=kk;k<min(kk+B,N);++k)
>>    {
>>      r=r+y[i][k]*z[k][j];
>>    }
>>    x[i][j]=x[i][j]+r;
>>   }
>>  }
>> martin@ubuntu:~$ valgrind --tool=cachegrind ./mar5ti
>> ==4654== Cachegrind, a cache and branch-prediction profiler
>> ==4654== Copyright (C) 2002-2011, and GNU GPL'd, by Nicholas Nethercote
>> et al.
>> ==4654== Using Valgrind-3.7.0 and LibVEX; rerun with -h for copyright info
>> ==4654== Command: ./mar5ti
>> ==4654==
>> --4654-- warning: L3 cache found, using its data for the LL simulation.
>> ==4654==
>> ==4654== I   refs:      265,277,487
>> ==4654== I1  misses:            690
>> ==4654== LLi misses:            685
>> ==4654== I1  miss rate:        0.00%
>> ==4654== LLi miss rate:        0.00%
>> ==4654==
>> ==4654== D   refs:      166,275,677  (159,919,965 rd   + 6,355,712 wr)
>> ==4654== D1  misses:        170,231  (    170,082 rd   +       149 wr)
>> ==4654== LLd misses:          2,823  (      2,688 rd   +       135 wr)
>> ==4654== D1  miss rate:         0.1% (        0.1%     +       0.0%  )
>> ==4654== LLd miss rate:         0.0% (        0.0%     +       0.0%  )
>> ==4654==
>> ==4654== LL refs:           170,921  (    170,772 rd   +       149 wr)
>> ==4654== LL misses:           3,508  (      3,373 rd   +       135 wr)
>> ==4654== LL miss rate:          0.0% (        0.0%     +       0.0%  )
>>
>> */
>>
>>
>> Regards,
>>
>>
>> Martin
>>
>>
>>
>> ------------------------------------------------------------------------------
>> Site24x7 APM Insight: Get Deep Visibility into Application Performance
>> APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
>> Monitor end-to-end web transactions and take corrective actions now
>> Troubleshoot faster and improve end-user experience. Signup Now!
>> http://pubads.g.doubleclick.net/gampad/clk?id=272487151&iu=/4140
>>
>>
>>
>> _______________________________________________
>> Valgrind-users mailing list
>> Val...@li...
>> https://lists.sourceforge.net/lists/listinfo/valgrind-users
>>
> 
> ------------------------------------------------------------------------------
> Site24x7 APM Insight: Get Deep Visibility into Application Performance
> APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
> Monitor end-to-end web transactions and take corrective actions now
> Troubleshoot faster and improve end-user experience. Signup Now!
> http://pubads.g.doubleclick.net/gampad/clk?id=272487151&iu=/4140
> _______________________________________________
> Valgrind-users mailing list
> Val...@li...
> https://lists.sourceforge.net/lists/listinfo/valgrind-users
> 

Re: [Valgrind-users] why miss rate decrease but number of misses increase in ubuntu 12 in vmware player 12 ?

[Mandy M. <te...@ho...>]

Hi,

when no -O2 or -O3
the blocking version has 166 million data access , original version without blocking it has 10 million data access. 

After run with gcc -O3 -o mar5ti mar5ti.c,

1.there are nearly no difference in the result. Why no difference?
2. does it mean that compiler has already done cache optimization? no need to consider cache optimization in c language programming any more nowadays?

#define min(a,b) (((a)<(b))?(a):(b))
#define max(a,b) (((a)>(b))?(a):(b))
int main()
{
 int x[100][100];
 int y[100][100];
 int z[100][100];
 int i=0;
 int j=0;
 int k=0;
 int N=100;
 int r=0;
 int jj=0;
 int kk=0;
 int B = 5;
/*
 for(i=0;i<N;++i)
 {
  for(j=0;j<N;++j)
  {
   r=0;
   for(k=0;k<N;++k)
   {
     r=r+y[i][k]*z[k][j];
   }
   x[i][j]=r;
  }
 }
*/
 for(jj=0;jj<N;jj=jj+B)
 for(kk=0;kk<N;kk=kk+B)
 for(i=0;i<N;++i)
 {
  for(j=0;j<min(jj+B,N);++j)
  {
   r=0;
   for(k=kk;k<min(kk+B,N);++k)
   {
     r=r+y[i][k]*z[k][j];
   }
   x[i][j]=x[i][j]+r;
  }
 }

 return 0;
}
/*
 for(i=0;i<N;++i)
 {
  for(j=0;j<N;++j)
  {
   r=0;
   for(k=0;k<N;++k)
   {
     r=r+y[i][k]*z[k][j];
   }
   x[i][j]=r;
  }
 }
martin@ubuntu:~$ valgrind --tool=cachegrind ./mar5ti
==2934== Cachegrind, a cache and branch-prediction profiler
==2934== Copyright (C) 2002-2011, and GNU GPL'd, by Nicholas Nethercote et al.
==2934== Using Valgrind-3.7.0 and LibVEX; rerun with -h for copyright info
==2934== Command: ./mar5ti
==2934== 
--2934-- warning: L3 cache found, using its data for the LL simulation.
==2934== 
==2934== I   refs:      113,272
==2934== I1  misses:        686
==2934== LLi misses:        681
==2934== I1  miss rate:    0.60%
==2934== LLi miss rate:    0.60%
==2934== 
==2934== D   refs:       52,724  (37,442 rd   + 15,282 wr)
==2934== D1  misses:      1,075  (   930 rd   +    145 wr)
==2934== LLd misses:        982  (   847 rd   +    135 wr)
==2934== D1  miss rate:     2.0% (   2.4%     +    0.9%  )
==2934== LLd miss rate:     1.8% (   2.2%     +    0.8%  )
==2934== 
==2934== LL refs:         1,761  ( 1,616 rd   +    145 wr)
==2934== LL misses:       1,663  ( 1,528 rd   +    135 wr)
==2934== LL miss rate:      1.0% (   1.0%     +    0.8%  )

 for(jj=0;jj<N;jj=jj+B)
 for(kk=0;kk<N;kk=kk+B)
 for(i=0;i<N;++i)
 {
  for(j=0;j<min(jj+B,N);++j)
  {
   r=0;
   for(k=kk;k<min(kk+B,N);++k)
   {
     r=r+y[i][k]*z[k][j];
   }
   x[i][j]=x[i][j]+r;
  }
 }

martin@ubuntu:~$ valgrind --tool=cachegrind ./mar5ti
==3047== Cachegrind, a cache and branch-prediction profiler
==3047== Copyright (C) 2002-2011, and GNU GPL'd, by Nicholas Nethercote et al.
==3047== Using Valgrind-3.7.0 and LibVEX; rerun with -h for copyright info
==3047== Command: ./mar5ti
==3047== 
--3047-- warning: L3 cache found, using its data for the LL simulation.
==3047== 
==3047== I   refs:      113,268
==3047== I1  misses:        686
==3047== LLi misses:        681
==3047== I1  miss rate:    0.60%
==3047== LLi miss rate:    0.60%
==3047== 
==3047== D   refs:       52,724  (37,442 rd   + 15,282 wr)
==3047== D1  misses:      1,075  (   930 rd   +    145 wr)
==3047== LLd misses:        982  (   847 rd   +    135 wr)
==3047== D1  miss rate:     2.0% (   2.4%     +    0.9%  )
==3047== LLd miss rate:     1.8% (   2.2%     +    0.8%  )
==3047== 
==3047== LL refs:         1,761  ( 1,616 rd   +    145 wr)
==3047== LL misses:       1,663  ( 1,528 rd   +    135 wr)
==3047== LL miss rate:      1.0% (   1.0%     +    0.8%  )

*/

Regards,

Martin

________________________________________
From: Josef Weidendorfer <Jos...@gm...>
Sent: Tuesday, February 16, 2016 6:37
To: val...@li...
Subject: Re: [Valgrind-users] why miss rate decrease but number of misses increase in ubuntu 12 in vmware player 12 ?

Am 15.02.2016 um 11:25 schrieb Mandy Martino:
> why
>
> I1 misses increase, LLi misses increase, LL misses increase, D1 misses
> increase
> though miss rate decrease at this row 0.1%     +       0.0% ?
>
> which indicator show the correct number that can show the improvement
> after optimization?

I see you do blocking in the 2nd version. However, the number of data
accesses is 166 million vs. 10 million in your 1st version. I assume
this is because you did not compile with -O2 or -O3 ?

Miss rate is a relative number, based on total number of accesses.
A comparison is meaningless if the number of accesses is so different.

Josef


>
>
> #define min(a,b) (((a)<(b))?(a):(b))
> #define max(a,b) (((a)>(b))?(a):(b))
> int main()
> {
>  int x[100][100];
>  int y[100][100];
>  int z[100][100];
>  int i=0;
>  int j=0;
>  int k=0;
>  int N=100;
>  int r=0;
>  int jj=0;
>  int kk=0;
>  int B = 5;
> /*
>  for(i=0;i<N;++i)
>  {
>   for(j=0;j<N;++j)
>   {
>    r=0;
>    for(k=0;k<N;++k)
>    {
>      r=r+y[i][k]*z[k][j];
>    }
>    x[i][j]=r;
>   }
>  }
> */
>  for(jj=0;jj<N;jj=jj+B)
>  for(kk=0;kk<N;kk=kk+B)
>  for(i=0;i<N;++i)
>  {
>   for(j=0;j<min(jj+B,N);++j)
>   {
>    r=0;
>    for(k=kk;k<min(kk+B,N);++k)
>    {
>      r=r+y[i][k]*z[k][j];
>    }
>    x[i][j]=x[i][j]+r;
>   }
>  }
>  return 0;
> }
> /*
>  for(i=0;i<N;++i)
>  {
>   for(j=0;j<N;++j)
>   {
>    r=0;
>    for(k=0;k<N;++k)
>    {
>      r=r+y[i][k]*z[k][j];
>    }
>    x[i][j]=r;
>   }
>  }
>
> martin@ubuntu:~$ valgrind --tool=cachegrind ./mar5ti
> ==4602== Cachegrind, a cache and branch-prediction profiler
> ==4602== Copyright (C) 2002-2011, and GNU GPL'd, by Nicholas Nethercote
> et al.
> ==4602== Using Valgrind-3.7.0 and LibVEX; rerun with -h for copyright info
> ==4602== Command: ./mar5ti
> ==4602==
> --4602-- warning: L3 cache found, using its data for the LL simulation.
> ==4602==
> ==4602== I   refs:      14,264,184
> ==4602== I1  misses:           689
> ==4602== LLi misses:           684
> ==4602== I1  miss rate:       0.00%
> ==4602== LLi miss rate:       0.00%
> ==4602==
> ==4602== D   refs:      10,163,336  (10,117,945 rd   + 45,391 wr)
> ==4602== D1  misses:        64,978  (    64,200 rd   +    778 wr)
> ==4602== LLd misses:         2,823  (     2,063 rd   +    760 wr)
> ==4602== D1  miss rate:        0.6% (       0.6%     +    1.7%  )
> ==4602== LLd miss rate:        0.0% (       0.0%     +    1.6%  )
> ==4602==
> ==4602== LL refs:           65,667  (    64,889 rd   +    778 wr)
> ==4602== LL misses:          3,507  (     2,747 rd   +    760 wr)
> ==4602== LL miss rate:         0.0% (       0.0%     +    1.6%  )
>
>  for(jj=0;jj<N;jj=jj+B)
>  for(kk=0;kk<N;kk=kk+B)
>  for(i=0;i<N;++i)
>  {
>   for(j=0;j<min(jj+B,N);++j)
>   {
>    r=0;
>    for(k=kk;k<min(kk+B,N);++k)
>    {
>      r=r+y[i][k]*z[k][j];
>    }
>    x[i][j]=x[i][j]+r;
>   }
>  }
> martin@ubuntu:~$ valgrind --tool=cachegrind ./mar5ti
> ==4654== Cachegrind, a cache and branch-prediction profiler
> ==4654== Copyright (C) 2002-2011, and GNU GPL'd, by Nicholas Nethercote
> et al.
> ==4654== Using Valgrind-3.7.0 and LibVEX; rerun with -h for copyright info
> ==4654== Command: ./mar5ti
> ==4654==
> --4654-- warning: L3 cache found, using its data for the LL simulation.
> ==4654==
> ==4654== I   refs:      265,277,487
> ==4654== I1  misses:            690
> ==4654== LLi misses:            685
> ==4654== I1  miss rate:        0.00%
> ==4654== LLi miss rate:        0.00%
> ==4654==
> ==4654== D   refs:      166,275,677  (159,919,965 rd   + 6,355,712 wr)
> ==4654== D1  misses:        170,231  (    170,082 rd   +       149 wr)
> ==4654== LLd misses:          2,823  (      2,688 rd   +       135 wr)
> ==4654== D1  miss rate:         0.1% (        0.1%     +       0.0%  )
> ==4654== LLd miss rate:         0.0% (        0.0%     +       0.0%  )
> ==4654==
> ==4654== LL refs:           170,921  (    170,772 rd   +       149 wr)
> ==4654== LL misses:           3,508  (      3,373 rd   +       135 wr)
> ==4654== LL miss rate:          0.0% (        0.0%     +       0.0%  )
>
> */
>
>
> Regards,
>
>
> Martin
>
>
>
> ------------------------------------------------------------------------------
> Site24x7 APM Insight: Get Deep Visibility into Application Performance
> APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
> Monitor end-to-end web transactions and take corrective actions now
> Troubleshoot faster and improve end-user experience. Signup Now!
> http://pubads.g.doubleclick.net/gampad/clk?id=272487151&iu=/4140
>
>
>
> _______________________________________________
> Valgrind-users mailing list
> Val...@li...
> https://lists.sourceforge.net/lists/listinfo/valgrind-users
>

------------------------------------------------------------------------------
Site24x7 APM Insight: Get Deep Visibility into Application Performance
APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
Monitor end-to-end web transactions and take corrective actions now
Troubleshoot faster and improve end-user experience. Signup Now!
http://pubads.g.doubleclick.net/gampad/clk?id=272487151&iu=/4140
_______________________________________________
Valgrind-users mailing list
Val...@li...
https://lists.sourceforge.net/lists/listinfo/valgrind-users

Re: [Valgrind-users] why miss rate decrease but number of misses increase in ubuntu 12 in vmware player 12 ?

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

Am 15.02.2016 um 11:25 schrieb Mandy Martino:
> why 
> 
> I1 misses increase, LLi misses increase, LL misses increase, D1 misses
> increase
> though miss rate decrease at this row 0.1%     +       0.0% ?
> 
> which indicator show the correct number that can show the improvement
> after optimization?

I see you do blocking in the 2nd version. However, the number of data
accesses is 166 million vs. 10 million in your 1st version. I assume
this is because you did not compile with -O2 or -O3 ?

Miss rate is a relative number, based on total number of accesses.
A comparison is meaningless if the number of accesses is so different.

Josef


> 
> 
> #define min(a,b) (((a)<(b))?(a):(b))
> #define max(a,b) (((a)>(b))?(a):(b))
> int main()
> {
>  int x[100][100];
>  int y[100][100];
>  int z[100][100];
>  int i=0;
>  int j=0;
>  int k=0;
>  int N=100;
>  int r=0;
>  int jj=0;
>  int kk=0;
>  int B = 5;
> /*
>  for(i=0;i<N;++i)
>  {
>   for(j=0;j<N;++j)
>   {
>    r=0;
>    for(k=0;k<N;++k)
>    {
>      r=r+y[i][k]*z[k][j];
>    }
>    x[i][j]=r;
>   }
>  }
> */
>  for(jj=0;jj<N;jj=jj+B)
>  for(kk=0;kk<N;kk=kk+B)
>  for(i=0;i<N;++i)
>  {
>   for(j=0;j<min(jj+B,N);++j)
>   {
>    r=0;
>    for(k=kk;k<min(kk+B,N);++k)
>    {
>      r=r+y[i][k]*z[k][j];
>    }
>    x[i][j]=x[i][j]+r;
>   }
>  }
>  return 0;
> }
> /*
>  for(i=0;i<N;++i)
>  {
>   for(j=0;j<N;++j)
>   {
>    r=0;
>    for(k=0;k<N;++k)
>    {
>      r=r+y[i][k]*z[k][j];
>    }
>    x[i][j]=r;
>   }
>  }
> 
> martin@ubuntu:~$ valgrind --tool=cachegrind ./mar5ti
> ==4602== Cachegrind, a cache and branch-prediction profiler
> ==4602== Copyright (C) 2002-2011, and GNU GPL'd, by Nicholas Nethercote
> et al.
> ==4602== Using Valgrind-3.7.0 and LibVEX; rerun with -h for copyright info
> ==4602== Command: ./mar5ti
> ==4602== 
> --4602-- warning: L3 cache found, using its data for the LL simulation.
> ==4602== 
> ==4602== I   refs:      14,264,184
> ==4602== I1  misses:           689
> ==4602== LLi misses:           684
> ==4602== I1  miss rate:       0.00%
> ==4602== LLi miss rate:       0.00%
> ==4602== 
> ==4602== D   refs:      10,163,336  (10,117,945 rd   + 45,391 wr)
> ==4602== D1  misses:        64,978  (    64,200 rd   +    778 wr)
> ==4602== LLd misses:         2,823  (     2,063 rd   +    760 wr)
> ==4602== D1  miss rate:        0.6% (       0.6%     +    1.7%  )
> ==4602== LLd miss rate:        0.0% (       0.0%     +    1.6%  )
> ==4602== 
> ==4602== LL refs:           65,667  (    64,889 rd   +    778 wr)
> ==4602== LL misses:          3,507  (     2,747 rd   +    760 wr)
> ==4602== LL miss rate:         0.0% (       0.0%     +    1.6%  )
> 
>  for(jj=0;jj<N;jj=jj+B)
>  for(kk=0;kk<N;kk=kk+B)
>  for(i=0;i<N;++i)
>  {
>   for(j=0;j<min(jj+B,N);++j)
>   {
>    r=0;
>    for(k=kk;k<min(kk+B,N);++k)
>    {
>      r=r+y[i][k]*z[k][j];
>    }
>    x[i][j]=x[i][j]+r;
>   }
>  }
> martin@ubuntu:~$ valgrind --tool=cachegrind ./mar5ti
> ==4654== Cachegrind, a cache and branch-prediction profiler
> ==4654== Copyright (C) 2002-2011, and GNU GPL'd, by Nicholas Nethercote
> et al.
> ==4654== Using Valgrind-3.7.0 and LibVEX; rerun with -h for copyright info
> ==4654== Command: ./mar5ti
> ==4654== 
> --4654-- warning: L3 cache found, using its data for the LL simulation.
> ==4654== 
> ==4654== I   refs:      265,277,487
> ==4654== I1  misses:            690
> ==4654== LLi misses:            685
> ==4654== I1  miss rate:        0.00%
> ==4654== LLi miss rate:        0.00%
> ==4654== 
> ==4654== D   refs:      166,275,677  (159,919,965 rd   + 6,355,712 wr)
> ==4654== D1  misses:        170,231  (    170,082 rd   +       149 wr)
> ==4654== LLd misses:          2,823  (      2,688 rd   +       135 wr)
> ==4654== D1  miss rate:         0.1% (        0.1%     +       0.0%  )
> ==4654== LLd miss rate:         0.0% (        0.0%     +       0.0%  )
> ==4654== 
> ==4654== LL refs:           170,921  (    170,772 rd   +       149 wr)
> ==4654== LL misses:           3,508  (      3,373 rd   +       135 wr)
> ==4654== LL miss rate:          0.0% (        0.0%     +       0.0%  )
> 
> */
> 
> 
> Regards,
> 
> 
> Martin
> 
> 
> 
> ------------------------------------------------------------------------------
> Site24x7 APM Insight: Get Deep Visibility into Application Performance
> APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
> Monitor end-to-end web transactions and take corrective actions now
> Troubleshoot faster and improve end-user experience. Signup Now!
> http://pubads.g.doubleclick.net/gampad/clk?id=272487151&iu=/4140
> 
> 
> 
> _______________________________________________
> Valgrind-users mailing list
> Val...@li...
> https://lists.sourceforge.net/lists/listinfo/valgrind-users
> 

[Valgrind-users] why miss rate decrease but number of misses increase in ubuntu 12 in vmware player 12 ?

[Mandy M. <te...@ho...>]

Hi,


why

I1 misses increase, LLi misses increase, LL misses increase, D1 misses increase
though miss rate decrease at this row 0.1%     +       0.0% ?

which indicator show the correct number that can show the improvement after optimization?


#define min(a,b) (((a)<(b))?(a):(b))
#define max(a,b) (((a)>(b))?(a):(b))
int main()
{
 int x[100][100];
 int y[100][100];
 int z[100][100];
 int i=0;
 int j=0;
 int k=0;
 int N=100;
 int r=0;
 int jj=0;
 int kk=0;
 int B = 5;
/*
 for(i=0;i<N;++i)
 {
  for(j=0;j<N;++j)
  {
   r=0;
   for(k=0;k<N;++k)
   {
     r=r+y[i][k]*z[k][j];
   }
   x[i][j]=r;
  }
 }
*/
 for(jj=0;jj<N;jj=jj+B)
 for(kk=0;kk<N;kk=kk+B)
 for(i=0;i<N;++i)
 {
  for(j=0;j<min(jj+B,N);++j)
  {
   r=0;
   for(k=kk;k<min(kk+B,N);++k)
   {
     r=r+y[i][k]*z[k][j];
   }
   x[i][j]=x[i][j]+r;
  }
 }
 return 0;
}
/*
 for(i=0;i<N;++i)
 {
  for(j=0;j<N;++j)
  {
   r=0;
   for(k=0;k<N;++k)
   {
     r=r+y[i][k]*z[k][j];
   }
   x[i][j]=r;
  }
 }

martin@ubuntu:~$ valgrind --tool=cachegrind ./mar5ti
==4602== Cachegrind, a cache and branch-prediction profiler
==4602== Copyright (C) 2002-2011, and GNU GPL'd, by Nicholas Nethercote et al.
==4602== Using Valgrind-3.7.0 and LibVEX; rerun with -h for copyright info
==4602== Command: ./mar5ti
==4602==
--4602-- warning: L3 cache found, using its data for the LL simulation.
==4602==
==4602== I   refs:      14,264,184
==4602== I1  misses:           689
==4602== LLi misses:           684
==4602== I1  miss rate:       0.00%
==4602== LLi miss rate:       0.00%
==4602==
==4602== D   refs:      10,163,336  (10,117,945 rd   + 45,391 wr)
==4602== D1  misses:        64,978  (    64,200 rd   +    778 wr)
==4602== LLd misses:         2,823  (     2,063 rd   +    760 wr)
==4602== D1  miss rate:        0.6% (       0.6%     +    1.7%  )
==4602== LLd miss rate:        0.0% (       0.0%     +    1.6%  )
==4602==
==4602== LL refs:           65,667  (    64,889 rd   +    778 wr)
==4602== LL misses:          3,507  (     2,747 rd   +    760 wr)
==4602== LL miss rate:         0.0% (       0.0%     +    1.6%  )

 for(jj=0;jj<N;jj=jj+B)
 for(kk=0;kk<N;kk=kk+B)
 for(i=0;i<N;++i)
 {
  for(j=0;j<min(jj+B,N);++j)
  {
   r=0;
   for(k=kk;k<min(kk+B,N);++k)
   {
     r=r+y[i][k]*z[k][j];
   }
   x[i][j]=x[i][j]+r;
  }
 }
martin@ubuntu:~$ valgrind --tool=cachegrind ./mar5ti
==4654== Cachegrind, a cache and branch-prediction profiler
==4654== Copyright (C) 2002-2011, and GNU GPL'd, by Nicholas Nethercote et al.
==4654== Using Valgrind-3.7.0 and LibVEX; rerun with -h for copyright info
==4654== Command: ./mar5ti
==4654==
--4654-- warning: L3 cache found, using its data for the LL simulation.
==4654==
==4654== I   refs:      265,277,487
==4654== I1  misses:            690
==4654== LLi misses:            685
==4654== I1  miss rate:        0.00%
==4654== LLi miss rate:        0.00%
==4654==
==4654== D   refs:      166,275,677  (159,919,965 rd   + 6,355,712 wr)
==4654== D1  misses:        170,231  (    170,082 rd   +       149 wr)
==4654== LLd misses:          2,823  (      2,688 rd   +       135 wr)
==4654== D1  miss rate:         0.1% (        0.1%     +       0.0%  )
==4654== LLd miss rate:         0.0% (        0.0%     +       0.0%  )
==4654==
==4654== LL refs:           170,921  (    170,772 rd   +       149 wr)
==4654== LL misses:           3,508  (      3,373 rd   +       135 wr)
==4654== LL miss rate:          0.0% (        0.0%     +       0.0%  )

*/



Regards,


Martin

[Valgrind-users] why number of cache miss do not decrease after optimize in ubuntu 12 in VMware player 12?

[Mandy M. <te...@ho...>]

Hi ,


/*
gcc -o marti marti.c
valgrind --tool=cachegrind ./marti
valgrind --dsymutil=yes --tool=callgrind ./marti
*/
int main()
{
 int x[5000][100];
 int i = 0;
 int j = 0;
 for(i = 0; i <5000; ++i)
 {
   for (j = 0; j < 100; ++j)
   {
    x[i][j] = 2*x[i][j];
   }
 }
 return 0;
}
/*
Ubuntu 12 in VMware player 12

 for (j = 0; j < 100; ++j)
 {
 for(i = 0; i <5000; ++i)
   {
    x[i][j] = 2*x[i][j];
   }
 }

==4526== Cachegrind, a cache and branch-prediction profiler
==4526== Copyright (C) 2002-2011, and GNU GPL'd, by Nicholas Nethercote et al.
==4526== Using Valgrind-3.7.0 and LibVEX; rerun with -h for copyright info
==4526== Command: ./marti
==4526==
--4526-- warning: L3 cache found, using its data for the LL simulation.
==4526==
==4526== I   refs:      6,113,976
==4526== I1  misses:          687
==4526== LLi misses:          682
==4526== I1  miss rate:      0.01%
==4526== LLi miss rate:      0.01%
==4526==
==4526== D   refs:      4,053,131  (3,537,745 rd   + 515,386 wr)
==4526== D1  misses:      501,148  (  500,988 rd   +     160 wr)
==4526== LLd misses:       32,197  (   32,062 rd   +     135 wr)
==4526== D1  miss rate:      12.3% (     14.1%     +     0.0%  )
==4526== LLd miss rate:       0.7% (      0.9%     +     0.0%  )
==4526==
==4526== LL refs:         501,835  (  501,675 rd   +     160 wr)
==4526== LL misses:        32,879  (   32,744 rd   +     135 wr)
==4526== LL miss rate:        0.3% (      0.3%     +     0.0%  )

 for(i = 0; i <5000; ++i)
 {
   for (j = 0; j < 100; ++j)
   {
    x[i][j] = 2*x[i][j];
   }
 }
==4539== Cachegrind, a cache and branch-prediction profiler
==4539== Copyright (C) 2002-2011, and GNU GPL'd, by Nicholas Nethercote et al.
==4539== Using Valgrind-3.7.0 and LibVEX; rerun with -h for copyright info
==4539== Command: ./marti
==4539==
--4539-- warning: L3 cache found, using its data for the LL simulation.
==4539==
==4539== I   refs:      6,148,278
==4539== I1  misses:          687
==4539== LLi misses:          682
==4539== I1  miss rate:      0.01%
==4539== LLi miss rate:      0.01%
==4539==
==4539== D   refs:      4,072,731  (3,552,445 rd   + 520,286 wr)
==4539== D1  misses:       32,387  (   32,238 rd   +     149 wr)
==4539== LLd misses:       32,197  (   32,062 rd   +     135 wr)
==4539== D1  miss rate:       0.7% (      0.9%     +     0.0%  )
==4539== LLd miss rate:       0.7% (      0.9%     +     0.0%  )
==4539==
==4539== LL refs:          33,074  (   32,925 rd   +     149 wr)
==4539== LL misses:        32,879  (   32,744 rd   +     135 wr)
==4539== LL miss rate:        0.3% (      0.3%     +     0.0%  )
*/



Regards,


Martin

Re: [Valgrind-users] what are the commands to check this scheduler code?

[Mandy M. <te...@ho...>]

Hi ,


how to resolve this issue, invalid read of size 4 and Process terminating with default action of signal 11 (SIGSEGV) ?


martin@ubuntu:~/Downloads/tasks$ valgrind --leak-check=yes casio_system
valgrind: casio_system: command not found
martin@ubuntu:~/Downloads/tasks$ valgrind --leak-check=yes ./casio_system
==15478== Memcheck, a memory error detector
==15478== Copyright (C) 2002-2015, and GNU GPL'd, by Julian Seward et al.
==15478== Using Valgrind-3.11.0 and LibVEX; rerun with -h for copyright info
==15478== Command: ./casio_system
==15478==
Usage: ./casio_system file_name (system configuration)
==15478==
==15478== HEAP SUMMARY:
==15478==     in use at exit: 0 bytes in 0 blocks
==15478==   total heap usage: 0 allocs, 0 frees, 0 bytes allocated
==15478==
==15478== All heap blocks were freed -- no leaks are possible
==15478==
==15478== For counts of detected and suppressed errors, rerun with: -v
==15478== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)
martin@ubuntu:~/Downloads/tasks$ valgrind --leak-check=yes ./casio_system a
==15479== Memcheck, a memory error detector
==15479== Copyright (C) 2002-2015, and GNU GPL'd, by Julian Seward et al.
==15479== Using Valgrind-3.11.0 and LibVEX; rerun with -h for copyright info
==15479== Command: ./casio_system a
==15479==
==15479== Invalid read of size 4
==15479==    at 0x40FFB4B: fgets (iofgets.c:50)
==15479==    by 0x8048D36: get_casio_tasks_config_info (in /home/martin/Downloads/tasks/casio_system)
==15479==    by 0x8048E95: main (in /home/martin/Downloads/tasks/casio_system)
==15479==  Address 0x0 is not stack'd, malloc'd or (recently) free'd
==15479==
==15479==
==15479== Process terminating with default action of signal 11 (SIGSEGV)
==15479==  Access not within mapped region at address 0x0
==15479==    at 0x40FFB4B: fgets (iofgets.c:50)
==15479==    by 0x8048D36: get_casio_tasks_config_info (in /home/martin/Downloads/tasks/casio_system)
==15479==    by 0x8048E95: main (in /home/martin/Downloads/tasks/casio_system)
==15479==  If you believe this happened as a result of a stack
==15479==  overflow in your program's main thread (unlikely but
==15479==  possible), you can try to increase the size of the
==15479==  main thread stack using the --main-stacksize= flag.
==15479==  The main thread stack size used in this run was 8388608.
==15479==
==15479== HEAP SUMMARY:
==15479==     in use at exit: 0 bytes in 0 blocks
==15479==   total heap usage: 1 allocs, 1 frees, 352 bytes allocated
==15479==
==15479== All heap blocks were freed -- no leaks are possible
==15479==
==15479== For counts of detected and suppressed errors, rerun with: -v
==15479== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 0 from 0)
Segmentation fault (core dumped)



Regards,


Martin


________________________________
From: Mandy Martino <te...@ho...>
Sent: Sunday, February 14, 2016 23:25
To: val...@li...
Subject: [Valgrind-users] what are the commands to check this scheduler code?


Hi


There is a need to recompile kernel to patch this module, how to check and step by step debug run this scheduler with valgrind before patch to kernel ?

what are the commands to check this scheduler code?


http://www.embedded.com/design/operating-systems/4204980/Real-Time-Linux-Scheduling-Part-3

[http://www.embedded.com/content/images/icons/contentitem-default.png]<http://www.embedded.com/design/operating-systems/4204980/Real-Time-Linux-Scheduling-Part-3>

Implementing a new real-time scheduling policy for Linux ...<http://www.embedded.com/design/operating-systems/4204980/Real-Time-Linux-Scheduling-Part-3>
www.embedded.com
Implementing a new real-time scheduling policy for Linux: Part 3. Paulo Baltarejo Sousa and Luis Lino Ferreira, Polytechnic Institute of Porto July 28 ...



Regards,


Martin