Valgrind memcheck amd64 linux

How do I use valgrind to find memory leaks?

How do I use valgrind to find the memory leaks in a program? I am using Ubuntu 10.04 and I have a program a.c .

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

How to Run Valgrind

First of all check you have Valgrind installed, if not:

sudo apt install valgrind # Ubuntu, Debian, etc. sudo yum install valgrind # RHEL, CentOS, Fedora, etc. sudo pacman -Syu valgrind # Arch, Manjaro, Garuda, etc 

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).

valgrind --leak-check=full \ --show-leak-kinds=all \ --track-origins=yes \ --verbose \ --log-file=valgrind-out.txt \ ./executable exampleParam1 

• —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:

HEAP SUMMARY: in use at exit: 0 bytes in 0 blocks total heap usage: 636 allocs, 636 frees, 25,393 bytes allocated All heap blocks were freed -- no leaks are possible ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0) ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0) 

I have a leak, but WHERE?

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

5 bytes in 1 blocks are definitely lost in loss record 1 of 1 at 0x4C29BE3: malloc (vg_replace_malloc.c:299) by 0x40053E: main (in /home/Peri461/Documents/executable) 

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):

gcc -o executable -std=c11 -Wall main.c # suppose it was this at first gcc -o executable -std=c11 -Wall -ggdb3 main.c # add -ggdb3 to it 

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.)

5 bytes in 1 blocks are definitely lost in loss record 1 of 1 at 0x4C29BE3: malloc (vg_replace_malloc.c:299) by 0x40053E: main (main.c:4) 

Techniques for Debugging Memory Leaks & Errors

• Make use of www.cplusplus.com! It has great documentation on C/C++ functions.
• General advice for memory leaks:
• Make sure your dynamically allocated memory does in fact get freed.
• Don’t allocate memory and forget to assign the pointer.
• Don’t overwrite a pointer with a new one unless the old memory is freed.
• General advice for memory errors:
• Access and write to addresses and indices you’re sure belong to you. Memory errors are different from leaks; they’re often just IndexOutOfBoundsException type problems.
• Don’t access or write to memory after freeing it.
• 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.
• If all else fails, try looking it up. Valgrind has documentation too!

A Look at Common Leaks and Errors

Watch your pointers

60 bytes in 1 blocks are definitely lost in loss record 1 of 1 at 0x4C2BB78: realloc (vg_replace_malloc.c:785) by 0x4005E4: resizeArray (main.c:12) by 0x40062E: main (main.c:19) 

#include #include struct _List < int32_t* data; int32_t length; >; typedef struct _List List; List* resizeArray(List* array) < int32_t* dPtr = array->data; dPtr = realloc(dPtr, 15 * sizeof(int32_t)); //doesn't update array->data return array; > int main() < List* array = calloc(1, sizeof(List)); array->data = calloc(10, sizeof(int32_t)); array = resizeArray(array); free(array->data); free(array); return 0; > 

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

1 errors in context 1 of 1: Invalid write of size 1 at 0x4005CA: main (main.c:10) Address 0x51f905a is 0 bytes after a block of size 26 alloc'd at 0x4C2B975: calloc (vg_replace_malloc.c:711) by 0x400593: main (main.c:5) 

#include #include int main() < char* alphabet = calloc(26, sizeof(char)); for(uint8_t i = 0; i < 26; i++) < *(alphabet + i) = 'A' + i; >*(alphabet + 26) = '\0'; //null-terminate the string? free(alphabet); return 0; > 

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

1 errors in context 1 of 1: Invalid read of size 1 at 0x400602: main (main.c:9) Address 0x51f90ba is 0 bytes after a block of size 26 alloc'd at 0x4C29BE3: malloc (vg_replace_malloc.c:299) by 0x4005E1: main (main.c:6) 

#include #include int main() < char* destination = calloc(27, sizeof(char)); char* source = malloc(26 * sizeof(char)); for(uint8_t i = 0; i < 27; i++) < *(destination + i) = *(source + i); //Look at the last iteration. >free(destination); free(source); return 0; > 

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.

The Open Source (U/Dys)topia

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

#include #include int main() < char* string = "< \"key\": \"value\" >"; json_error_t error; json_t* root = json_loads(string, 0, &error); //obtaining a pointer json_t* value = json_object_get(root, "key"); //obtaining a pointer printf("\"%s\" is the value field.\n", json_string_value(value)); //use value json_decref(value); //Do I free this pointer? json_decref(root); //What about this one? Does the order matter? return 0; > 

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 .

Why? The variable value is considered a «borrowed reference» in the Jansson API. Jansson keeps track of its memory for you, and you simply have to decref JSON structures independent of each other. The lesson here: read the documentation. Really. It’s sometimes hard to understand, but they’re telling you why these things happen. Instead, we have existing questions about this memory error.

SDL: a graphics and gaming library

#include "SDL2/SDL.h" int main(int argc, char* argv[]) < if (SDL_Init(SDL_INIT_VIDEO|SDL_INIT_AUDIO) != 0) < SDL_Log("Unable to initialize SDL: %s", SDL_GetError()); return 1; >SDL_Quit(); return 0; > 

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.

That might sound bizarre at first. Truth be told, graphics are messy and sometimes you have to accept some leaks as being part of the standard library. The lesson here: you need not quell every memory leak. Sometimes you just need to suppress the leaks because they’re known issues you can’t do anything about. (This is not my permission to ignore your own leaks!)

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!

Further Reading

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:

Источник

Ubuntu: valgrind: failed to start tool ‘memcheck’ for platform ‘amd64-linux’: No such file or directory

I have adjusted my bash file accordingly. I added the following path: /usr/bin/valgrind from using: which valgrind command and it’s still not working. Then I added the path: /usr/lib/valgrind and it is still not working. I think I am confused about the correct local directory for using Ubuntu. I am using:

export VALGRIND_LIB="/usr/lib/valgrind" 

9 Answers 9

I built valgrind from source and the posted answer did not work for me but this did:

./configure --prefix=$HOME/local/valgrind 

What I added to my ~/.bashrc

export VALGRIND_LIB=$HOME/local/valgrind/libexec/valgrind 

Seems like it needed libexec , not lib

For some reason, when I got 3.16.1 going in my arm/linux environment, /opt/lib/valgrind/ did the trick. Upgrading to 3.20.0, for some reason this error popped up and I had to edit my export to /opt/libexec/valgrind/

add «export VALGRIND_LIB=/usr/lib/valgrind/»(or /usr/local/lib/valgrind/ or other place where you install your valgrind lib) into ~/.bashrc

You shouldn’t need to set any environment variables, unless you are working on the code of Valgrind itself.

Just run /usr/bin/valgrind. This will then run /usr/lib/valgrind/memcheck-amd64-linux and preload some .so files in the same directory.

I don’t have much experience with Debian/Ubuntu, but if you installed it with snap then afaict you should use the —classic option.

I have confirmed that this fixes running with valgrind/3.17.0 . All that it is needed is the $PATH set, not VALGRIND_LIB . Setting VALGRIND_LIB breaks it. With valgrind/3.15.0 , the VALGRIND_LIB might be needed.

Also make sure you are using a 64bit valgrind for 64 bit executable, using a 32 bit valgrind on a 64 bit exe resuts in this error

/tmp>file /usr/bin/valgrind /usr/bin/valgrind: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.18, not stripped

/tmp>file a.out a.out: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.18, not stripped

/tmp>valgrind a.out valgrind: failed to start tool ‘memcheck’ for platform ‘amd64-linux’: No such file or directory

Источник