Как установить valgrind ubuntu

Обновлено: 07.07.2024

The complete source code, including documentation, is available as a tarball for the current release. For downloadable / browseable manual packages, go to the Documentation page. For older releases, see the Release Archive page.

If you would like to be notified when a new valgrind release is made, you can subscribe to the Valgrind announcements mailing list.

Valgrind 3.18.1

PGP signature is here.

3.18.1 fixes a number of bugs and adds support for glibc-2.34, and for new platforms x86/FreeBSD and amd64/FreeBSD. Debuginfo reading is faster, and Rust demangling has been improved. For PPC64, ISA 3.1 support has been completed, and some newer ARM64 and S390 instructions are also supported. See the release notes for details.

PGP signature is here.

3.17.0 fixes a number of bugs and adds some functional changes: support for GCC 11, Clang 11, DWARF5 debuginfo, the 'debuginfod' debuginfo server, and some new instructions for Arm64, S390 and POWER. There are also some tool updates. See the release notes for details.

PGP signature is here.

3.16.0 updates support for existing platforms, adds support for AArch64 v8.1, and reduces the Memcheck false positive rate on highly optimised code. There are, as ever, many smaller refinements and bug fixes. See the release notes for details.

PGP signature is here.

3.15.0 updates support for existing platforms and adds a major overhaul of the DHAT heap profiler. There are, as ever, many smaller refinements and bug fixes. See the release notes for details.

3.14.0 updates support for existing platforms. There are, as ever, many smaller refinements and bug fixes. See the release notes for details.

3.13.0 adds support for larger processes and programs, solidifies and improves support on existing platforms, and provides new heap-use reporting facilities. There are, as ever, many smaller refinements and bug fixes. See the release notes for details.

3.12.0 is a feature release with many improvements and the usual collection of bug fixes. This release adds support for POWER ISA 3.0, improves instruction set support on ARM32, ARM64 and MIPS, and provides support for the latest common components (kernel, gcc, glibc). There are many smaller refinements and new features. See the release notes for details.

You may want to look at the 3.11.0 release notes.

3.11.0 is a feature release with many improvements and the usual collection of bug fixes. This release adds full support for X86/Solaris and AMD64/Solaris, improves support for Mac OS X 10.10 (Yosemite), and adds preliminary support for Mac OS X 10.11 (El Capitan) and TileGX/Linux. Intel AVX2 support is more complete (64 bit targets only). There are many smaller refinements and new features. See the release notes for details.

You may want to look at the 3.10.1 release notes.

3.10.1 is a bug fix release. It fixes various bugs reported in 3.10.0 and backports fixes for all reported missing AArch64 ARMv8 instructions and syscalls from the trunk. If you package or deliver 3.10.0 for others to use, you might want to consider upgrading to 3.10.1 instead. See the release notes for details.

This release supports X86/Linux, AMD64/Linux, ARM/Linux, ARM64/Linux,PPC32/Linux, PPC64/Linux, PPC64BE/Linux, S390X/Linux, MIPS32/Linux, MIPS64/Linux, ARM/Android (2.3 and later), X86/Android (4.0 and later), MIPS32/Android, X86/Darwin and AMD64/Darwin (Mac OS X 10.9 and, to a limited extent, 10.8).

You may want to look at the 3.10.0 release notes.

3.10.0 is a feature release with many improvements and the usual collection of bug fixes. This release adds support for ARM64/Linux, MIPS32/Android and little-endian PPC64/Linux, and improves support for Mac OS X 10.9 (Mavericks). Inlining-aware stack unwinding is now available on Linux targets. There are many smaller refinements and new features. See the release notes for details.

You may want to look at the 3.9.0 release notes.

3.9.0 is feature release with many improvements and the usual collection of bug fixes. This release adds support for MIPS64/Linux and improves support for Mac OS X 10.8 (Mountain Lion). Intel AVX2 and Power POWER8 instructions are supported. Initial support for hardware transactional memory on Intel and POWER platforms has been added. Accuracy of Memcheck on vectorized code has been improved. There are many smaller refinements and new features. See the release notes for details.

This release supports X86/Linux, AMD64/Linux, ARM/Linux, PPC32/Linux, PPC64/Linux, S390X/Linux, MIPS32/Linux, MIPS64/Linux, ARM/Android (2.3 and later), X86/Android (4.0 and later), X86/Darwin and AMD64/Darwin (Mac OS X 10.7 and, to a limited extent, 10.8).

You may want to look at the 3.8.1 release notes.

