title: Why doesn't valgrind spot the leak when program was compiled with gcc-5.2.0
body: <p>Today I was coding something and after I was done, I made a check with <a href="http://www.valgrind.org/" rel="nofollow noreferrer"><code>valgrind</code></a> and I got a surprise.</p>
  
  <p>If I compile my program on my Ubuntu (15.04 64BIT) with gcc-4.9.2 with the following:</p>
  
  <pre><code>gcc -Wextra -Werror -Wstrict-prototypes -Wconversion --std=c11 -O2 -g program.c -o program
  </code></pre>
  
  <p>And then run valgrind:</p>
  
  <pre><code>valgrind --leak-check=full --track-origins=yes ./program
  </code></pre>
  
  <p>I get the following output:</p>
  
  <blockquote>
  <pre><code>==5325== Memcheck, a memory error detector
  ==5325== Copyright (C) 2002-2013, and GNU GPL'd, by Julian Seward et al.
  ==5325== Using Valgrind-3.10.1 and LibVEX; rerun with -h for copyright info
  ==5325== Command: ./program
  ==5325== 
  Bye
  ==5325== 
  ==5325== HEAP SUMMARY:
  ==5325==     in use at exit: 33 bytes in 1 blocks
  ==5325==   total heap usage: 1 allocs, 0 frees, 33 bytes allocated
  ==5325== 
  ==5325== 33 bytes in 1 blocks are definitely lost in loss record 1 of 1
  ==5325==    at 0x4C2BBA0: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
  ==5325==    by 0x4004BD: main (program.c:11)
  ==5325== 
  ==5325== LEAK SUMMARY:
  ==5325==    definitely lost: 33 bytes in 1 blocks
  ==5325==    indirectly lost: 0 bytes in 0 blocks
  ==5325==      possibly lost: 0 bytes in 0 blocks
  ==5325==    still reachable: 0 bytes in 0 blocks
  ==5325==         suppressed: 0 bytes in 0 blocks
  ==5325== 
  ==5325== For counts of detected and suppressed errors, rerun with: -v
  ==5325== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 0 from 0)
  </code></pre>
  </blockquote>
  
  <p>As you can see the leak is spotted, but take a look of what happens if I compile with gcc-5.2.0 with the following:</p>
  
  <pre><code>./install/gcc-5.2.0/bin/gcc5.2 -Wextra -Werror -Wstrict-prototypes -Wconversion --std=c11 -O2 -g program.c -o program
  </code></pre>
  
  <p>And now valgrind says:</p>
  
  <blockquote>
  <pre><code>==5344== Memcheck, a memory error detector
  ==5344== Copyright (C) 2002-2013, and GNU GPL'd, by Julian Seward et al.
  ==5344== Using Valgrind-3.10.1 and LibVEX; rerun with -h for copyright info
  ==5344== Command: ./program
  ==5344== 
  Bye
  ==5344== 
  ==5344== HEAP SUMMARY:
  ==5344==     in use at exit: 0 bytes in 0 blocks
  ==5344==   total heap usage: 0 allocs, 0 frees, 0 bytes allocated
  ==5344== 
  ==5344== All heap blocks were freed -- no leaks are possible
  ==5344== 
  ==5344== For counts of detected and suppressed errors, rerun with: -v
  ==5344== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)
  </code></pre>
  </blockquote>
  
  <p>As you can see there is <strong>total heap usage: 0 allocs, 0 frees, 0 bytes allocated</strong></p>
  
  <p>The piece of code I tried was the following:</p>
  
  <pre><code>#include&lt;stdio.h&gt;
  #include&lt;stdlib.h&gt;
  #include&lt;string.h&gt;
  
  int main(void){
      int a = 0;
      size_t len1 = 0, len2 = 0;
      char *string1 = "Hello";
      char *string2;
  
      string2 = malloc(33);
      strcpy(string2, "Hello");
  
      len1 = strlen(string1);
      len2 = strlen(string2);
  
      if(len1 != len2){
          a = 5;
      }else{
          a=4;
      }
  
      while (a != -1){
          if(a == 2){
              break;
          }
          a--;
      }
  
  
      printf("Bye\n");
      /*free(string2);*/
      return 0;
  }
  </code></pre>
  
  <p>GCC-5.2.0 was installed <a href="https://stackoverflow.com/questions/32771977/error-building-and-compiling-gcc-5-2-0-from-scratch-on-vortex86dx/32792077#32792077">using this method</a>.</p>
  
  <p>Now my question is: is it GCC or valgrind at fault? Why does this happen and how can I avoid it?</p>
  
  <p>One last thing, if I change:</p>
  
  <pre><code>printf("Bye\n");
  </code></pre>
  
  <p>to this:</p>
  
  <pre><code>printf("String2 = %s\n",string2);
  </code></pre>
  
  <p>The leak is spotted:</p>
  
  <blockquote>
  <pre><code>==5443== Memcheck, a memory error detector
  ==5443== Copyright (C) 2002-2013, and GNU GPL'd, by Julian Seward et al.
  ==5443== Using Valgrind-3.10.1 and LibVEX; rerun with -h for copyright info
  ==5443== Command: ./program
  ==5443== 
  String2 = Hello
  ==5443== 
  ==5443== HEAP SUMMARY:
  ==5443==     in use at exit: 33 bytes in 1 blocks
  ==5443==   total heap usage: 1 allocs, 0 frees, 33 bytes allocated
  ==5443== 
  ==5443== 33 bytes in 1 blocks are definitely lost in loss record 1 of 1
  ==5443==    at 0x4C2BBA0: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
  ==5443==    by 0x40044D: main (program.c:11)
  ==5443== 
  ==5443== LEAK SUMMARY:
  ==5443==    definitely lost: 33 bytes in 1 blocks
  ==5443==    indirectly lost: 0 bytes in 0 blocks
  ==5443==      possibly lost: 0 bytes in 0 blocks
  ==5443==    still reachable: 0 bytes in 0 blocks
  ==5443==         suppressed: 0 bytes in 0 blocks
  ==5443== 
  ==5443== For counts of detected and suppressed errors, rerun with: -v
  ==5443== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 0 from 0)
  </code></pre>
  </blockquote>
  
  <p>Which makes me ask myself why? Somehow printf() helps in this story.</p>