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

Re: [Valgrind-users] Callgrind

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

Hi Olaf,

Am 21.07.2014 14:48, schrieb Olaf Lenz:
> 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.:

Can you check out with Valgrind 3.9.0 ?
This is not Callgrind related, but about the debuginfo loader, which also
should affect the other tools, such as memcheck output on finding errors.
It would be good if you can confirm that.

If the problem persists, please open a bug.

Josef

> 
> 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
> 
> 
> ------------------------------------------------------------------------------
> Want fast and easy access to all the code in your enterprise? Index and
> search up to 200,000 lines of code with a free copy of Black Duck
> Code Sight - the same software that powers the world's largest code
> search on Ohloh, the Black Duck Open Hub! Try it now.
> http://p.sf.net/sfu/bds
> 
> 
> 
> _______________________________________________
> Valgrind-users mailing list
> Val...@li...
> https://lists.sourceforge.net/lists/listinfo/valgrind-users
> 

Re: [Valgrind-users] Callgrind

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

Hi Josef!

I have just installed valgrind-3.9.0, and it doesn't solve the problem.
Also, the problem seems to be there in memcheck, so it seems to be a
problem with the debuginfo loader.
Is there a way to explicitly check the loader?

Olaf


2014-07-22 10:25 GMT+02:00 Josef Weidendorfer <Jos...@gm...>:

> Hi Olaf,
>
> Am 21.07.2014 14:48, schrieb Olaf Lenz:
> > 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.:
>
> Can you check out with Valgrind 3.9.0 ?
> This is not Callgrind related, but about the debuginfo loader, which also
> should affect the other tools, such as memcheck output on finding errors.
> It would be good if you can confirm that.
>
> If the problem persists, please open a bug.
>
> Josef
>
> >
> > 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
> >
> >
> >
> ------------------------------------------------------------------------------
> > Want fast and easy access to all the code in your enterprise? Index and
> > search up to 200,000 lines of code with a free copy of Black Duck
> > Code Sight - the same software that powers the world's largest code
> > search on Ohloh, the Black Duck Open Hub! Try it now.
> > http://p.sf.net/sfu/bds
> >
> >
> >
> > _______________________________________________
> > Valgrind-users mailing list
> > Val...@li...
> > https://lists.sourceforge.net/lists/listinfo/valgrind-users
> >
>
>
> ------------------------------------------------------------------------------
> Want fast and easy access to all the code in your enterprise? Index and
> search up to 200,000 lines of code with a free copy of Black Duck
> Code Sight - the same software that powers the world's largest code
> search on Ohloh, the Black Duck Open Hub! Try it now.
> http://p.sf.net/sfu/bds
> _______________________________________________
> Valgrind-users mailing list
> Val...@li...
> https://lists.sourceforge.net/lists/listinfo/valgrind-users
>
>


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

Re: [Valgrind-users] Callgrind

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

Am 22.07.2014 14:31, schrieb Olaf Lenz:
> Hi Josef!
> 
> I have just installed valgrind-3.9.0, and it doesn't solve the problem. 
> Also, the problem seems to be there in memcheck, so it seems to be a
> problem with the debuginfo loader.
> Is there a way to explicitly check the loader?

Hmm. You could check the current SVN version. There are some fixes
for the DWARF loader. Also, a sync with the demangler code from
gdb was recently done.
Or recompile (part of the code) with different debug info generation
flags of the compiler (-gdwarf-3, -gstabs, ..).
What compiler/architecture is this?

Josef


> 
> Olaf
> 
> 
> 2014-07-22 10:25 GMT+02:00 Josef Weidendorfer <Jos...@gm...
> <mailto:Jos...@gm...>>:
> 
>     Hi Olaf,
> 
>     Am 21.07.2014 14 <tel:21.07.2014%2014>:48, schrieb Olaf Lenz:
>     > 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.:
> 
>     Can you check out with Valgrind 3.9.0 ?
>     This is not Callgrind related, but about the debuginfo loader, which
>     also
>     should affect the other tools, such as memcheck output on finding
>     errors.
>     It would be good if you can confirm that.
> 
>     If the problem persists, please open a bug.
> 
>     Josef
> 
>     >
>     > 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
>     >
>     >
>     > ------------------------------------------------------------------------------
>     > Want fast and easy access to all the code in your enterprise? Index and
>     > search up to 200,000 lines of code with a free copy of Black Duck
>     > Code Sight - the same software that powers the world's largest code
>     > search on Ohloh, the Black Duck Open Hub! Try it now.
>     > http://p.sf.net/sfu/bds
>     >
>     >
>     >
>     > _______________________________________________
>     > Valgrind-users mailing list
>     > Val...@li...
>     <mailto:Val...@li...>
>     > https://lists.sourceforge.net/lists/listinfo/valgrind-users
>     >
> 
>     ------------------------------------------------------------------------------
>     Want fast and easy access to all the code in your enterprise? Index and
>     search up to 200,000 lines of code with a free copy of Black Duck
>     Code Sight - the same software that powers the world's largest code
>     search on Ohloh, the Black Duck Open Hub! Try it now.
>     http://p.sf.net/sfu/bds
>     _______________________________________________
>     Valgrind-users mailing list
>     Val...@li...
>     <mailto:Val...@li...>
>     https://lists.sourceforge.net/lists/listinfo/valgrind-users
> 
> 
> 
> 
> -- 
> Dr. rer. nat. Olaf Lenz
> Institut für Computerphysik, Allmandring 3, D-70569 Stuttgart
> Phone: +49-711-685-63607