3.8.1 is a bug fix release. It fixes some assertion failures in 3.8.0 that occur moderately frequently in real use cases, adds support for some missing instructions on ARM, and fixes a deadlock condition on MacOSX. If you package or deliver 3.8.0 for others to use, you might want to consider upgrading to 3.8.1 instead. See the release notes for details, including a list of bug fixes.

This release supports X86/Linux, AMD64/Linux, ARM/Linux, PPC32/Linux, PPC64/Linux, S390X/Linux, MIPS32/Linux, ARM/Android (2.3 and later), X86/Android (4.0 and later), X86/Darwin and AMD64/Darwin (Mac OS X 10.6, 10.7 and to a very limited extent, 10.8).

You may want to look at the 3.8.0 release notes.

3.8.0 is a feature release with many improvements and the usual collection of bug fixes. This release adds support for MIPS32/Linux and X86/Android and has initial support for Mac OS X 10.8 (Mountain Lion). Intel AVX and AES instructions are now supported. There is modestly improved performance in some areas, and decreased memory consumption. There are many smaller refinements and new features. See the release notes for details.

You may want to look at the 3.7.0 release notes.

3.7.0 is a feature release with many significant improvements and the usual collection of bug fixes. This release adds support for ARM/Android, S390X/Linux and Mac OS X 10.7 (Lion). A GDB server has been added, so you can now control your application from inside GDB whilst it runs on Valgrind. There have been performance and functionality improvements for the following tools: Helgrind, DRD, Memcheck and exp-Sgcheck.

The tool formerly known as exp-Ptrcheck has been renamed to exp-SGCheck.

This release supports X86/Linux, AMD64/Linux, ARM/Linux, PPC32/Linux, PPC64/Linux, S390X/Linux, ARM/Android (2.3.x), X86/Darwin and AMD64/Darwin (Mac OS X 10.6 and 10.7).

You may want to look at the 3.6.1 release notes.

3.6.1 is a bug fix release. It adds support for some SSE4 instructions that were omitted in 3.6.0 due to lack of time. Initial support for glibc-2.13 has been added. A number of bugs causing crashing or assertion failures have been fixed.

You may want to look at the 3.6.0 release notes.

3.6.0 is a feature release with many significant improvements and the usual collection of bug fixes. The main improvement is that Valgrind now works on ARM/Linux and on Mac OS X 10.6 (Snow Leopard).

This release supports X86/Linux, AMD64/Linux, ARM/Linux, PPC32/Linux, PPC64/Linux, X86/Darwin and AMD64/Darwin (Mac OS X 10.5 and 10.6). Support for recent distros and toolchain components (glibc 2.12, gcc 4.5) has been added.

You may want to look at the 3.5.0 release notes.

3.5.0 is a feature release with many significant improvements and the usual collection of bug fixes. The main improvement is that Valgrind now works on Mac OS X.

This release supports X86/Linux, AMD64/Linux, PPC32/Linux, PPC64/Linux and X86/Darwin (Mac OS X). Support for recent distros and toolchain components (glibc 2.10, gcc 4.5) has been added.

You may want to look at the 3.4.1 release notes.

3.4.1 is a bug-fix release that fixes some regressions and assertion failures in debug info reading in 3.4.0, most notably incorrect stack traces on amd64-linux on older (glibc-2.3 based) systems. Various other debug info problems are also fixed. A number of bugs in the exp-ptrcheck tool introduced in 3.4.0 have been fixed.

In view of the fact that 3.4.0 contains user-visible regressions relative to 3.3.x, upgrading to 3.4.1 is recommended. Packagers are encouraged to ship 3.4.1 in preference to 3.4.0.

Valkyrie 2.0.0

valkyrie 2.0.0 (tar.bz2) [260Kb] - 21 October 2010.
md5: a411dfb803f548dae5f988de0160aeb5

Valkyrie is a Qt4-based GUI for the Valgrind 3.6.x and 3.7.x series, that works for the Memcheck and Helgrind tools. It also has an XML merging tool for Memcheck outputs (vk_logmerge). This tarball is known to build and work with valgrind-3.6.0 and valgrind-3.7.0.

This version of Valkyrie does not support any version of Valgrind prior to 3.6.0. If you want to use Valkyrie with an older Valgrind version, we recommend you instead upgrade your Valgrind to 3.6.0 and use this version of Valkyrie.

Valkyrie is a GUI for the Valgrind 3.4.x releases. It also has an XML merging tool for Memcheck outputs (vk_logmerge). This tarball is known to build and work with valgrind-3.4.0.

This version of Valkyrie does not support the older Valgrind 3.3.x releases. If you need a GUI for Valgrind 3.3.x, instead use valkyrie 1.3.0 (tar.bz2) instead.

