{"id":4986,"date":"2020-03-23T00:50:17","date_gmt":"2020-03-22T22:50:17","guid":{"rendered":"https:\/\/blue.pri.ee\/ttu\/?page_id=4986"},"modified":"2021-03-01T18:41:31","modified_gmt":"2021-03-01T16:41:31","slug":"fun-with-valgrind","status":"publish","type":"page","link":"https:\/\/blue.pri.ee\/ttu\/coding-guides\/fun-with-valgrind\/","title":{"rendered":"Fun with Valgrind"},"content":{"rendered":"<div id=\"ez-toc-container\" class=\"ez-toc-v2_0_82_2 counter-hierarchy ez-toc-counter ez-toc-grey ez-toc-container-direction\">\n<div class=\"ez-toc-title-container\">\n<span class=\"ez-toc-title-toggle\"><a href=\"#\" class=\"ez-toc-pull-right ez-toc-btn ez-toc-btn-xs ez-toc-btn-default ez-toc-toggle\" aria-label=\"Toggle Table of Content\"><span class=\"ez-toc-js-icon-con\"><span class=\"\"><span class=\"eztoc-hide\" style=\"display:none;\">Toggle<\/span><span class=\"ez-toc-icon-toggle-span\"><svg style=\"fill: #999;color:#999\" xmlns=\"http:\/\/www.w3.org\/2000\/svg\" class=\"list-377408\" width=\"20px\" height=\"20px\" viewBox=\"0 0 24 24\" fill=\"none\"><path d=\"M6 6H4v2h2V6zm14 0H8v2h12V6zM4 11h2v2H4v-2zm16 0H8v2h12v-2zM4 16h2v2H4v-2zm16 0H8v2h12v-2z\" fill=\"currentColor\"><\/path><\/svg><svg style=\"fill: #999;color:#999\" class=\"arrow-unsorted-368013\" xmlns=\"http:\/\/www.w3.org\/2000\/svg\" width=\"10px\" height=\"10px\" viewBox=\"0 0 24 24\" version=\"1.2\" baseProfile=\"tiny\"><path d=\"M18.2 9.3l-6.2-6.3-6.2 6.3c-.2.2-.3.4-.3.7s.1.5.3.7c.2.2.4.3.7.3h11c.3 0 .5-.1.7-.3.2-.2.3-.5.3-.7s-.1-.5-.3-.7zM5.8 14.7l6.2 6.3 6.2-6.3c.2-.2.3-.5.3-.7s-.1-.5-.3-.7c-.2-.2-.4-.3-.7-.3h-11c-.3 0-.5.1-.7.3-.2.2-.3.5-.3.7s.1.5.3.7z\"\/><\/svg><\/span><\/span><\/span><\/a><\/span><\/div>\n<nav><ul class='ez-toc-list ez-toc-list-level-1 ' ><li class='ez-toc-page-1 ez-toc-heading-level-1'><a class=\"ez-toc-link ez-toc-heading-1\" href=\"https:\/\/blue.pri.ee\/ttu\/coding-guides\/fun-with-valgrind\/#Introduction\" >Introduction<\/a><\/li><li class='ez-toc-page-1 ez-toc-heading-level-1'><a class=\"ez-toc-link ez-toc-heading-2\" href=\"https:\/\/blue.pri.ee\/ttu\/coding-guides\/fun-with-valgrind\/#Memcheck\" >Memcheck<\/a><ul class='ez-toc-list-level-2' ><li class='ez-toc-heading-level-2'><a class=\"ez-toc-link ez-toc-heading-3\" href=\"https:\/\/blue.pri.ee\/ttu\/coding-guides\/fun-with-valgrind\/#Example_1\" >Example 1<\/a><ul class='ez-toc-list-level-3' ><li class='ez-toc-heading-level-3'><a class=\"ez-toc-link ez-toc-heading-4\" href=\"https:\/\/blue.pri.ee\/ttu\/coding-guides\/fun-with-valgrind\/#Unconditional_jump_or_move\" >Unconditional jump or move<\/a><\/li><li class='ez-toc-page-1 ez-toc-heading-level-3'><a class=\"ez-toc-link ez-toc-heading-5\" href=\"https:\/\/blue.pri.ee\/ttu\/coding-guides\/fun-with-valgrind\/#Uninitialized_value\" >Uninitialized value<\/a><\/li><li class='ez-toc-page-1 ez-toc-heading-level-3'><a class=\"ez-toc-link ez-toc-heading-6\" href=\"https:\/\/blue.pri.ee\/ttu\/coding-guides\/fun-with-valgrind\/#Origins_of_uninitialized_values\" >Origins of uninitialized values<\/a><\/li><\/ul><\/li><li class='ez-toc-page-1 ez-toc-heading-level-2'><a class=\"ez-toc-link ez-toc-heading-7\" href=\"https:\/\/blue.pri.ee\/ttu\/coding-guides\/fun-with-valgrind\/#Example_2\" >Example 2<\/a><ul class='ez-toc-list-level-3' ><li class='ez-toc-heading-level-3'><a class=\"ez-toc-link ez-toc-heading-8\" href=\"https:\/\/blue.pri.ee\/ttu\/coding-guides\/fun-with-valgrind\/#Invalid_write\" >Invalid write<\/a><\/li><li class='ez-toc-page-1 ez-toc-heading-level-3'><a class=\"ez-toc-link ez-toc-heading-9\" href=\"https:\/\/blue.pri.ee\/ttu\/coding-guides\/fun-with-valgrind\/#Invalid_read_and_segmentation_fault\" >Invalid read and segmentation fault<\/a><\/li><li class='ez-toc-page-1 ez-toc-heading-level-3'><a class=\"ez-toc-link ez-toc-heading-10\" href=\"https:\/\/blue.pri.ee\/ttu\/coding-guides\/fun-with-valgrind\/#Memory_leak\" >Memory leak<\/a><\/li><\/ul><\/li><li class='ez-toc-page-1 ez-toc-heading-level-2'><a class=\"ez-toc-link ez-toc-heading-11\" href=\"https:\/\/blue.pri.ee\/ttu\/coding-guides\/fun-with-valgrind\/#Example_3\" >Example 3<\/a><ul class='ez-toc-list-level-3' ><li class='ez-toc-heading-level-3'><a class=\"ez-toc-link ez-toc-heading-12\" href=\"https:\/\/blue.pri.ee\/ttu\/coding-guides\/fun-with-valgrind\/#Indirectly_lost_memory\" >Indirectly lost memory<\/a><\/li><\/ul><\/li><li class='ez-toc-page-1 ez-toc-heading-level-2'><a class=\"ez-toc-link ez-toc-heading-13\" href=\"https:\/\/blue.pri.ee\/ttu\/coding-guides\/fun-with-valgrind\/#Example_4\" >Example 4<\/a><ul class='ez-toc-list-level-3' ><li class='ez-toc-heading-level-3'><a class=\"ez-toc-link ez-toc-heading-14\" href=\"https:\/\/blue.pri.ee\/ttu\/coding-guides\/fun-with-valgrind\/#Double_or_invalid_free\" >Double or invalid free<\/a><\/li><\/ul><\/li><li class='ez-toc-page-1 ez-toc-heading-level-2'><a class=\"ez-toc-link ez-toc-heading-15\" href=\"https:\/\/blue.pri.ee\/ttu\/coding-guides\/fun-with-valgrind\/#Overview_of_the_commands_for_the_Memcheck_tool\" >Overview of the commands for the Memcheck tool<\/a><\/li><\/ul><\/li><li class='ez-toc-page-1 ez-toc-heading-level-1'><a class=\"ez-toc-link ez-toc-heading-16\" href=\"https:\/\/blue.pri.ee\/ttu\/coding-guides\/fun-with-valgrind\/#_SGCheck\" >\u00a0SGCheck<\/a><\/li><\/ul><\/nav><\/div>\n<h1><span class=\"ez-toc-section\" id=\"Introduction\"><\/span>Introduction<span class=\"ez-toc-section-end\"><\/span><\/h1>\n<p>Valgrind is a programming tool for debugging memory related issues and memory profiling. When you work with dynamic memory allocation, you should be really careful about resources you use. Simple programs can be debugged by careful visual inspection of the code or by adding corresponding print statements here and there to check the state of the program. However, when the programs become bigger and more complex, the debugging process might require additional measures. Valgrind is one of the possible tools that provide help with memory debugging.<\/p>\n<p>Valgrind contains several tools for debugging and profiling. We will not go through all of them in this tutorial, however, we will only focus on those tools that are of particular interest for the Programming 2 course.<\/p>\n<h1><span class=\"ez-toc-section\" id=\"Memcheck\"><\/span>Memcheck<span class=\"ez-toc-section-end\"><\/span><\/h1>\n<p>The basic tool of Valgrind and the most useful tool when you start to work with dynamic memory allocation, because it detects memory-management errors. The tool checks all reads and writes to the memory, every call of malloc\/calloc\/realloc\/free functions. Memcheck can detect if the program tries to access the memory it should not (areas not yet allocated, that have been freed or where it does not have access to), uses uninitialized variables in calculations or comparison, if there are memory leaks, incorrect frees of memory blocks, etc.<\/p>\n<p>In order to debug your program using Memcheck, you will need to run it with the following command:<\/p>\n<pre class=\"toolbar:2 show-lang:2 nums:false lang:c highlight:0 decode:true\">valgrind --tool=memcheck --leak-check=yes .\/your_program_name\r\n<\/pre>\n<p>The leak-check option provides a detailed overview of the memory leaks. In order to get more detailed output from the valgrind, it is advisable to compile your program with -g flag. It will introduce debugging symbols to the program and allows to provide the line number where the error occurred to the Valgrind output.<\/p>\n<h2><span class=\"ez-toc-section\" id=\"Example_1\"><\/span>Example 1<span class=\"ez-toc-section-end\"><\/span><\/h2>\n<p>Let&#8217;s try to debug a simple program.<\/p>\n<pre class=\"tab-convert:true lang:c decode:true\" title=\"memory_check.c\">#include &lt;stdio.h&gt;\r\n#include &lt;stdlib.h&gt;\r\n\r\nint main(void){\r\n    int i;\r\n    int array[5];\r\n\r\n    while(i &lt;= 5){\r\n        array[i] = i;\r\n        printf(\"El. %d: %d\\n\", i, array[i]);\r\n        i++;\r\n    }\r\n\r\n    return 0;\r\n}<\/pre>\n<p>This is how the Valgrind report will look like:<\/p>\n<p><a href=\"https:\/\/blue.pri.ee\/ttu\/wp-content\/uploads\/2020\/03\/simple_example_full.png\"><img loading=\"lazy\" decoding=\"async\" class=\"alignnone wp-image-4992 size-full\" src=\"https:\/\/blue.pri.ee\/ttu\/wp-content\/uploads\/2020\/03\/simple_example_full.png\" alt=\"\" width=\"932\" height=\"1030\" srcset=\"https:\/\/blue.pri.ee\/ttu\/wp-content\/uploads\/2020\/03\/simple_example_full.png 932w, https:\/\/blue.pri.ee\/ttu\/wp-content\/uploads\/2020\/03\/simple_example_full-271x300.png 271w, https:\/\/blue.pri.ee\/ttu\/wp-content\/uploads\/2020\/03\/simple_example_full-768x849.png 768w, https:\/\/blue.pri.ee\/ttu\/wp-content\/uploads\/2020\/03\/simple_example_full-927x1024.png 927w\" sizes=\"auto, (max-width: 932px) 100vw, 932px\" \/><\/a><\/p>\n<p>Let\u2019s go through the report and see what information about the program we can get from it. First of all, we can get an ID number assigned to the process, it is the number on the left, though it is not important for us.<\/p>\n<p><a href=\"https:\/\/blue.pri.ee\/ttu\/wp-content\/uploads\/2020\/03\/simple_example_cond_jump.png\"><img loading=\"lazy\" decoding=\"async\" class=\"alignnone size-full wp-image-4993\" src=\"https:\/\/blue.pri.ee\/ttu\/wp-content\/uploads\/2020\/03\/simple_example_cond_jump.png\" alt=\"\" width=\"932\" height=\"42\" srcset=\"https:\/\/blue.pri.ee\/ttu\/wp-content\/uploads\/2020\/03\/simple_example_cond_jump.png 932w, https:\/\/blue.pri.ee\/ttu\/wp-content\/uploads\/2020\/03\/simple_example_cond_jump-300x14.png 300w, https:\/\/blue.pri.ee\/ttu\/wp-content\/uploads\/2020\/03\/simple_example_cond_jump-768x35.png 768w\" sizes=\"auto, (max-width: 932px) 100vw, 932px\" \/><\/a><\/p>\n<h3><span class=\"ez-toc-section\" id=\"Unconditional_jump_or_move\"><\/span>Unconditional jump or move<span class=\"ez-toc-section-end\"><\/span><\/h3>\n<p>Jump or move is the computer instruction (when your C code is compiled into a machine code, your program becomes a list of such instructions that are executed sequentially) that indicates the transition to some place in the program. Jumps may be conditional and unconditional. Conditional jumps correspond to if statements, while and for loop conditional statements. This error refers to the <code>while(i &lt;= 5)<\/code> statement, where we compare uninitialized variable <code>i<\/code> with the number 5, which potentially might cause problems during the process execution &#8211; the program might not enter the while loop at all.<\/p>\n<h3><span class=\"ez-toc-section\" id=\"Uninitialized_value\"><\/span>Uninitialized value<span class=\"ez-toc-section-end\"><\/span><\/h3>\n<p>Note that each error description is followed by the stack trace, showing where the problem occurred. It is a chain of function calls, where the topmost function indicates the actual error location and the one in the bottom is in most cases the main function.<\/p>\n<p><a href=\"https:\/\/blue.pri.ee\/ttu\/wp-content\/uploads\/2020\/03\/simple_example_uninit_use.png\"><img loading=\"lazy\" decoding=\"async\" class=\"alignnone size-full wp-image-5000\" src=\"https:\/\/blue.pri.ee\/ttu\/wp-content\/uploads\/2020\/03\/simple_example_uninit_use.png\" alt=\"\" width=\"932\" height=\"92\" srcset=\"https:\/\/blue.pri.ee\/ttu\/wp-content\/uploads\/2020\/03\/simple_example_uninit_use.png 932w, https:\/\/blue.pri.ee\/ttu\/wp-content\/uploads\/2020\/03\/simple_example_uninit_use-300x30.png 300w, https:\/\/blue.pri.ee\/ttu\/wp-content\/uploads\/2020\/03\/simple_example_uninit_use-768x76.png 768w\" sizes=\"auto, (max-width: 932px) 100vw, 932px\" \/><\/a><\/p>\n<p>Those errors corresponds to the usage of uninitialized variable <code>i<\/code> in array elements assignment and in the <code>printf()<\/code> function.\u00a0 Valgrind defines the error as the usage of uninitialized value of size 8, however, on my machine integer is 4 bytes. What does this mean? Valgrind refers to a pointer (an address actually). I use 64-bit system, therefore, each address value is 8 bytes. Remember what does the index of an array element mean. It is an offset to the starting address of an array, where each element of an array is accessed the following way:<\/p>\n<pre class=\"toolbar:2 nums:false lang:c decode:true \">element_address = starting_address + index * element_size.<\/pre>\n<p>Hence the first element has index 0. Whenever we are trying to access array elements to either get or set their value, we are doing either read or write operation to the address of the element. Internally <code>array[i]<\/code> is always represented as <code>(array + i)<\/code>. When <code>i<\/code> is used uninitialized for the memory address calculation, we get an uninitialized address value.<\/p>\n<p>Notice that only use of uninitialized value on lines 9 and 10 was reported. The statement <code>i++<\/code> on the line 11, which also used the uninitialized value of <code>i<\/code> for the calculation, was not reported. Valgrind keeps track of every uninitialized variable, however, report its use only when it becomes visible and affects the flow of the program.<\/p>\n<p>Then several errors connected to the same uninitialized variable that happen inside the <code>printf()<\/code> function are reported. Since we already identified the problem, they are not interesting for us.<\/p>\n<p>At the end of Valgrind report we have a heap and memory leaks summary.<\/p>\n<p><a href=\"https:\/\/blue.pri.ee\/ttu\/wp-content\/uploads\/2020\/03\/simple_example_heap_leak.png\"><img loading=\"lazy\" decoding=\"async\" class=\"alignnone size-full wp-image-5001\" src=\"https:\/\/blue.pri.ee\/ttu\/wp-content\/uploads\/2020\/03\/simple_example_heap_leak.png\" alt=\"\" width=\"932\" height=\"93\" srcset=\"https:\/\/blue.pri.ee\/ttu\/wp-content\/uploads\/2020\/03\/simple_example_heap_leak.png 932w, https:\/\/blue.pri.ee\/ttu\/wp-content\/uploads\/2020\/03\/simple_example_heap_leak-300x30.png 300w, https:\/\/blue.pri.ee\/ttu\/wp-content\/uploads\/2020\/03\/simple_example_heap_leak-768x77.png 768w\" sizes=\"auto, (max-width: 932px) 100vw, 932px\" \/><\/a><\/p>\n<p>No memory leaks in this program, everything is fine.<\/p>\n<p>In the heap report there is one memory allocation, though we have not allocated any memory explicitly. Where did it come from? It was an internal allocation done by <code>printf()<\/code> function for the standard output buffer.<\/p>\n<h3><span class=\"ez-toc-section\" id=\"Origins_of_uninitialized_values\"><\/span>Origins of uninitialized values<span class=\"ez-toc-section-end\"><\/span><\/h3>\n<p>In this simple example we can easily track the uninitialized variable ourselves, however, in more tricky cases it is possible to use <code>--track-origins=yes<\/code> option to see where uninitialized values are coming from.<\/p>\n<p><a href=\"https:\/\/blue.pri.ee\/ttu\/wp-content\/uploads\/2020\/03\/simple_example_uninit_alloc.png\"><img loading=\"lazy\" decoding=\"async\" class=\"alignnone size-full wp-image-4994\" src=\"https:\/\/blue.pri.ee\/ttu\/wp-content\/uploads\/2020\/03\/simple_example_uninit_alloc.png\" alt=\"\" width=\"932\" height=\"80\" srcset=\"https:\/\/blue.pri.ee\/ttu\/wp-content\/uploads\/2020\/03\/simple_example_uninit_alloc.png 932w, https:\/\/blue.pri.ee\/ttu\/wp-content\/uploads\/2020\/03\/simple_example_uninit_alloc-300x26.png 300w, https:\/\/blue.pri.ee\/ttu\/wp-content\/uploads\/2020\/03\/simple_example_uninit_alloc-768x66.png 768w\" sizes=\"auto, (max-width: 932px) 100vw, 932px\" \/><\/a><\/p>\n<p>Valgrind defines four origins for uninitialized values: a heap block, a stack allocation, a client request, or other source. If an uninitialized value originates from a heap block, Memcheck shows where the block was allocated. In case of a stack allocation (statically allocated variable), Memcheck can only tell which function allocated the value. It is a good start anyway, especially if you have a big program. Make sure to carefully check all local variables declared in the function.<\/p>\n<p>As you can see, the output of the program is printed in-between the Valgrind report. To separate them, it is possible to write Valgrind report to a file with the <code>--log-file=filename<\/code> option.<\/p>\n<p>We checked all the errors reported, however, there is a problem in our program that Memcheck cannot detect: the out-of-range read or write to the array that is allocated statically. When <code>i<\/code> becomes 5, the program writes a value to the <code>array[5]<\/code> element, which is out of range of our array. It is possible to track such errors with Valgrind tools as well, however, we will come back to it later.<\/p>\n<h2><span class=\"ez-toc-section\" id=\"Example_2\"><\/span>Example 2<span class=\"ez-toc-section-end\"><\/span><\/h2>\n<p>This was a simple example. Let us try the more complicated one.<\/p>\n<pre class=\"lang:c decode:true\" title=\"memory_check.c\">#include &lt;stdio.h&gt;\r\n#include &lt;stdlib.h&gt;\r\n#include &lt;string.h&gt;\r\n\r\n#define MAX_LENGTH 20\r\n#define MAX_SIZE 3\r\n\r\ntypedef struct data{\r\n\tchar name[MAX_LENGTH];\r\n\tint votes_num;\r\n} data;\r\n\r\nFILE *openFile(char *fileName, char *mode);\r\nint readFile(FILE *pfile, data *massiv);\r\nvoid printData(data *massiv, int records);\r\n\r\nint main(void){\r\n\t\r\n\tFILE *input = openFile(\"votes.txt\",\"r\");\t\r\n\tdata *votes = NULL;\t\r\n\tint recordsNumber = readFile(input,votes);\r\n\tprintData(votes,recordsNumber);\r\n\tfree(votes);\r\n\t\r\n\treturn 0;\r\n}\r\n\r\nFILE *openFile(char *fileName, char *mode){\r\n\t\r\n\tFILE *pf = fopen(fileName, mode);\r\n\tif(pf == NULL){\r\n\t\tperror(\"Can't open input file\");\r\n\t\texit(1);\r\n\t}\t\r\n\treturn pf;\r\n}\r\n\r\nint readFile(FILE *pfile, data *massiv){\r\n\r\n\tint i = 0;\r\n\t\r\n\t\/\/ Allocating memory for an array of three data structs\r\n\t\/\/ What will happen with this pointer at the end of the function?\r\n\tmassiv = malloc(sizeof(data) * MAX_SIZE);\r\n\tif(massiv == NULL){\r\n\t\tperror(\"Memory allocation failed\");\r\n\t\texit(1);\r\n\t}\r\n\t\r\n\t\/\/ Reading through the file until there are two values on the line\r\n\t\/\/ However, there is a mistake here. What important condition is missing?\r\n\twhile(fscanf(pfile,\"%s %d\", (massiv + i)-&gt;name, &amp;((massiv + i)-&gt;votes_num)) == 2){\r\n\t\ti++;\r\n\t}\r\n\t\r\n\treturn i;\r\n}\r\n\r\nvoid printData(data *massiv, int records){\r\n\t\r\n\tint i;\t\r\n\tfor(i = 0; i &lt; records; i++){\r\n\t\tprintf(\"Party: %s. Number of votes: %d\\n\", massiv[i].name, massiv[i].votes_num);\r\n\t}\r\n}<\/pre>\n<pre class=\"lang:c highlight:0 decode:true\" title=\"votes.txt\">Democrats 450\r\nRepublicans 34\r\nNationals 256\r\nLiberals 123<\/pre>\n<p>The Valgrind report for this program looks more interesting. We even got a segmentation fault. But lets go through it one by one.<\/p>\n<p><a href=\"https:\/\/blue.pri.ee\/ttu\/wp-content\/uploads\/2020\/03\/complex_example_full.png\"><img loading=\"lazy\" decoding=\"async\" class=\"alignnone size-full wp-image-4995\" src=\"https:\/\/blue.pri.ee\/ttu\/wp-content\/uploads\/2020\/03\/complex_example_full.png\" alt=\"\" width=\"932\" height=\"1299\" srcset=\"https:\/\/blue.pri.ee\/ttu\/wp-content\/uploads\/2020\/03\/complex_example_full.png 932w, https:\/\/blue.pri.ee\/ttu\/wp-content\/uploads\/2020\/03\/complex_example_full-215x300.png 215w, https:\/\/blue.pri.ee\/ttu\/wp-content\/uploads\/2020\/03\/complex_example_full-768x1070.png 768w, https:\/\/blue.pri.ee\/ttu\/wp-content\/uploads\/2020\/03\/complex_example_full-735x1024.png 735w\" sizes=\"auto, (max-width: 932px) 100vw, 932px\" \/><\/a><\/p>\n<h3><span class=\"ez-toc-section\" id=\"Invalid_write\"><\/span>Invalid write<span class=\"ez-toc-section-end\"><\/span><\/h3>\n<p>We have several records indicating invalid write somehow connected to the memory allocation done in the <code>readFile()<\/code> function. Invalid write happens when the program tries to write something to the memory that it does not have access to.<\/p>\n<p><a href=\"https:\/\/blue.pri.ee\/ttu\/wp-content\/uploads\/2020\/03\/complex_example_invalid_write.png\"><img loading=\"lazy\" decoding=\"async\" class=\"alignnone size-full wp-image-5002\" src=\"https:\/\/blue.pri.ee\/ttu\/wp-content\/uploads\/2020\/03\/complex_example_invalid_write.png\" alt=\"\" width=\"932\" height=\"362\" srcset=\"https:\/\/blue.pri.ee\/ttu\/wp-content\/uploads\/2020\/03\/complex_example_invalid_write.png 932w, https:\/\/blue.pri.ee\/ttu\/wp-content\/uploads\/2020\/03\/complex_example_invalid_write-300x117.png 300w, https:\/\/blue.pri.ee\/ttu\/wp-content\/uploads\/2020\/03\/complex_example_invalid_write-768x298.png 768w\" sizes=\"auto, (max-width: 932px) 100vw, 932px\" \/><\/a><\/p>\n<p>We have invalid write of size 1, which is a size of a character. Valgrind reports that the program wants to write the first character from the party name to an invalid location. Valgrind also reports that the invalid address the program is trying to write to is located 0 bytes after the block of 72 bytes allocated by <code>malloc()<\/code> function. This means, that we allocated 72 bytes for three data structs, but then tried to access the fourth one. Indeed, if you look carefully at the code, you will see that the while loop in <code>readFile()<\/code> function does not check for the limits. We allocated the memory only for three elements of type data struct, therefore, we can only store three records from the file, we cannot store the fourth one. This way, Valgrind can detect the out-of-order read or write to the dynamically allocated array.<\/p>\n<p>Invalid write of size 4, which is a size of an integer, is obviously an attempt to write the number of votes. But what is the second invalid write of size 1 that the program tries to write 8 bytes after the allocated block for three structures? If you check the text file, the name of the fourth party <em>Liberals<\/em> has exactly 8 symbols. So what does the program write after those 8 symbols? What should be at the end of every string? A null character <code>'\\0'<\/code> of course.<\/p>\n<h3><span class=\"ez-toc-section\" id=\"Invalid_read_and_segmentation_fault\"><\/span>Invalid read and segmentation fault<span class=\"ez-toc-section-end\"><\/span><\/h3>\n<p>Now, let\u2019s check the next error.<\/p>\n<p><a href=\"https:\/\/blue.pri.ee\/ttu\/wp-content\/uploads\/2020\/03\/complex_example_invalid_read_014.png\"><img loading=\"lazy\" decoding=\"async\" class=\"alignnone size-full wp-image-5003\" src=\"https:\/\/blue.pri.ee\/ttu\/wp-content\/uploads\/2020\/03\/complex_example_invalid_read_014.png\" alt=\"\" width=\"932\" height=\"273\" srcset=\"https:\/\/blue.pri.ee\/ttu\/wp-content\/uploads\/2020\/03\/complex_example_invalid_read_014.png 932w, https:\/\/blue.pri.ee\/ttu\/wp-content\/uploads\/2020\/03\/complex_example_invalid_read_014-300x88.png 300w, https:\/\/blue.pri.ee\/ttu\/wp-content\/uploads\/2020\/03\/complex_example_invalid_read_014-768x225.png 768w\" sizes=\"auto, (max-width: 932px) 100vw, 932px\" \/><\/a><\/p>\n<p>Invalid read, as you can guess, occurs when the program tries to read the data from the invalid address. Memcheck cannot identify the address, however, we can try to trace the problem ourselves. At line 63 we are printing the values we have written to the data struct array, but what is wrong? We created a pointer of type data, we allocated the memory for the data array in the function <code>readFile()<\/code>, we assigned the starting address of the allocated memory block to that pointer, we filled that array. Why can&#8217;t we access this memory in the <code>printData()<\/code> function? Because the moment we left the <code>readFile()<\/code> function we lost the address of the memory allocated. We passed votes pointer by value not by reference, therefore, any changes we made to this variable in the <code>readFile()<\/code> were only valid inside this function.<\/p>\n<p>And this is actually why the program crashed with a segmentation fault. Note that Valgrind does not stop your program from accessing invalid memory region and crashing, nor does it stop the program from using uninitialized values for example, but the Valgrind can point out where the problem occurred.<\/p>\n<h3><span class=\"ez-toc-section\" id=\"Memory_leak\"><\/span>Memory leak<span class=\"ez-toc-section-end\"><\/span><\/h3>\n<p>Now, let\u2019s check heap summary and leak summary.<\/p>\n<p><a href=\"https:\/\/blue.pri.ee\/ttu\/wp-content\/uploads\/2020\/03\/complex_example_heap_leak.png\"><img loading=\"lazy\" decoding=\"async\" class=\"alignnone size-full wp-image-5004\" src=\"https:\/\/blue.pri.ee\/ttu\/wp-content\/uploads\/2020\/03\/complex_example_heap_leak.png\" alt=\"\" width=\"932\" height=\"383\" srcset=\"https:\/\/blue.pri.ee\/ttu\/wp-content\/uploads\/2020\/03\/complex_example_heap_leak.png 932w, https:\/\/blue.pri.ee\/ttu\/wp-content\/uploads\/2020\/03\/complex_example_heap_leak-300x123.png 300w, https:\/\/blue.pri.ee\/ttu\/wp-content\/uploads\/2020\/03\/complex_example_heap_leak-768x316.png 768w\" sizes=\"auto, (max-width: 932px) 100vw, 932px\" \/><\/a><\/p>\n<p>What do we get from this summary? We have 3 memory allocations, but only 1 allocated block was freed. We lost a memory block of 72 bytes, that we allocated in the <code>readFile()<\/code> function for the data array, because we lost a pointer to the starting address of that block and never freed it. This is identified by Valgrind as a <strong>Definitely lost<\/strong> block. Take a note that leaks are checked by Valgrind at the end of the program, at that moment the pointer to the data struct array is long gone. And we have a mysterious block of 552 bytes that is still reachable. <strong>Still reachable<\/strong> means that the pointer to the starting address of that block is found. But how can we identify this block? To get more information, we can rerun the Valgrind with <code>--leak-check=full --show-leak-kinds=all<\/code> options.<\/p>\n<p><a href=\"https:\/\/blue.pri.ee\/ttu\/wp-content\/uploads\/2020\/03\/complex_example_fopen_alloc-1.png\"><img loading=\"lazy\" decoding=\"async\" class=\"alignnone size-full wp-image-5005\" src=\"https:\/\/blue.pri.ee\/ttu\/wp-content\/uploads\/2020\/03\/complex_example_fopen_alloc-1.png\" alt=\"\" width=\"932\" height=\"131\" srcset=\"https:\/\/blue.pri.ee\/ttu\/wp-content\/uploads\/2020\/03\/complex_example_fopen_alloc-1.png 932w, https:\/\/blue.pri.ee\/ttu\/wp-content\/uploads\/2020\/03\/complex_example_fopen_alloc-1-300x42.png 300w, https:\/\/blue.pri.ee\/ttu\/wp-content\/uploads\/2020\/03\/complex_example_fopen_alloc-1-768x108.png 768w\" sizes=\"auto, (max-width: 932px) 100vw, 932px\" \/><\/a><\/p>\n<p>Now we can see that these 552 bytes were allocated by <code>fopen()<\/code> function for the file buffer, however, since we forgot to close the file, this memory was not freed.<\/p>\n<h2><span class=\"ez-toc-section\" id=\"Example_3\"><\/span>Example 3<span class=\"ez-toc-section-end\"><\/span><\/h2>\n<h3><span class=\"ez-toc-section\" id=\"Indirectly_lost_memory\"><\/span>Indirectly lost memory<span class=\"ez-toc-section-end\"><\/span><\/h3>\n<p>We have identified two memory leak kinds, let\u2019s check the others. <strong>Indirectly lost<\/strong> means that the block is unreachable not because there is no pointer to its starting address but because all the blocks pointing to it are lost. Consider the following code:<\/p>\n<pre class=\"lang:c decode:true\" title=\"memory_check.c\">#include &lt;stdio.h&gt;\r\n#include &lt;stdlib.h&gt;\r\n#include &lt;string.h&gt;\r\n\r\n#define MAX_LENGTH 20\r\n#define MAX_SIZE 4\r\n\r\n\/\/ Structure definition has changed\r\n\/\/ name is not an array now, it is a pointer\r\n\/\/ And we will allocate memory for each name\r\ntypedef struct data{\r\n\tchar *name;\r\n\tint votes_num;\r\n} data;\r\n\r\nFILE *openFile(char *fileName, char *mode);\r\nint readFile(FILE *pfile, data *massiv);\r\nvoid printData(data *massiv, int records);\r\n\r\nint main(void){\r\n\t\r\n\tFILE *input = openFile(\"votes.txt\",\"r\");\t\r\n\tdata *votes = NULL;\t\r\n\tint recordsNumber = readFile(input,votes);\r\n\tprintData(votes,recordsNumber);\r\n\tfree(votes);\r\n\t\r\n\treturn 0;\r\n}\r\n\r\nFILE *openFile(char *fileName, char *mode){\r\n\t\r\n\tFILE *pf = fopen(fileName, mode);\r\n\tif(pf == NULL){\r\n\t\tperror(\"Can't open input file\");\r\n\t\texit(1);\r\n\t}\r\n\t\r\n\treturn pf;\r\n}\r\n\r\nint readFile(FILE *pfile, data *massiv){\r\n\r\n\tchar nameBuffer[MAX_LENGTH];\r\n\tint i = 0;\r\n\t\r\n\t\/\/ Allocating memory for an array of three data structs\r\n\tmassiv = malloc(sizeof(data) * MAX_SIZE);\r\n\tif(massiv == NULL){\r\n\t\tperror(\"Memory allocation failed\\n\");\r\n\t\texit(1);\r\n\t}\r\n\t\r\n\t\/\/ Reading through the file until there are two values on the line\r\n\t\/\/ We are reading a party name in a buffer now and then allocate memory for it\r\n\twhile(fscanf(pfile,\"%s %d\", nameBuffer, &amp;((massiv + i)-&gt;votes_num)) == 2){\r\n\t\t(massiv + i)-&gt;name = malloc(sizeof(char) * (strlen(nameBuffer)+1));\r\n\t\tstrcpy((massiv + i)-&gt;name, nameBuffer);\r\n\t\ti++;\r\n\t}\r\n\t\r\n\treturn i;\r\n}\r\n\r\nvoid printData(data *massiv, int records){\r\n\t\r\n\tint i;\t\r\n\tfor(i = 0; i &lt; records; i++){\r\n\t\tprintf(\"Party: %s. Number of votes: %d\\n\", massiv[i].name, massiv[i].votes_num);\r\n\t}\r\n}<\/pre>\n<p>In the data struct, instead of a statically defined char array <code>name<\/code> we define a char pointer, and later in <code>readFile()<\/code> function allocate memory for each party name. The memory block allocated for the data struct array will be definitely lost, but memory blocks for those strings containing political party names will be indefinitely lost, because the block that contained the pointers to these elements is lost.<\/p>\n<p><a href=\"https:\/\/blue.pri.ee\/ttu\/wp-content\/uploads\/2020\/03\/complex_example_indirect_lost.png\"><img loading=\"lazy\" decoding=\"async\" class=\"alignnone size-full wp-image-4997\" src=\"https:\/\/blue.pri.ee\/ttu\/wp-content\/uploads\/2020\/03\/complex_example_indirect_lost.png\" alt=\"\" width=\"932\" height=\"96\" srcset=\"https:\/\/blue.pri.ee\/ttu\/wp-content\/uploads\/2020\/03\/complex_example_indirect_lost.png 932w, https:\/\/blue.pri.ee\/ttu\/wp-content\/uploads\/2020\/03\/complex_example_indirect_lost-300x31.png 300w, https:\/\/blue.pri.ee\/ttu\/wp-content\/uploads\/2020\/03\/complex_example_indirect_lost-768x79.png 768w\" sizes=\"auto, (max-width: 932px) 100vw, 932px\" \/><\/a><\/p>\n<p><a href=\"https:\/\/blue.pri.ee\/ttu\/wp-content\/uploads\/2020\/03\/complex_example_v2_leak_summary.png\"><img loading=\"lazy\" decoding=\"async\" class=\"alignnone size-full wp-image-5006\" src=\"https:\/\/blue.pri.ee\/ttu\/wp-content\/uploads\/2020\/03\/complex_example_v2_leak_summary.png\" alt=\"\" width=\"779\" height=\"115\" srcset=\"https:\/\/blue.pri.ee\/ttu\/wp-content\/uploads\/2020\/03\/complex_example_v2_leak_summary.png 779w, https:\/\/blue.pri.ee\/ttu\/wp-content\/uploads\/2020\/03\/complex_example_v2_leak_summary-300x44.png 300w, https:\/\/blue.pri.ee\/ttu\/wp-content\/uploads\/2020\/03\/complex_example_v2_leak_summary-768x113.png 768w\" sizes=\"auto, (max-width: 779px) 100vw, 779px\" \/><\/a><\/p>\n<p><strong>Possibly lost<\/strong> means that the pointer to a memory block was found, however, it is a pointer to the middle of the block. There are several ways how this can occur: e.g. the pointer initially was pointing to the start of the block but was moved along deliberately or accidentally, or the pointer value might be completely random and points to the allocated memory block by accident.<\/p>\n<h2><span class=\"ez-toc-section\" id=\"Example_4\"><\/span>Example 4<span class=\"ez-toc-section-end\"><\/span><\/h2>\n<p>Lets check the last example. It is small and simple.<\/p>\n<pre class=\"lang:c decode:true \">#include &lt;stdio.h&gt;\r\n#include &lt;stdlib.h&gt;\r\n\r\n#define SIZE 10\r\n\r\nint main(void){\r\n\t\r\n\tint i;\t\r\n\tint *pInt = (int *)malloc(sizeof(int) * SIZE);\r\n\t\r\n\tfor(i = 0; i &lt; SIZE; i++){\r\n\t\t*(pInt + i) = i;\r\n\t}\r\n\t\r\n\tfree(pInt);\r\n\tfree(pInt);\r\n\t\r\n\tfloat *pFloat = (float *)malloc(sizeof(float) * SIZE);\r\n\tfree(pInt);\r\n\tchar *pChar = (char *)malloc(sizeof(char) * SIZE);\r\n\tprintf(\"pFloat = %p\\n\", pFloat);\r\n\tprintf(\"pChar = %p\\n\", pChar);\r\n\t\r\n\tfree(pFloat);\r\n\tfree(pChar);\r\n\t\r\n\treturn 0;\r\n}<\/pre>\n<p>Valgrind reports only one error called invalid free.<\/p>\n<p><a href=\"https:\/\/blue.pri.ee\/ttu\/wp-content\/uploads\/2021\/02\/012.png\"><img loading=\"lazy\" decoding=\"async\" class=\"alignnone size-full wp-image-5769\" src=\"https:\/\/blue.pri.ee\/ttu\/wp-content\/uploads\/2021\/02\/012.png\" alt=\"\" width=\"957\" height=\"200\" srcset=\"https:\/\/blue.pri.ee\/ttu\/wp-content\/uploads\/2021\/02\/012.png 957w, https:\/\/blue.pri.ee\/ttu\/wp-content\/uploads\/2021\/02\/012-300x63.png 300w, https:\/\/blue.pri.ee\/ttu\/wp-content\/uploads\/2021\/02\/012-768x161.png 768w\" sizes=\"auto, (max-width: 957px) 100vw, 957px\" \/><\/a><\/p>\n<h3><span class=\"ez-toc-section\" id=\"Double_or_invalid_free\"><\/span>Double or invalid free<span class=\"ez-toc-section-end\"><\/span><\/h3>\n<p>Invalid free occurs when program is calling free() function on already freed memory location. According to C specification, invalid free leads to undefined behavior. This can cause program to crash or in some circumstances two later calls to malloc() can return the same pointer, because it corrupts the state of the memory manager. What happened in my case? On Linux, program crashed. On Windows, pFloat and pChar actually got the same address. If you want to avoid such situation, set an already freed pointer to NULL.<\/p>\n<p><a href=\"https:\/\/blue.pri.ee\/ttu\/wp-content\/uploads\/2021\/03\/invalid_free_windows.png\"><img loading=\"lazy\" decoding=\"async\" class=\"alignnone size-full wp-image-5779\" src=\"https:\/\/blue.pri.ee\/ttu\/wp-content\/uploads\/2021\/03\/invalid_free_windows.png\" alt=\"\" width=\"799\" height=\"70\" srcset=\"https:\/\/blue.pri.ee\/ttu\/wp-content\/uploads\/2021\/03\/invalid_free_windows.png 799w, https:\/\/blue.pri.ee\/ttu\/wp-content\/uploads\/2021\/03\/invalid_free_windows-300x26.png 300w, https:\/\/blue.pri.ee\/ttu\/wp-content\/uploads\/2021\/03\/invalid_free_windows-768x67.png 768w\" sizes=\"auto, (max-width: 799px) 100vw, 799px\" \/><\/a><\/p>\n<h2><span class=\"ez-toc-section\" id=\"Overview_of_the_commands_for_the_Memcheck_tool\"><\/span>Overview of the commands for the Memcheck tool<span class=\"ez-toc-section-end\"><\/span><\/h2>\n<p>Compile your program with debugging flag:<\/p>\n<pre class=\"toolbar:2 show-lang:2 nums:false lang:c highlight:0 decode:true\">gcc -g -o your_program_name your_program_code.c<\/pre>\n<p>The basic command, will give the leak summary:<\/p>\n<pre class=\"toolbar:2 show-lang:2 nums:false lang:c highlight:0 decode:true\">valgrind --tool=memcheck --leak-check=yes .\/your_program_name<\/pre>\n<p>Detailed information on leaks:<\/p>\n<pre class=\"toolbar:2 show-lang:2 nums:false lang:c highlight:0 decode:true\">valgrind --tool=memcheck --leak-check=full --show-leak-kinds=all .\/your_program_name<\/pre>\n<p>Track the origin of the uninitialised values:<\/p>\n<pre class=\"toolbar:2 show-lang:2 nums:false lang:c highlight:0 decode:true\">valgrind --tool=memcheck --track-origins=yes .\/your_program_name<\/pre>\n<p>Write Valgrind output to a file:<\/p>\n<pre class=\"toolbar:2 show-lang:2 nums:false lang:c highlight:0 decode:true\">valgrind --tool=memcheck --leak-check=full --log-file=filename .\/your_program_name<\/pre>\n<h1><span class=\"ez-toc-section\" id=\"_SGCheck\"><\/span>\u00a0SGCheck<span class=\"ez-toc-section-end\"><\/span><\/h1>\n<p>Remember we said that Memcheck cannot check the bounds for statically allocated arrays, however, there is a tool in Valgrind toolbox that has such capabilities. SGCheck is a stack and global array overrun detector.\u00a0<span style=\"background-color: #ffd11a;\">It is important to note that this is an experimental tool; it uses technique and assumptions that have certain limitations and can produce false positive or false negative results.<\/span> It also runs slower than Memcheck. You do not need to use it within the course, Memcheck is more important for us, however, let\u2019s look at how it works.<\/p>\n<p>To use SGCheck, run the program with the command:<\/p>\n<pre class=\"toolbar:2 show-lang:2 nums:false lang:c highlight:0 decode:true\">valgrind --tool=exp-sgcheck .\/your_program_name<\/pre>\n<p><a href=\"https:\/\/blue.pri.ee\/ttu\/wp-content\/uploads\/2020\/03\/simple_example_sdcheck.png\"><img loading=\"lazy\" decoding=\"async\" class=\"alignnone size-full wp-image-4998\" src=\"https:\/\/blue.pri.ee\/ttu\/wp-content\/uploads\/2020\/03\/simple_example_sdcheck.png\" alt=\"\" width=\"932\" height=\"379\" srcset=\"https:\/\/blue.pri.ee\/ttu\/wp-content\/uploads\/2020\/03\/simple_example_sdcheck.png 932w, https:\/\/blue.pri.ee\/ttu\/wp-content\/uploads\/2020\/03\/simple_example_sdcheck-300x122.png 300w, https:\/\/blue.pri.ee\/ttu\/wp-content\/uploads\/2020\/03\/simple_example_sdcheck-768x312.png 768w\" sizes=\"auto, (max-width: 932px) 100vw, 932px\" \/><\/a><\/p>\n<p>In our simple case the tool actually gives a correct result. Valgrind reports the invalid write and invalid read of size 4 (integer) and provides information on expected and actual addresses. An invalid address is expected to be a part of statically allocated (i.e. allocated on stack) array called <code>array<\/code> (good naming) of size 20 (5 * 4 = 20), but actually it is located 0 bytes after that array. This way, we come out of bounds.<\/p>\n","protected":false},"excerpt":{"rendered":"<p>Introduction Valgrind is a programming tool for debugging memory related issues and memory profiling. When you work with dynamic memory allocation, you should be really careful about resources you use. Simple programs can be debugged by careful visual inspection of the code or by adding corresponding print statements here and there to check the state &hellip; <a href=\"https:\/\/blue.pri.ee\/ttu\/coding-guides\/fun-with-valgrind\/\" class=\"more-link\">Loe edasi <span class=\"screen-reader-text\">Fun with Valgrind<\/span> <span class=\"meta-nav\">&rarr;<\/span><\/a><\/p>\n","protected":false},"author":5,"featured_media":0,"parent":4802,"menu_order":5,"comment_status":"closed","ping_status":"closed","template":"page-templates\/code-width-wide.php","meta":{"footnotes":""},"class_list":["post-4986","page","type-page","status-publish","hentry"],"_links":{"self":[{"href":"https:\/\/blue.pri.ee\/ttu\/wp-json\/wp\/v2\/pages\/4986","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/blue.pri.ee\/ttu\/wp-json\/wp\/v2\/pages"}],"about":[{"href":"https:\/\/blue.pri.ee\/ttu\/wp-json\/wp\/v2\/types\/page"}],"author":[{"embeddable":true,"href":"https:\/\/blue.pri.ee\/ttu\/wp-json\/wp\/v2\/users\/5"}],"replies":[{"embeddable":true,"href":"https:\/\/blue.pri.ee\/ttu\/wp-json\/wp\/v2\/comments?post=4986"}],"version-history":[{"count":0,"href":"https:\/\/blue.pri.ee\/ttu\/wp-json\/wp\/v2\/pages\/4986\/revisions"}],"up":[{"embeddable":true,"href":"https:\/\/blue.pri.ee\/ttu\/wp-json\/wp\/v2\/pages\/4802"}],"wp:attachment":[{"href":"https:\/\/blue.pri.ee\/ttu\/wp-json\/wp\/v2\/media?parent=4986"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}