Re: [Valgrind-users] Callgrind

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

On Tue, 2014-07-22 at 14:48 +0200, Josef Weidendorfer wrote:
> Am 22.07.2014 14:31, schrieb Olaf Lenz:
> > Hi Josef!
> > 
> > I have just installed valgrind-3.9.0, and it doesn't solve the problem. 
> > Also, the problem seems to be there in memcheck, so it seems to be a
> > problem with the debuginfo loader.
> > Is there a way to explicitly check the loader?
> 
> Hmm. You could check the current SVN version. There are some fixes
> for the DWARF loader. Also, a sync with the demangler code from
> gdb was recently done.
> Or recompile (part of the code) with different debug info generation
> flags of the compiler (-gdwarf-3, -gstabs, ..).
Note that valgrind stabs reader is broken and disabled since 3.9.0.

Philippe

Re: [Valgrind-users] Callgrind

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

I'm using OpenSUSE 12.3, 64bit.
I have used current valgrind and also the SVN version, but to no avail.
"nm" tells me that the debuginfo is in the binary, but valgrind won't find
it.

I did use valgrind to profile other binaries on the same machine, built
with the same compiler, and it worked fine. Could that be something in the
build system of our software? Or am I safe to say that when nm finds the
info, valgrind should, too?

Olaf


2014-07-22 14:48 GMT+02:00 Josef Weidendorfer <Jos...@gm...>:

> Am 22.07.2014 14:31, schrieb Olaf Lenz:
> > Hi Josef!
> >
> > I have just installed valgrind-3.9.0, and it doesn't solve the problem.
> > Also, the problem seems to be there in memcheck, so it seems to be a
> > problem with the debuginfo loader.
> > Is there a way to explicitly check the loader?
>
> Hmm. You could check the current SVN version. There are some fixes
> for the DWARF loader. Also, a sync with the demangler code from
> gdb was recently done.
> Or recompile (part of the code) with different debug info generation
> flags of the compiler (-gdwarf-3, -gstabs, ..).
> What compiler/architecture is this?
>
> Josef
>
>
> >
> > Olaf
> >
> >
> > 2014-07-22 10:25 GMT+02:00 Josef Weidendorfer <Jos...@gm...
> > <mailto:Jos...@gm...>>:
> >
> >     Hi Olaf,
> >
> >     Am 21.07.2014 14 <tel:21.07.2014%2014>:48, schrieb Olaf Lenz:
> >     > 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.:
> >
> >     Can you check out with Valgrind 3.9.0 ?
> >     This is not Callgrind related, but about the debuginfo loader, which
> >     also
> >     should affect the other tools, such as memcheck output on finding
> >     errors.
> >     It would be good if you can confirm that.
> >
> >     If the problem persists, please open a bug.
> >
> >     Josef
> >
> >     >
> >     > 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
> >     >
> >     >
> >     >
> ------------------------------------------------------------------------------
> >     > Want fast and easy access to all the code in your enterprise?
> Index and
> >     > search up to 200,000 lines of code with a free copy of Black Duck
> >     > Code Sight - the same software that powers the world's largest code
> >     > search on Ohloh, the Black Duck Open Hub! Try it now.
> >     > http://p.sf.net/sfu/bds
> >     >
> >     >
> >     >
> >     > _______________________________________________
> >     > Valgrind-users mailing list
> >     > Val...@li...
> >     <mailto:Val...@li...>
> >     > https://lists.sourceforge.net/lists/listinfo/valgrind-users
> >     >
> >
> >
> ------------------------------------------------------------------------------
> >     Want fast and easy access to all the code in your enterprise? Index
> and
> >     search up to 200,000 lines of code with a free copy of Black Duck
> >     Code Sight - the same software that powers the world's largest code
> >     search on Ohloh, the Black Duck Open Hub! Try it now.
> >     http://p.sf.net/sfu/bds
> >     _______________________________________________
> >     Valgrind-users mailing list
> >     Val...@li...
> >     <mailto:Val...@li...>
> >     https://lists.sourceforge.net/lists/listinfo/valgrind-users
> >
> >
> >
> >
> > --
> > Dr. rer. nat. Olaf Lenz
> > Institut für Computerphysik, Allmandring 3, D-70569 Stuttgart
> > Phone: +49-711-685-63607
>
>


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

Re: [Valgrind-users] Callgrind

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