This version of Valkyrie also does not support the newer Valgrind 3.5.0 release. We plan to release a 3.5.0-compatible version of Valkyrie in the near future.

RPMs / Binaries

We do not distribute binaries or RPMs. The releases available on this website contain the source code and have to be compiled in order to be installed on your system. Many Linux distributions come with valgrind these days, so if you do not want to compile your own, go to your distribution's download site.

How do I use valgrind to find the memory leaks in a program?

Please someone help me and describe the steps to carryout the procedure?

I am using Ubuntu 10.04 and I have a program a.c , please help me out.

9,077 3 3 gold badges 42 42 silver badges 68 68 bronze badges 3,533 7 7 gold badges 19 19 silver badges 14 14 bronze badges You use valgrind to test your compiled program, not the source code. A leak is caused by something you fail to do - ie. free allocated memory. Hence Valgrind cannot show you "where" the leak is - only you know where the allocated memory is no longer required. However, by telling you which allocation is not being free()d, by tracing the use of that memory through your program, you should be able to determine where it should get free()d. A common mistake is error-exiting a function without freeing allocated memory.

4 Answers 4

Not to insult the OP, but for those who come to this question and are still new to Linux—you might have to install Valgrind on your system.

Valgrind is readily usable for C/C++ code, but can even be used for other languages when configured properly (see this for Python).

To run Valgrind, pass the executable as an argument (along with any parameters to the program).

The flags are, in short:

--leak-check=full : "each individual leak will be shown in detail"
--show-leak-kinds=all : Show all of "definite, indirect, possible, reachable" leak kinds in the "full" report.
--track-origins=yes : Favor useful output over speed. This tracks the origins of uninitialized values, which could be very useful for memory errors. Consider turning off if Valgrind is unacceptably slow.
--verbose : Can tell you about unusual behavior of your program. Repeat for more verbosity.
--log-file : Write to a file. Useful when output exceeds terminal space.

Finally, you would like to see a Valgrind report that looks like this:

So, you have a memory leak, and Valgrind isn't saying anything meaningful. Perhaps, something like this:

Let's take a look at the C code I wrote too:

