Bureaucrats, cc_docs_admin, cc_staff
2,314
edits
Valgrind: Difference between revisions
Jump to navigation
Jump to search
Marked this version for translation
No edit summary |
(Marked this version for translation) |
||
| Line 1: | Line 1: | ||
<languages /> | <languages /> | ||
<translate> | <translate> | ||
=Valgrind= | =Valgrind= <!--T:1--> | ||
<!--T:2--> | |||
[http://valgrind.org/ Valgrind] is a powerful debugging tool to detect bad memory usage. It can detect memory leaks, but also access to unallocated or deallocated memory, multiple deallocation or other bad memory usage. If your program ends with a ''segmentation fault'', ''broken pipe'' or ''bus error'', you most likely have such a problem in your code. Valgrind is installed on Compute Canada clusters as part of the base software distribution, so there is no need to load a module to use it. | [http://valgrind.org/ Valgrind] is a powerful debugging tool to detect bad memory usage. It can detect memory leaks, but also access to unallocated or deallocated memory, multiple deallocation or other bad memory usage. If your program ends with a ''segmentation fault'', ''broken pipe'' or ''bus error'', you most likely have such a problem in your code. Valgrind is installed on Compute Canada clusters as part of the base software distribution, so there is no need to load a module to use it. | ||
== Preparing your application == | == Preparing your application == <!--T:3--> | ||
To get useful information from [http://valgrind.org/ Valgrind], you first need to compile your code with debugging information enabled. With the most compilers, you do so by adding a "<tt>-g</tt>" option during compilation. | To get useful information from [http://valgrind.org/ Valgrind], you first need to compile your code with debugging information enabled. With the most compilers, you do so by adding a "<tt>-g</tt>" option during compilation. | ||
<!--T:4--> | |||
Some aggressive optimizations may yield false errors in Valgrind if they result in unsupported operations, which may occurr in certain mathematical libraries. Since you don't want to diagnose errors in those libraries, but rather errors in your own code, you should compile and link your code against non-optimized versions of the libraries (such as the Netlib implementation of BLAS/LAPACK) that do not use those operations. This is of course only to diagnose issues; when the time comes to run real simulations, you should link against optimized libraries. | Some aggressive optimizations may yield false errors in Valgrind if they result in unsupported operations, which may occurr in certain mathematical libraries. Since you don't want to diagnose errors in those libraries, but rather errors in your own code, you should compile and link your code against non-optimized versions of the libraries (such as the Netlib implementation of BLAS/LAPACK) that do not use those operations. This is of course only to diagnose issues; when the time comes to run real simulations, you should link against optimized libraries. | ||
== Using Valgrind == | == Using Valgrind == <!--T:5--> | ||
Once your code is compiled with the proper options, you execute it within Valgrind with the following command : | Once your code is compiled with the proper options, you execute it within Valgrind with the following command : | ||
{{Command|valgrind --tool{{=}}memcheck --leak-check{{=}}yes --show-reachable{{=}}yes ./your_program}} | {{Command|valgrind --tool{{=}}memcheck --leak-check{{=}}yes --show-reachable{{=}}yes ./your_program}} | ||
<!--T:6--> | |||
For more information about Valgrind, we recommend [http://www.cprogramming.com/debugging/valgrind.html this page]. | For more information about Valgrind, we recommend [http://www.cprogramming.com/debugging/valgrind.html this page]. | ||
=== Words of wisdom === | === Words of wisdom === <!--T:7--> | ||
* When you run your code in Valgrind, your application is executed within a virtual machine that validates every memory access. It will therefore run '''much slower''' than usual. Choose the size of the problem to test with caution, much smaller than what you would usually run. | * When you run your code in Valgrind, your application is executed within a virtual machine that validates every memory access. It will therefore run '''much slower''' than usual. Choose the size of the problem to test with caution, much smaller than what you would usually run. | ||
* You do not need to run the exact same problem that results in a segmentation fault to detect memory issues in your code. Very frequently, memory access problem, such as reading data outside of the bounds of an array, will go undetected for small size problems, but will cause a segmentation fault for large ones. Valgrind will detect even the slightest access outside of the bounds of an array. | * You do not need to run the exact same problem that results in a segmentation fault to detect memory issues in your code. Very frequently, memory access problem, such as reading data outside of the bounds of an array, will go undetected for small size problems, but will cause a segmentation fault for large ones. Valgrind will detect even the slightest access outside of the bounds of an array. | ||
=== Some typical error messages === | === Some typical error messages === <!--T:8--> | ||
Here are some problems that Valgrind will help you detect, and the error messages that it will produce. | Here are some problems that Valgrind will help you detect, and the error messages that it will produce. | ||
==== Memory leak ==== | ==== Memory leak ==== <!--T:9--> | ||
The error message for a memory leak will be given at the end of the program execution, and will look like this : | The error message for a memory leak will be given at the end of the program execution, and will look like this : | ||
</translate> | </translate> | ||
| Line 32: | Line 35: | ||
</syntaxhighlight> | </syntaxhighlight> | ||
<translate> | <translate> | ||
==== Invalid pointer access/out of bound errors ==== | ==== Invalid pointer access/out of bound errors ==== <!--T:10--> | ||
If you attempt to read or write to an unallocated pointer or outside of the allocated memory, the error message will look like this: | If you attempt to read or write to an unallocated pointer or outside of the allocated memory, the error message will look like this: | ||
</translate> | </translate> | ||
| Line 43: | Line 46: | ||
</syntaxhighlight> | </syntaxhighlight> | ||
<translate> | <translate> | ||
==== Usage of uninitialized variables ==== | ==== Usage of uninitialized variables ==== <!--T:11--> | ||
If you use an uninitialized variable, you will get an error message such as | If you use an uninitialized variable, you will get an error message such as | ||
</translate> | </translate> | ||