CODEWITHSUNDEEP
c++valgrindcallgrind
libxelar.so
libxelar.so

Reputation: 543

attaching callgrind/valgrind to program in mid-way of its execution

I use Valgrind to detect issues by running a program from the beginning. Now I have memory/performance issues in a very specific moment in the program. Unfortunately there is no feasible way to make a shortcut to this place from the start.

Is there a way to instrument the c++ program ( Valgrind/Callgrind ) in its mid-way execution, like attaching to the process?

Already answered here: How use callgrind to profiling only a certain period of program execution?

Upvotes: 3

Views: 3392

Answers (3)

libxelar.so
libxelar.so

Reputation: 543

Thanks all for help. Seems It's been already answered here: How use callgrind to profiling only a certain period of program execution? but not marked as answered for some reason.

Summary: Starting callgrind with instrumentation off 

valgrind --tool=callgrind --instr-atstart=no <PROG>

Controling instrumentation ( can be executed in other shell )

callgrind_control -i on/off

Upvotes: 3

Paul Floyd
Paul Floyd

Reputation: 6906

There are two things that Callgrind does that slows down execution.

  • Counting operations (the collect part)
  • Simulating the cache and branch predictor (the instrumentation part). This depends on the --cache-sim and --branch-sim options, which both default to "no". If you are using these options and you disable instrumentation then I expect that there will be some impact on the accuracy of the modelling as the cache and predictor won't be "warm" when they are toggled.

There are a few other approaches that you could use.

  1. Use the client request mechanisms. This would require you to include a Valgrind header and add a few lines that use Valgrind macros CALLGRIND_START_INSTRUMENTATION/CALLGRIND_STOP_INSTRUMENTATION and CALLGRIND_TOGGLE_COLLECTto start and stop instrumentation/collection. See the manual for details. Then just run your application under Valgrind with --instr-atstart=no --collect-atstart=no

  2. Use the gdb monitor commands. In this case you would have two terminals. In the first you would run Valgrind with --instr-atstart=no --collect-atstart=no --vgdb=yes. In the second terminal run gdb yourapplication then from the gdb prompt (gdb) target remote | vgdb. Then you can use the monitor commands as described in the manual, which include collect and instrumentation control.

  3. callgrind_control, part of the Valgrind distribution. To be honest I've never used this.

I recently did some profiling using the first technique without cache/branch sim. When I used Callgrind on the whole run I saw a 23x runtime increase compared to running outside of Callgrind. When I profiled only the one function that I wanted to analyze, this fell to about a 5x slowdown. Obviously this will very greatly case by case.

Upvotes: 2

phd
phd

Reputation: 3807

There is no way to use valgrind on an already running program.

For callgrind, you can however somewhat speed it up by only recording data later during execution.

For this, you might e.g. look at callgrind options

    --instr-atstart=no|yes    Do instrumentation at callgrind start [yes]
    --collect-atstart=no|yes  Collect at process/thread start [yes]
    --toggle-collect=<func>   Toggle collection on enter/leave function

You can also control such aspects from within your program.

Refer to valgrind/callgrind user manual for more details.

Upvotes: 5

Related Questions