Well, there were 5 bytes lost. How did it happen? The error report just says main and malloc . In a larger program, that would be seriously troublesome to hunt down. This is because of how the executable was compiled. We can actually get line-by-line details on what went wrong. Recompile your program with a debug flag (I'm using gcc here):

Now with this debug build, Valgrind points to the exact line of code allocating the memory that got leaked! (The wording is important: it might not be exactly where your leak is, but what got leaked. The trace helps you find where.)

Sometimes your leaks/errors can be linked to one another, much like an IDE discovering that you haven't typed a closing bracket yet. Resolving one issue can resolve others, so look for one that looks a good culprit and apply some of these ideas:

List out the functions in your code that depend on/are dependent on the "offending" code that has the memory error. Follow the program's execution (maybe even in gdb perhaps), and look for precondition/postcondition errors. The idea is to trace your program's execution while focusing on the lifetime of allocated memory.
Try commenting out the "offending" block of code (within reason, so your code still compiles). If the Valgrind error goes away, you've found where it is.

Watch your pointers

As a teaching assistant, I've seen this mistake often. The student makes use of a local variable and forgets to update the original pointer. The error here is noticing that realloc can actually move the allocated memory somewhere else and change the pointer's location. We then leave resizeArray without telling array->data where the array was moved to.

Invalid write

Notice that Valgrind points us to the commented line of code above. The array of size 26 is indexed [0,25] which is why *(alphabet + 26) is an invalid write—it's out of bounds. An invalid write is a common result of off-by-one errors. Look at the left side of your assignment operation.

Invalid read

Valgrind points us to the commented line above. Look at the last iteration here, which is
*(destination + 26) = *(source + 26); . However, *(source + 26) is out of bounds again, similarly to the invalid write. Invalid reads are also a common result of off-by-one errors. Look at the right side of your assignment operation.

How do I know when the leak is mine? How do I find my leak when I'm using someone else's code? I found a leak that isn't mine; should I do something? All are legitimate questions. First, 2 real-world examples that show 2 classes of common encounters.

Jansson: a JSON library

This is a simple program: it reads a JSON string and parses it. In the making, we use library calls to do the parsing for us. Jansson makes the necessary allocations dynamically since JSON can contain nested structures of itself. However, this doesn't mean we decref or "free" the memory given to us from every function. In fact, this code I wrote above throws both an "Invalid read" and an "Invalid write". Those errors go away when you take out the decref line for value .

SDL: a graphics and gaming library

What's wrong with this code? It consistently leaks

212 KiB of memory for me. Take a moment to think about it. We turn SDL on and then off. Answer? There is nothing wrong.

Answers unto the void

How do I know when the leak is mine?
It is. (99% sure, anyway)

How do I find my leak when I'm using someone else's code?
Chances are someone else already found it. Try Google! If that fails, use the skills I gave you above. If that fails and you mostly see API calls and little of your own stack trace, see the next question.

I found a leak that isn't mine; should I do something?
Yes! Most APIs have ways to report bugs and issues. Use them! Help give back to the tools you're using in your project!

Thanks for staying with me this long. I hope you've learned something, as I tried to tend to the broad spectrum of people arriving at this answer. Some things I hope you've asked along the way: How does C's memory allocator work? What actually is a memory leak and a memory error? How are they different from segfaults? How does Valgrind work? If you had any of these, please do feed your curiousity:

The Valgrind tool suite provides a number of debugging and profiling tools that help you make your programs faster and more correct. The most popular of these tools is called Memcheck. It can detect many memory-related errors that are common in C and C++ programs and that can lead to crashes and unpredictable behaviour.

The rest of this guide gives the minimum information you need to start detecting memory errors in your program with Memcheck. For full documentation of Memcheck and the other tools, please read the User Manual.

2. Preparing your program

Compile your program with -g to include debugging information so that Memcheck's error messages include exact line numbers. Using -O0 is also a good idea, if you can tolerate the slowdown. With -O1 line numbers in error messages can be inaccurate, although generally speaking running Memcheck on code compiled at -O1 works fairly well, and the speed improvement compared to running -O0 is quite significant. Use of -O2 and above is not recommended as Memcheck occasionally reports uninitialised-value errors which don't really exist.

3. Running your program under Memcheck

If you normally run your program like this:

Use this command line:

Memcheck is the default tool. The --leak-check option turns on the detailed memory leak detector.

Your program will run much slower (eg. 20 to 30 times) than normal, and use a lot more memory. Memcheck will issue messages about memory errors and leaks that it detects.

4. Interpreting Memcheck's output

Here's an example C program, in a file called a.c, with a memory error and a memory leak.

Most error messages look like the following, which describes problem 1, the heap block overrun:

Things to notice:

There is a lot of information in each error message; read it carefully.

The 19182 is the process ID; it's usually unimportant.

The first line ("Invalid write. ") tells you what kind of error it is. Here, the program wrote to some memory it should not have due to a heap block overrun.

Below the first line is a stack trace telling you where the problem occurred. Stack traces can get quite large, and be confusing, especially if you are using the C++ STL. Reading them from the bottom up can help. If the stack trace is not big enough, use the --num-callers option to make it bigger.

The code addresses (eg. 0x804838F) are usually unimportant, but occasionally crucial for tracking down weirder bugs.

Some error messages have a second component which describes the memory address involved. This one shows that the written memory is just past the end of a block allocated with malloc() on line 5 of example.c.

It's worth fixing errors in the order they are reported, as later errors can be caused by earlier errors. Failing to do this is a common cause of difficulty with Memcheck.

Memory leak messages look like this:

The stack trace tells you where the leaked memory was allocated. Memcheck cannot tell you why the memory leaked, unfortunately. (Ignore the "vg_replace_malloc.c", that's an implementation detail.)

"definitely lost": your program is leaking memory -- fix it!

"probably lost": your program is leaking memory, unless you're doing funny things with pointers (such as moving them to point to the middle of a heap block).

Memcheck also reports uses of uninitialised values, most commonly with the message "Conditional jump or move depends on uninitialised value(s)". It can be difficult to determine the root cause of these errors. Try using the --track-origins=yes to get extra information. This makes Memcheck run slower, but the extra information you get often saves a lot of time figuring out where the uninitialised values are coming from.

If you don't understand an error message, please consult Explanation of error messages from Memcheck in the Valgrind User Manual which has examples of all the error messages Memcheck produces.

5. Caveats

Memcheck is not perfect; it occasionally produces false positives, and there are mechanisms for suppressing these (see Suppressing errors in the Valgrind User Manual). However, it is typically right 99% of the time, so you should be wary of ignoring its error messages. After all, you wouldn't ignore warning messages produced by a compiler, right? The suppression mechanism is also useful if Memcheck is reporting errors in library code that you cannot change. The default suppression set hides a lot of these, but you may come across more.

Memcheck cannot detect every memory error your program has. For example, it can't detect out-of-range reads or writes to arrays that are allocated statically or on the stack. But it should detect many errors that could crash your program (eg. cause a segmentation fault).

6. More information

Please consult the Valgrind FAQ and the Valgrind User Manual, which have much more information. Note that the other tools in the Valgrind distribution can be invoked with the --tool option.

Читайте также: