project('testproject', 'cpp')
src = ['a.cpp', 'b.cpp']
executable('test', src)
What is the simplest way to build my executable with Valgrind using Meson build system?
Just for completeness, wanted to note that valgrind can be used as wrapper in meson command line, for example
$ meson test --wrap='valgrind --leak-check=full --error-exitcode=1' testname
or
$ meson test --wrap='valgrind --tool=helgrind -v --error-exitcode=1' testname
which can be combined with other test options, e.g.
$ meson test --wrap='valgrind --leak-check=full --error-exitcode=1' testname --repeat=100
Check this page of reference manual.
valgrind is a dynamic analysis tool, there is no need to recompile it specially for valgrind.
For example, you can do:
valgrind ls
and valgrind will run and analyse the ls command.
Note that it is however recommended to compile with debugging information, as otherwise the error reports of valgrind will not be very understandable.
An introduction on how to use valgrind is available in http://www.valgrind.org/docs/manual/QuickStart.html
Related
I have a C++ project setup with CMake, running on Mac. Recently I am looking into adding Fortify to do auto code analyzation. I am using Fortify version 22.1.
After set up the CMake and shell scripts, I found that if I compile with more than one CPU (using -j), the compiler (c++ or g++) will have issues generating the libs. Sometimes it will pass and successfully generate the Fortify output, but others it will just error out. Multi CPUs compile fine for this project without running Fortify.
I also see this error when I compile with Fortify (no matter it success or not):
[error]: Translator execution failed. Please consult the Troubleshooting section of the User Manual.
Translator returned status 1:
error: unable to handle compilation, expected exactly one compiler job in ''
This error always happens after a "Linking CXX xxxxx xxxx". I can't find any documentation about them.
Does anyone know how to solve this? Thank you.
Update more details about my setup:
I use shell files to wrap the sourceanalyzer like this:
#!/bin/bash
exec sourceanalyzer -b MyApp /Library/Developer/CommandLineTools/usr/bin/c++ "$#"
And my CMake setup like this:
if (${ENABLE_FORTIFY} EQUAL 1)
set(CMAKE_CC_COMPILER ${AVSxAppDALDefaultImplementation_SOURCE_DIR}/scripts/fortify-build-cc.sh)
set(CMAKE_CXX_COMPILER ${AVSxAppDALDefaultImplementation_SOURCE_DIR}/scripts/fortify-build-cxx.sh)
endif()
My shell script to run CMake and then to the scan:
cmake $PACKAGEPATH \
...
-DENABLE_FORTIFY="${ENABLE_FORTIFY}"
echo "---BUILDING---"
make release
if [[ $ENABLE_FORTIFY == 1 ]]; then
echo "---RUNNING FORTIFY SCAN---"
sourceanalyzer -b ${CURRENT_PROJECT_NAME} -scan -f fortify_scan_result_${CURRENT_PROJECT_NAME}.txt
fi
I have found several conflicting answers over this topic. This blog post requires libuwind, but that doesn't work on Mac OS X. I included #include <google/profiler.h> in my code, however my compiler (g++) could not find the library. I installed gperftools via homebrew. In addition, I found this stackoverflow question showing this:
Then I ran pprof to generate the output:
[hidden ~]$ pprof --text ./a.out cpu.profile
Using local file ./a.out.
Using local file cpu.profile.
Removing __sigtramp from all stack traces.
Total: 282 samples
107 37.9% 37.9% 107 37.9% 0x000000010d72229e
16 5.7% 43.6% 16 5.7% 0x000000010d721a5f
12 4.3% 47.9% 12 4.3% 0x000000010d721de8
...
Running that command (without any of the prior steps) gets me this:
[hidden]$ pprof --text ./a.out cpu.profile
Using remote profile at ./a.out.
Failed to get the number of symbols from http://cpu.profile/pprof/symbol
Why does it try to access an internet site on my machine and a local file on his/hers?
Attempting to link lib profiler as a dry run with g++ gets me:
[hidden]$ g++ -l libprofiler
ld: library not found for -llibprofiler
clang: error: linker command failed with exit code 1 (use -v to see invocation)
I have looked at the man pages, the help option text, the official online guide, blog posts, and many other sources.
I am so confused right now. Can someone help me use gperftools?
The result of my conversation with #osgx was this script. I tried to clean it up a bit. It likely contains quite a few unnecessary options too.
The blog post https://dudefrommangalore.wordpress.com/2012/02/09/profiling-c-code-using-google-performance-tools/ "Profiling C++ code using Google Performance Tools" 2012 by dudefrommangalore missed the essential step.
You should link your program (which you want to be profiled) with cpu profiler library of gperftools library.
Check official manual: http://goog-perftools.sourceforge.net/doc/cpu_profiler.html, part "Linking in the Library"
add -lprofiler to the link-time step for your executable. (It's also probably possible to add in the profiler at run-time using LD_PRELOAD, but this isn't necessarily recommended.)
Second step is to collect the profile, run the code with profiling enabled. In linux world it was done by setting controlling environment variable CPUPROFILE before running:
CPUPROFILE=name_of_profile ./program_to_be_profiled
Third step is to use pprof (google-pprof in ubuntu world). Check that there is not-empty name_of_profile profile file generated; it there is no such file, pprof will try to do remote profile fetch (you see output of such try).
pprof ./program_to_be_profiled name_of_profile
First you need to run your program with profiling enabled.
This is usually first linking your program with libprofiler and then running it with CPUPROFILE=cpu.profile.
I.e.
$ CPUPROFILE=cpu.profile my_program
I think that later step is what you have been missing.
The program will create this cpu.profile file when it exits. And then you can use pprof (preferably from github.com/google/pprof) on it to visualize/analyze.
My program uses all of available memory, so I wanted to check which functions and abstracts are spoiling my project. I decided to use Memprof, so I installed their compiler and compiled my code with command
ocamlfind ocamlopt -package xml-light unix.cmxa str.cmxa -c -g NKJPxmlbasics.ml NKJP.mli NKJP.ml test.ml
and then run as suggested in tutorial
ocp-memprof --exec ./test
But there is error instead of result:
Error: no memory profiling information found. Possible causes:
- the application was not compiled with memory profiling support;
- the application exited before any major garbage collection was performed.
I even managed once to make it work but I have no idea how it happened
http://memprof.typerex.org/users/97beffbaec332eb7b2a048b94f7a38cf/2015-12-15_17-33-50_ab17218e800fe0a68fc2cfa54c13bfa6_16194/index.html
Is there any way to use this tool properly in this situation? What am I missing?
ocamlfind ... -c ... does not generate any executable. So, the ./test that you are running was probably generated by a previous command, probably without the memprof switch.
How can I increase the verbosity of the build process?
Bazel seems to print compiler commands only if something goes wrong during the build.
I would like to see which compiler comands the cc_library rule fires, even if everything seems to be fine, to debug linking problems.
I already tried various bazel command line parameters but nothing gives me the compiler commands :(
This is probably what you are looking for:
bazel build --subcommands //my:target
The --subcommands option causes Bazel's execution phase to print the full command line for each command prior to executing it.
Useful information taken from Envoy's bazel readme (https://github.com/envoyproxy/envoy/blob/master/bazel/README.md)
When trying to understand what Bazel is doing, the -s and --explain options are useful. To have Bazel provide verbose output on which commands it is executing:
bazel build -s //source/...
To have Bazel emit to a text file the rationale for rebuilding a target:
bazel build --explain=file.txt //source/...
To get more verbose explanations:
bazel build --explain=file.txt --verbose_explanations //source/...
Maybe you can generate the compile_commands.json file. I have created Shell scripts (under Linux) to automate that: https://github.com/vincent-picaud/Bazel_and_CompileCommands.
You might also find the following useful in addition to the accepted answer of using --subcommands (-s):
bazel build --subcommands --verbose_failures //my:target
The --verbose_failures option causes Bazel's execution phase to print the full command line for commands that failed.
Although it would seem the --subcommands option supercedes it given it is documented to display prior to command execution, I have found cases (with bazel 5.2.0) where for a failing command, --subcommands alone shows only a portion of the command along with <remaining N arguments skipped>. Using both --subcommands and --verbose_failures displays the full command line in these cases.
I need to set LD_LIBRARY_PATH, LD_PRELOAD and some environment variables for a process while running and detect memory leaks with Valgrind.
Can anyone suggest a way to set or pass these variable for a process in valgrind?.
I've run into a similar issue, trying to run valgrind on programs that need libraries incompatible with the ones valgrind uses, and have been using:
valgrind --trace-children=yes env LD_LIBRARY_PATH=your_library_path OTHER_VAR=foo your_program arg1 arg2...
env sets up the environment and then execs your_program. We need to pass the --trace-children=yes argument to valgrind in order for it to continue to trace through the exec syscall. Without --trace-children=yes set, valgrind will stop tracing at the exec and you won't get any useful output from valgrind on your_program.
One potential downside to this approach is that valgrind might report any memory issues in env. I haven't seen any false positives from this source (env is not a very complicated program), but it could happen.
I haven't tried this with LD_PRELOAD though (it hasn't come up for my use-case yet). Valgrind does set LD_PRELOAD, so you might have to do something like:
valgrind --trace-children=yes env LD_PRELOAD=$LD_PRELOAD:your_preload your_program
What is wrong with the standard mechanisms? These include:
LD_LIBRARY_PATH=$new_libpath LD_PRELOAD=$new_preload OTHERVAR=otherval valgrind your.program arg1 …
Or:
env LD_LIBRARY_PATH=$new_libpath \
LD_PRELOAD=$new_preload \
OTHERVAR=otherval \
valgrind ./your.program arg1 …
Or:
export LD_LIBRARY_PATH=$new_libpath
export LD_PRELOAD=$new_preload
export OTHERVAR=otherval
valgrind ./your.program arg1 …
The advantage of the first two mechanisms is that it doesn't affect the working environment of your shell. The advantage of the last mechanism is that it does affect the working environment of your shell (which makes it easier to run valgrind the next time — you don't have to remember to find the command with the environment in your history).