On Tue, 2014-07-22 at 15:20 +0200, Olaf Lenz wrote:
> I'm using OpenSUSE 12.3, 64bit.
> I have used current valgrind and also the SVN version, but to no
> avail.
> "nm" tells me that the debuginfo is in the binary, but valgrind won't
> find it.
> 
> 
> I did use valgrind to profile other binaries on the same machine,
> built with the same compiler, and it worked fine. Could that be
> something in the build system of our software? Or am I safe to say
> that when nm finds the info, valgrind should, too?
What you could do is to take a binary which is ok,
and the binary that is not ok.

Then for both, you run valgrind, increasing the level of
tracing/debugging, until you see a difference which could explain
what is going wrong with espresso.

You could first try with -v 
and then succesfully add more -v and more -d (up to 3 each).
After that, even more heavyweight tracing can be enabled by adding
one or more of :
--debug-dump=syms
--debug-dump=line
--debug-dump=frames
--trace-symtab=yes

Philippe

Re: [Valgrind-users] Callgrind

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

Hi!

It looks as though I'm homing in on the culprit.
The problem seems to be that the program is MPI-enabled. When disabling MPI
in ESPResSo, valgrind works fine.
It should be noted that OpenMPI provides its own compiler wrapper (mpic++)
around g++ and does some heavy meddling with the internals. I assume that
this somehow causes valgrind not to be able to use the symbol table. I am
still looking into it.

Olaf


2014-07-22 23:15 GMT+02:00 Philippe Waroquiers <
phi...@sk...>:

> On Tue, 2014-07-22 at 15:20 +0200, Olaf Lenz wrote:
> > I'm using OpenSUSE 12.3, 64bit.
> > I have used current valgrind and also the SVN version, but to no
> > avail.
> > "nm" tells me that the debuginfo is in the binary, but valgrind won't
> > find it.
> >
> >
> > I did use valgrind to profile other binaries on the same machine,
> > built with the same compiler, and it worked fine. Could that be
> > something in the build system of our software? Or am I safe to say
> > that when nm finds the info, valgrind should, too?
> What you could do is to take a binary which is ok,
> and the binary that is not ok.
>
> Then for both, you run valgrind, increasing the level of
> tracing/debugging, until you see a difference which could explain
> what is going wrong with espresso.
>
> You could first try with -v
> and then succesfully add more -v and more -d (up to 3 each).
> After that, even more heavyweight tracing can be enabled by adding
> one or more of :
> --debug-dump=syms
> --debug-dump=line
> --debug-dump=frames
> --trace-symtab=yes
>
> Philippe
>
>
>
>


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

Re: [Valgrind-users] Callgrind

[Brian B. <bri...@gm...>]

You can build openmpi to have better valgrind support.  See the openmpi
docs for details.
On Jul 23, 2014 4:59 AM, "Olaf Lenz" <ol...@ic...> wrote:

> Hi!
>
> It looks as though I'm homing in on the culprit.
> The problem seems to be that the program is MPI-enabled. When disabling
> MPI in ESPResSo, valgrind works fine.
> It should be noted that OpenMPI provides its own compiler wrapper (mpic++)
> around g++ and does some heavy meddling with the internals. I assume that
> this somehow causes valgrind not to be able to use the symbol table. I am
> still looking into it.
>
> Olaf
>
>
> 2014-07-22 23:15 GMT+02:00 Philippe Waroquiers <
> phi...@sk...>:
>
>> On Tue, 2014-07-22 at 15:20 +0200, Olaf Lenz wrote:
>> > I'm using OpenSUSE 12.3, 64bit.
>> > I have used current valgrind and also the SVN version, but to no
>> > avail.
>> > "nm" tells me that the debuginfo is in the binary, but valgrind won't
>> > find it.
>> >
>> >
>> > I did use valgrind to profile other binaries on the same machine,
>> > built with the same compiler, and it worked fine. Could that be
>> > something in the build system of our software? Or am I safe to say
>> > that when nm finds the info, valgrind should, too?
>> What you could do is to take a binary which is ok,
>> and the binary that is not ok.
>>
>> Then for both, you run valgrind, increasing the level of
>> tracing/debugging, until you see a difference which could explain
>> what is going wrong with espresso.
>>
>> You could first try with -v
>> and then succesfully add more -v and more -d (up to 3 each).
>> After that, even more heavyweight tracing can be enabled by adding
>> one or more of :
>> --debug-dump=syms
>> --debug-dump=line
>> --debug-dump=frames
>> --trace-symtab=yes
>>
>> Philippe
>>
>>
>>
>>
>
>
> --
> Dr. rer. nat. Olaf Lenz
> Institut für Computerphysik, Allmandring 3, D-70569 Stuttgart
> Phone: +49-711-685-63607
>
>
> ------------------------------------------------------------------------------
> Want fast and easy access to all the code in your enterprise? Index and
> search up to 200,000 lines of code with a free copy of Black Duck
> Code Sight - the same software that powers the world's largest code
> search on Ohloh, the Black Duck Open Hub! Try it now.
> http://p.sf.net/sfu/bds
> _______________________________________________
> Valgrind-users mailing list
> Val...@li...
> https://lists.sourceforge.net/lists/listinfo/valgrind-users
>
>