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.

How do I use valgrind to find memory leaks?

I was looking into Valgrind to help improve my C coding/debugging when I discovered it is only for Linux - I have no other need or interest in moving my OS to Linux so I was wondering if there is a equally good program for Windows.

Is there a good Valgrind substitute for Windows?

So I&#39;ve been getting some mysterious uninitialized values message from valgrind and it&#39;s been quite the mystery as of where the bad value originated from.

Seems that valgrind shows the place where the unitialised value ends up being used, but not the origin of the uninitialised value.

    ==11366== Conditional jump or move depends on uninitialised value(s)
    ==11366==    at 0x43CAE4F: __printf_fp (in /lib/tls/i686/cmov/libc-2.7.so)
    ==11366==    by 0x43C6563: vfprintf (in /lib/tls/i686/cmov/libc-2.7.so)
    ==11366==    by 0x43EAC03: vsnprintf (in /lib/tls/i686/cmov/libc-2.7.so)
    ==11366==    by 0x42D475B: (within /usr/lib/libstdc++.so.6.0.9)
    ==11366==    by 0x42E2C9B: std::ostreambuf_iterator&lt;char, std::char_traits&lt;char&gt; &gt; std::num_put&lt;char, std::ostreambuf_iterator&lt;char, std::char_traits&lt;char&gt; &gt; &gt;::_M_insert_float&lt;double&gt;(std::ostreambuf_iterator&lt;char, std::char_traits&lt;char&gt; &gt;, std::ios_base&amp;, char, char, double) const (in /usr/lib/libstdc++.so.6.0.9)
    ==11366==    by 0x42E31B4: std::num_put&lt;char, std::ostreambuf_iterator&lt;char, std::char_traits&lt;char&gt; &gt; &gt;::do_put(std::ostreambuf_iterator&lt;char, std::char_traits&lt;char&gt; &gt;, std::ios_base&amp;, char, double) const (in /usr/lib/libstdc++.so.6.0.9)
    ==11366==    by 0x42EE56F: std::ostream&amp; std::ostream::_M_insert&lt;double&gt;(double) (in /usr/lib/libstdc++.so.6.0.9)
    ==11366==    by 0x81109ED: Snake::SnakeBody::syncBodyPos() (ostream:221)
    ==11366==    by 0x810B9F1: Snake::Snake::update() (snake.cpp:257)
    ==11366==    by 0x81113C1: SnakeApp::updateState() (snakeapp.cpp:224)
    ==11366==    by 0x8120351: RoenGL::updateState() (roengl.cpp:1180)
    ==11366==    by 0x81E87D9: Roensachs::update() (rs.cpp:321)

As can be seen, it gets quite cryptic.. especially because when it&#39;s saying by Class::MethodX, it sometimes points straight to ostream etc. Perhaps this is due to optimization?

    ==11366==    by 0x81109ED: Snake::SnakeBody::syncBodyPos() (ostream:221)

Just like that. Is there something I&#39;m missing? What is the best way to catch bad values without having to resort to super-long printf detective work?

***Update:***

I found out what was wrong, but the strange thing is, valgrind did not report it when the bad value was first used. It was used in a multiplication function:

    movespeed = stat.speedfactor * speedfac * currentbendfactor.val;

Where speedfac was an unitialised float. However, at that time it was not reported and not until the value is to be printed that I get the error.. Is there a setting for valgrind to change this behavior?

pinpointing &quot;conditional jump or move depends on uninitialized value(s)&quot; valgrind message

All the functions mentioned in this block are library functions. How can I rectify this memory leak? 

It is listed under the &quot;**Still reachable**&quot; category. (There are 4 more, which are very similar, but of varying sizes)

     630 bytes in 1 blocks are still reachable in loss record 5 of 5
        at 0x4004F1B: calloc (vg_replace_malloc.c:418)
        by 0x931CD2: _dl_new_object (dl-object.c:52)
        by 0x92DD36: _dl_map_object_from_fd (dl-load.c:972)
        by 0x92EFB6: _dl_map_object (dl-load.c:2251)
        by 0x939F1B: dl_open_worker (dl-open.c:255)
        by 0x935965: _dl_catch_error (dl-error.c:178)
        by 0x9399C5: _dl_open (dl-open.c:584)
        by 0xA64E31: do_dlopen (dl-libc.c:86)
        by 0x935965: _dl_catch_error (dl-error.c:178)
        by 0xA64FF4: __libc_dlopen_mode (dl-libc.c:47)
        by 0xAE6086: pthread_cancel_init (unwind-forcedunwind.c:53)
        by 0xAE61FC: _Unwind_ForcedUnwind (unwind-forcedunwind.c:126)

**Catch:** Once I ran my program, it gave no memory leaks, but it had one additional line in the Valgrind output, which wasn&#39;t present before:

&gt; Discarding syms at 0x5296fa0-0x52af438
&gt; in /lib/libgcc_s-4.4.4-20100630.so.1
&gt; due to munmap()

If the leak can&#39;t be rectified, can someone atleast explain why the munmap() line causes Valgrind to report 0 &quot;still reachable&quot; leaks?

**Edit:**

Here&#39;s a minimal test sample:

    #include &lt;stdio.h&gt;
    #include &lt;stdlib.h&gt;
    #include &lt;pthread.h&gt;
    
    void *runner(void *param) {
    	/* some operations ... */
    	pthread_exit(NULL);
    }
    
    int n;
    
    int main(void) {
    	
        int i;
    	pthread_t *threadIdArray;
    	
    	n=10; /* for example */
    
    	threadIdArray = malloc((n+n-1)*sizeof(pthread_t));  
    		
    	for(i=0;i&lt;(n+n-1);i++) {
    		if( pthread_create(&amp;threadIdArray[i],NULL,runner,NULL) != 0 ) {
    			printf(&quot;Couldn&#39;t create thread %d\n&quot;,i);
    			exit(1);
    		}
    	}
    	
    	
    	for(i=0;i&lt;(n+n-1);i++) {
    		pthread_join(threadIdArray[i],NULL);
    	}
    	
    	free(threadIdArray);
    	
    	return(0);
    }

Run with:

    valgrind -v --leak-check=full --show-reachable=yes ./a.out

 

Still Reachable Leak detected by Valgrind

While working with Valgrind tool, i need to log the details produced by valgrind tool. How can I accomplish that? I tried something like,


     valgrind a.out | test

and

     valgrind a.out &gt; test

It gave just the program&#39;s output and not the valgrind memory error,leak information. Even i am getting like this if the program requires no user interaction (i.e. giving input). If the program need user input even that thing itself won&#39;t work. 

How can I do this?


How to redirect Valgrind&#39;s output to a file?

Can you tell me how to install valgrind on yosemite? When I try to install it i get &quot; checking for the kernel version... unsupported (14.0.0)
configure: error: Valgrind works on Darwin 10.x, 11.x, 12.x and 13.x (Mac OS X 10.6/7/8/9) &quot;

There is no official path or update, and I didn&#39;t found anything (except http://comments.gmane.org/gmane.comp.kde.devel.bugs/1553705 , but they didn&#39;t resolve that problem).

Yosemite and Valgrind

Our code involves a POD (Plain Old Datastructure) struct (it is a basic c++ struct that has other structs and POD variables in it that needs to get initialized in the beginning.) 

Based one what I&#39;ve [read][1], it seems that:

    myStruct = (MyStruct*)calloc(1, sizeof(MyStruct));

should initialize all the values to zero, as does:

    myStruct = new MyStruct();

However, when the struct is initialized in the second way, Valgrind later complains &quot;conditional jump or move depends on uninitialised value(s)&quot; when those variables are used. Is my understanding flawed here, or is Valgrind throwing false positives?


  [1]: https://stackoverflow.com/questions/2951586/default-struct-initialization-in-c

Proper way to initialize C++ structs

When I was running my program against valgrind, I encountered the following warning.

    Warning: set address range perms: large range [0x4d59d040, 0x6159d040) (undefined)
    Warning: set address range perms: large range [0x194f7030, 0x2d4f7050) (noaccess)
    Warning: set address range perms: large range [0x3959d030, 0x6159d050) (noaccess)

After some googling I found at [here](http://www.network-theory.co.uk/docs/valgrind/valgrind_29.html) that it is a `Diagnostic message, mostly for benefit of the Valgrind developers, to do with memory permissions`, which doesn&#39;t tell me much.

My program does allocate a large amount of memory on heap. (Can reach 2-3 GB of ram after a whole bunch of `realloc`&#39;s)

However, the warning appeared despite none of the allocations failed.

So, I&#39;m wondering what this message really means? I don&#39;t have some sort of memory permission? (But allocation succeeded) 

What Does This Valgrind Warning Mean? - warning set address range perms

I&#39;m using Valgrind 3.3.1 with the **Massif** tool to profile the heap of a C++ application, and I&#39;m wondering if there is a **graphical tool** to examine the textual outputfile file.

Thanks for any suggestion.

Valgrind Massif tool output graphical interface?

Can someone provide a quick top level explanation of how Valgrind works? An example: how does it know when memory is allocated and freed?

How does valgrind work?

Take the following trivial program:

    #include &lt;iostream&gt;
    int main() {
      return 0;
    }

If I run this using valgrind, I&#39;m told that there are `72,704 bytes in 1 blocks` that are `still reachable`.  There have been extensive discussions on SO about whether or not to worry about still reachable warnings--I&#39;m not concerned about that.  I&#39;d just like to understand how simply *including* a standard library header could cause a still reachable warning, when none of the objects from that library were allocated in the program itself.

Here is the full `valgrind` output:

    $ valgrind --leak-check=full --track-origins=yes --show-reachable=yes ./ValgrindTest
    ==27671== Memcheck, a memory error detector
    ==27671== Copyright (C) 2002-2013, and GNU GPL&#39;d, by Julian Seward et al.
    ==27671== Using Valgrind-3.10.1 and LibVEX; rerun with -h for copyright info
    ==27671== Command: ./ValgrindTest
    ==27671== 
    ==27671== 
    ==27671== HEAP SUMMARY:
    ==27671==     in use at exit: 72,704 bytes in 1 blocks
    ==27671==   total heap usage: 1 allocs, 0 frees, 72,704 bytes allocated
    ==27671== 
    ==27671== 72,704 bytes in 1 blocks are still reachable in loss record 1 of 1
    ==27671==    at 0x4C2AB9D: malloc (vg_replace_malloc.c:296)
    ==27671==    by 0x4EC060F: ??? (in /usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.21)
    ==27671==    by 0x400F305: call_init.part.0 (dl-init.c:85)
    ==27671==    by 0x400F3DE: call_init (dl-init.c:52)
    ==27671==    by 0x400F3DE: _dl_init (dl-init.c:134)
    ==27671==    by 0x40016E9: ??? (in /lib/x86_64-linux-gnu/ld-2.15.so)
    ==27671== 
    ==27671== LEAK SUMMARY:
    ==27671==    definitely lost: 0 bytes in 0 blocks
    ==27671==    indirectly lost: 0 bytes in 0 blocks
    ==27671==      possibly lost: 0 bytes in 0 blocks
    ==27671==    still reachable: 72,704 bytes in 1 blocks
    ==27671==         suppressed: 0 bytes in 0 blocks
    ==27671== 
    ==27671== For counts of detected and suppressed errors, rerun with: -v
    ==27671== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)

And an object dump:


    $ objdump -d ValgrindTest 
    
    ValgrindTest:     file format elf64-x86-64
    
    
    Disassembly of section .init:
    
    0000000000400718 &lt;_init&gt;:
      400718:	48 83 ec 08          	sub    $0x8,%rsp
      40071c:	e8 8b 00 00 00       	callq  4007ac &lt;call_gmon_start&gt;
      400721:	48 83 c4 08          	add    $0x8,%rsp
      400725:	c3                   	retq   
    
    Disassembly of section .plt:
    
    0000000000400730 &lt;_ZNSt8ios_base4InitC1Ev@plt-0x10&gt;:
      400730:	ff 35 ba 08 20 00    	pushq  0x2008ba(%rip)        # 600ff0 &lt;_GLOBAL_OFFSET_TABLE_+0x8&gt;
      400736:	ff 25 bc 08 20 00    	jmpq   *0x2008bc(%rip)        # 600ff8 &lt;_GLOBAL_OFFSET_TABLE_+0x10&gt;
      40073c:	0f 1f 40 00          	nopl   0x0(%rax)
    
    0000000000400740 &lt;_ZNSt8ios_base4InitC1Ev@plt&gt;:
      400740:	ff 25 ba 08 20 00    	jmpq   *0x2008ba(%rip)        # 601000 &lt;_GLOBAL_OFFSET_TABLE_+0x18&gt;
      400746:	68 00 00 00 00       	pushq  $0x0
      40074b:	e9 e0 ff ff ff       	jmpq   400730 &lt;_init+0x18&gt;
    
    0000000000400750 &lt;__libc_start_main@plt&gt;:
      400750:	ff 25 b2 08 20 00    	jmpq   *0x2008b2(%rip)        # 601008 &lt;_GLOBAL_OFFSET_TABLE_+0x20&gt;
      400756:	68 01 00 00 00       	pushq  $0x1
      40075b:	e9 d0 ff ff ff       	jmpq   400730 &lt;_init+0x18&gt;
    
    0000000000400760 &lt;__cxa_atexit@plt&gt;:
      400760:	ff 25 aa 08 20 00    	jmpq   *0x2008aa(%rip)        # 601010 &lt;_GLOBAL_OFFSET_TABLE_+0x28&gt;
      400766:	68 02 00 00 00       	pushq  $0x2
      40076b:	e9 c0 ff ff ff       	jmpq   400730 &lt;_init+0x18&gt;
    
    0000000000400770 &lt;_ZNSt8ios_base4InitD1Ev@plt&gt;:
      400770:	ff 25 a2 08 20 00    	jmpq   *0x2008a2(%rip)        # 601018 &lt;_GLOBAL_OFFSET_TABLE_+0x30&gt;
      400776:	68 03 00 00 00       	pushq  $0x3
      40077b:	e9 b0 ff ff ff       	jmpq   400730 &lt;_init+0x18&gt;
    
    Disassembly of section .text:
    
    0000000000400780 &lt;_start&gt;:
      400780:	31 ed                	xor    %ebp,%ebp
      400782:	49 89 d1             	mov    %rdx,%r9
      400785:	5e                   	pop    %rsi
      400786:	48 89 e2             	mov    %rsp,%rdx
      400789:	48 83 e4 f0          	and    $0xfffffffffffffff0,%rsp
      40078d:	50                   	push   %rax
      40078e:	54                   	push   %rsp
      40078f:	49 c7 c0 80 09 40 00 	mov    $0x400980,%r8
      400796:	48 c7 c1 f0 08 40 00 	mov    $0x4008f0,%rcx
      40079d:	48 c7 c7 90 08 40 00 	mov    $0x400890,%rdi
      4007a4:	e8 a7 ff ff ff       	callq  400750 &lt;__libc_start_main@plt&gt;
      4007a9:	f4                   	hlt    
      4007aa:	90                   	nop
      4007ab:	90                   	nop
    
    00000000004007ac &lt;call_gmon_start&gt;:
      4007ac:	48 83 ec 08          	sub    $0x8,%rsp
      4007b0:	48 8b 05 29 08 20 00 	mov    0x200829(%rip),%rax        # 600fe0 &lt;_DYNAMIC+0x1f0&gt;
      4007b7:	48 85 c0             	test   %rax,%rax
      4007ba:	74 02                	je     4007be &lt;call_gmon_start+0x12&gt;
      4007bc:	ff d0                	callq  *%rax
      4007be:	48 83 c4 08          	add    $0x8,%rsp
      4007c2:	c3                   	retq   
      4007c3:	90                   	nop
      4007c4:	90                   	nop
      4007c5:	90                   	nop
      4007c6:	90                   	nop
      4007c7:	90                   	nop
      4007c8:	90                   	nop
      4007c9:	90                   	nop
      4007ca:	90                   	nop
      4007cb:	90                   	nop
      4007cc:	90                   	nop
      4007cd:	90                   	nop
      4007ce:	90                   	nop
      4007cf:	90                   	nop
    
    00000000004007d0 &lt;deregister_tm_clones&gt;:
      4007d0:	b8 37 10 60 00       	mov    $0x601037,%eax
      4007d5:	55                   	push   %rbp
      4007d6:	48 2d 30 10 60 00    	sub    $0x601030,%rax
      4007dc:	48 83 f8 0e          	cmp    $0xe,%rax
      4007e0:	48 89 e5             	mov    %rsp,%rbp
      4007e3:	77 02                	ja     4007e7 &lt;deregister_tm_clones+0x17&gt;
      4007e5:	5d                   	pop    %rbp
      4007e6:	c3                   	retq   
      4007e7:	b8 00 00 00 00       	mov    $0x0,%eax
      4007ec:	48 85 c0             	test   %rax,%rax
      4007ef:	74 f4                	je     4007e5 &lt;deregister_tm_clones+0x15&gt;
      4007f1:	5d                   	pop    %rbp
      4007f2:	bf 30 10 60 00       	mov    $0x601030,%edi
      4007f7:	ff e0                	jmpq   *%rax
      4007f9:	0f 1f 80 00 00 00 00 	nopl   0x0(%rax)
    
    0000000000400800 &lt;register_tm_clones&gt;:
      400800:	b8 30 10 60 00       	mov    $0x601030,%eax
      400805:	55                   	push   %rbp
      400806:	48 2d 30 10 60 00    	sub    $0x601030,%rax
      40080c:	48 c1 f8 03          	sar    $0x3,%rax
      400810:	48 89 e5             	mov    %rsp,%rbp
      400813:	48 89 c2             	mov    %rax,%rdx
      400816:	48 c1 ea 3f          	shr    $0x3f,%rdx
      40081a:	48 01 d0             	add    %rdx,%rax
      40081d:	48 d1 f8             	sar    %rax
      400820:	75 02                	jne    400824 &lt;register_tm_clones+0x24&gt;
      400822:	5d                   	pop    %rbp
      400823:	c3                   	retq   
      400824:	ba 00 00 00 00       	mov    $0x0,%edx
      400829:	48 85 d2             	test   %rdx,%rdx
      40082c:	74 f4                	je     400822 &lt;register_tm_clones+0x22&gt;
      40082e:	5d                   	pop    %rbp
      40082f:	48 89 c6             	mov    %rax,%rsi
      400832:	bf 30 10 60 00       	mov    $0x601030,%edi
      400837:	ff e2                	jmpq   *%rdx
      400839:	0f 1f 80 00 00 00 00 	nopl   0x0(%rax)
    
    0000000000400840 &lt;__do_global_dtors_aux&gt;:
      400840:	80 3d e9 07 20 00 00 	cmpb   $0x0,0x2007e9(%rip)        # 601030 &lt;__bss_start&gt;
      400847:	75 11                	jne    40085a &lt;__do_global_dtors_aux+0x1a&gt;
      400849:	55                   	push   %rbp
      40084a:	48 89 e5             	mov    %rsp,%rbp
      40084d:	e8 7e ff ff ff       	callq  4007d0 &lt;deregister_tm_clones&gt;
      400852:	5d                   	pop    %rbp
      400853:	c6 05 d6 07 20 00 01 	movb   $0x1,0x2007d6(%rip)        # 601030 &lt;__bss_start&gt;
      40085a:	f3 c3                	repz retq 
      40085c:	0f 1f 40 00          	nopl   0x0(%rax)
    
    0000000000400860 &lt;frame_dummy&gt;:
      400860:	48 83 3d 80 05 20 00 	cmpq   $0x0,0x200580(%rip)        # 600de8 &lt;__JCR_END__&gt;
      400867:	00 
      400868:	74 1e                	je     400888 &lt;frame_dummy+0x28&gt;
      40086a:	b8 00 00 00 00       	mov    $0x0,%eax
      40086f:	48 85 c0             	test   %rax,%rax
      400872:	74 14                	je     400888 &lt;frame_dummy+0x28&gt;
      400874:	55                   	push   %rbp
      400875:	bf e8 0d 60 00       	mov    $0x600de8,%edi
      40087a:	48 89 e5             	mov    %rsp,%rbp
      40087d:	ff d0                	callq  *%rax
      40087f:	5d                   	pop    %rbp
      400880:	e9 7b ff ff ff       	jmpq   400800 &lt;register_tm_clones&gt;
      400885:	0f 1f 00             	nopl   (%rax)
      400888:	e9 73 ff ff ff       	jmpq   400800 &lt;register_tm_clones&gt;
      40088d:	90                   	nop
      40088e:	90                   	nop
      40088f:	90                   	nop
    
    0000000000400890 &lt;main&gt;:
      400890:	55                   	push   %rbp
      400891:	48 89 e5             	mov    %rsp,%rbp
      400894:	b8 00 00 00 00       	mov    $0x0,%eax
      400899:	5d                   	pop    %rbp
      40089a:	c3                   	retq   
    
    000000000040089b &lt;_Z41__static_initialization_and_destruction_0ii&gt;:
      40089b:	55                   	push   %rbp
      40089c:	48 89 e5             	mov    %rsp,%rbp
      40089f:	48 83 ec 10          	sub    $0x10,%rsp
      4008a3:	89 7d fc             	mov    %edi,-0x4(%rbp)
      4008a6:	89 75 f8             	mov    %esi,-0x8(%rbp)
      4008a9:	83 7d fc 01          	cmpl   $0x1,-0x4(%rbp)
      4008ad:	75 27                	jne    4008d6 &lt;_Z41__static_initialization_and_destruction_0ii+0x3b&gt;
      4008af:	81 7d f8 ff ff 00 00 	cmpl   $0xffff,-0x8(%rbp)
      4008b6:	75 1e                	jne    4008d6 &lt;_Z41__static_initialization_and_destruction_0ii+0x3b&gt;
      4008b8:	bf 34 10 60 00       	mov    $0x601034,%edi
      4008bd:	e8 7e fe ff ff       	callq  400740 &lt;_ZNSt8ios_base4InitC1Ev@plt&gt;
      4008c2:	ba 28 10 60 00       	mov    $0x601028,%edx
      4008c7:	be 34 10 60 00       	mov    $0x601034,%esi
      4008cc:	bf 70 07 40 00       	mov    $0x400770,%edi
      4008d1:	e8 8a fe ff ff       	callq  400760 &lt;__cxa_atexit@plt&gt;
      4008d6:	c9                   	leaveq 
      4008d7:	c3                   	retq   
    
    00000000004008d8 &lt;_GLOBAL__sub_I_main&gt;:
      4008d8:	55                   	push   %rbp
      4008d9:	48 89 e5             	mov    %rsp,%rbp
      4008dc:	be ff ff 00 00       	mov    $0xffff,%esi
      4008e1:	bf 01 00 00 00       	mov    $0x1,%edi
      4008e6:	e8 b0 ff ff ff       	callq  40089b &lt;_Z41__static_initialization_and_destruction_0ii&gt;
      4008eb:	5d                   	pop    %rbp
      4008ec:	c3                   	retq   
      4008ed:	90                   	nop
      4008ee:	90                   	nop
      4008ef:	90                   	nop
    
    00000000004008f0 &lt;__libc_csu_init&gt;:
      4008f0:	48 89 6c 24 d8       	mov    %rbp,-0x28(%rsp)
      4008f5:	4c 89 64 24 e0       	mov    %r12,-0x20(%rsp)
      4008fa:	48 8d 2d df 04 20 00 	lea    0x2004df(%rip),%rbp        # 600de0 &lt;__init_array_end&gt;
      400901:	4c 8d 25 c8 04 20 00 	lea    0x2004c8(%rip),%r12        # 600dd0 &lt;__frame_dummy_init_array_entry&gt;
      400908:	4c 89 6c 24 e8       	mov    %r13,-0x18(%rsp)
      40090d:	4c 89 74 24 f0       	mov    %r14,-0x10(%rsp)
      400912:	4c 89 7c 24 f8       	mov    %r15,-0x8(%rsp)
      400917:	48 89 5c 24 d0       	mov    %rbx,-0x30(%rsp)
      40091c:	48 83 ec 38          	sub    $0x38,%rsp
      400920:	4c 29 e5             	sub    %r12,%rbp
      400923:	41 89 fd             	mov    %edi,%r13d
      400926:	49 89 f6             	mov    %rsi,%r14
      400929:	48 c1 fd 03          	sar    $0x3,%rbp
      40092d:	49 89 d7             	mov    %rdx,%r15
      400930:	e8 e3 fd ff ff       	callq  400718 &lt;_init&gt;
      400935:	48 85 ed             	test   %rbp,%rbp
      400938:	74 1c                	je     400956 &lt;__libc_csu_init+0x66&gt;
      40093a:	31 db                	xor    %ebx,%ebx
      40093c:	0f 1f 40 00          	nopl   0x0(%rax)
      400940:	4c 89 fa             	mov    %r15,%rdx
      400943:	4c 89 f6             	mov    %r14,%rsi
      400946:	44 89 ef             	mov    %r13d,%edi
      400949:	41 ff 14 dc          	callq  *(%r12,%rbx,8)
      40094d:	48 83 c3 01          	add    $0x1,%rbx
      400951:	48 39 eb             	cmp    %rbp,%rbx
      400954:	75 ea                	jne    400940 &lt;__libc_csu_init+0x50&gt;
      400956:	48 8b 5c 24 08       	mov    0x8(%rsp),%rbx
      40095b:	48 8b 6c 24 10       	mov    0x10(%rsp),%rbp
      400960:	4c 8b 64 24 18       	mov    0x18(%rsp),%r12
      400965:	4c 8b 6c 24 20       	mov    0x20(%rsp),%r13
      40096a:	4c 8b 74 24 28       	mov    0x28(%rsp),%r14
      40096f:	4c 8b 7c 24 30       	mov    0x30(%rsp),%r15
      400974:	48 83 c4 38          	add    $0x38,%rsp
      400978:	c3                   	retq   
      400979:	0f 1f 80 00 00 00 00 	nopl   0x0(%rax)
    
    0000000000400980 &lt;__libc_csu_fini&gt;:
      400980:	f3 c3                	repz retq 
      400982:	90                   	nop
      400983:	90                   	nop
    
    Disassembly of section .fini:
    
    0000000000400984 &lt;_fini&gt;:
      400984:	48 83 ec 08          	sub    $0x8,%rsp
      400988:	48 83 c4 08          	add    $0x8,%rsp
      40098c:	c3                   	retq   


For completeness, I&#39;m using:  
Ubuntu:  12.04  
Valgrind:  3.10.1 &lt;strike&gt;3.7.0&lt;/strike&gt;  
g++: 4.8.1

NB: As a side note, this does not happen when I include other headers such as `&lt;fstream&gt;` or `&lt;cmath&gt;`.

Valgrind: Memory still reachable with trivial program using &lt;iostream&gt;

I&#39;m following &#39;Learn C the Hard Way&#39;, specifically [the chapter on Valgrind][1]. This chapter gives you a deliberately wrong program to show how Valgrind works.

When I run the exercise under Valgrind I do not get line numbers in my stack trace, just &#39;(below main)&#39; for the errors.

I am _definitely_ compiling with the -g flag.

My Valgrind output is as follows:

    djb@twin:~/projects/Learning/C$ valgrind ./ex4
    ==5190== Memcheck, a memory error detector
    ==5190== Copyright (C) 2002-2010, and GNU GPL&#39;d, by Julian Seward et al.
    ==5190== Using Valgrind-3.6.1-Debian and LibVEX; rerun with -h for copyright info
    ==5190== Command: ./ex4
    ==5190== 
    ==5190== Use of uninitialised value of size 4
    ==5190==    at 0x4078B2B: _itoa_word (_itoa.c:195)
    ==5190==    by 0x407CE55: vfprintf (vfprintf.c:1619)
    ==5190==    by 0x40831DE: printf (printf.c:35)
    ==5190==    by 0x4052112: (below main) (libc-start.c:226)
    ==5190== 
    ==5190== Conditional jump or move depends on uninitialised value(s)
    ==5190==    at 0x4078B33: _itoa_word (_itoa.c:195)
    ==5190==    by 0x407CE55: vfprintf (vfprintf.c:1619)
    ==5190==    by 0x40831DE: printf (printf.c:35)
    ==5190==    by 0x4052112: (below main) (libc-start.c:226)
    ==5190== 
    ==5190== Conditional jump or move depends on uninitialised value(s)
    ==5190==    at 0x407CC10: vfprintf (vfprintf.c:1619)
    ==5190==    by 0x40831DE: printf (printf.c:35)
    ==5190==    by 0x4052112: (below main) (libc-start.c:226)
    ==5190== 
    ==5190== Conditional jump or move depends on uninitialised value(s)
    ==5190==    at 0x407C742: vfprintf (vfprintf.c:1619)
    ==5190==    by 0x40831DE: printf (printf.c:35)
    ==5190==    by 0x4052112: (below main) (libc-start.c:226)
    ==5190== 
    I am 0 years old.
    I am 68882420 inches tall.
    ==5190== 
    ==5190== HEAP SUMMARY:
    ==5190==     in use at exit: 0 bytes in 0 blocks
    ==5190==   total heap usage: 0 allocs, 0 frees, 0 bytes allocated
    ==5190== 
    ==5190== All heap blocks were freed -- no leaks are possible
    ==5190== 
    ==5190== For counts of detected and suppressed errors, rerun with: -v
    ==5190== Use --track-origins=yes to see where uninitialised values come from
    ==5190== ERROR SUMMARY: 22 errors from 4 contexts (suppressed: 11 from 6)


I&#39;m using Ubuntu 11.10 in a VirtualBox VM.

Thank you for any help. 

**Update**

It seems that if I call a function from `main()` and that function contains a mistake (eg an uninitialized variable), then I _do_ get a trace to the place that function was called in `main()`. However errors within `main()` remain unspecified. See [this paste][2] for an example.


  [1]: http://c.learncodethehardway.org/book/learn-c-the-hard-waych5.html#x10-290005
  [2]: http://pastebin.com/GGAK4912

Valgrind not showing line numbers in spite of -g flag (on Ubuntu 11.10/VirtualBox)

I tried to install Valgrind with `brew install Valgrind` and got  :

    valgrind: This formula either does not compile or function as expected
    on macOS versions newer than Sierra due to an upstream
    incompatibility. 
    Error: An unsatisfied requirement failed this build.

I tried  `brew install --HEAD Valgrind`. 

Instead, after successfully installing the dependencies `autoconf`, `automake` and `libtool`, when it tries to install valgrind, I get a configure error:

    Valgrind works on Darwin 10.x, 11.x, 12.x, 13.x, 14.x, 15.x, 16.x and
    17.x (Mac OS X 10.6/7/8/9/10/11 and macOS 10.12/13)

My OS is macOS Mojave(10.14), so does it mean that I can&#39;t install a functioning Valgrind with Homebrew presently?

How to install Valgrind on macOS Mojave(10.14) with Homebrew?

I am trying to memcheck a C python extension I am writing, but I&#39;m having trouble setting up valgrind to work with python. I would really appreciate some advice. Just for context, this is Ubuntu 13.10, python 2.7.5+, and valgrind 3.8.1.

As per recommendation from [`Readme.valgrind`](http://svn.python.org/projects/python/trunk/Misc/README.valgrind) I did the following.

1) Downloaded the python source with

    sudo apt-get build-dep python2.7
    apt-get source python2.7

2) Applied the code patch, i.e. &quot;Uncomment Py_USING_MEMORY_DEBUGGER in Objects/obmalloc.c&quot;.

3) Applied the suppression patch, i.e. &quot;Uncomment the lines in Misc/valgrind-python.supp that suppress the warnings for PyObject_Free and PyObject_Realloc&quot;

4) Compiled python with 

    ./configure --prefix=/home/dejan/workspace/python --without-pymalloc
    make -j4 install

Note that I did both 2 and 3, while README.valgrind says to do 2 or 3... more can&#39;t hurt. 

Now, let&#39;s test this on some sample python code in `test.py`

    print &quot;Test&quot;

Let&#39;s run valgrind on python with this script

    valgrind --tool=memcheck --leak-check=full --suppressions=python2.7-2.7.5/Misc/valgrind-python.supp bin/python test.py

Unexpectedly, there is still loads of reports from valgrind, with the first one being (and many more following) 

    ==27944== HEAP SUMMARY:
    ==27944==     in use at exit: 857,932 bytes in 5,144 blocks  
    ==27944==   total heap usage: 22,766 allocs, 17,622 frees, 4,276,934 bytes allocated
    ==27944== 
    ==27944== 38 bytes in 1 blocks are possibly lost in loss record 24 of 1,343
    ==27944==    at 0x4C2A2DB: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
    ==27944==    by 0x46B8DD: PyString_FromString (stringobject.c:143)
    ==27944==    by 0x439631: PyFile_FromFile (fileobject.c:157)
    ==27944==    by 0x4E9B4A: _PySys_Init (sysmodule.c:1383)
    ==27944==    by 0x4E29E9: Py_InitializeEx (pythonrun.c:222)
    ==27944==    by 0x4154B4: Py_Main (main.c:546)
    ==27944==    by 0x577DDE4: (below main) (libc-start.c:260)

Am I doing something wrong? Is there a way to valgrind a python script that doesn&#39;t leak and get clean valgrind output? 

How to use valgrind with python?

Or preferably all of them instead of just my code? My program uses Gtk, Loudmouth and few other things, and these two (and some behind them, libgcrypto, libssl) are causing so many errors themselves that I&#39;m unable to detect my own. Is it possible to make valgrind ignore things coming from deeper than my own code?

Is it possible to make valgrind ignore certain libraries?

I&#39;ve discovered a memory leak in my Rails code - that is to say, I&#39;ve found _what_ code leaks but not _why_ it leaks. I&#39;ve reduced it down to a test case that doesn&#39;t require Rails:

    require &#39;csspool&#39;
    require &#39;ruby-mass&#39;

    def report
    	puts &#39;Memory &#39; + `ps ax -o pid,rss | grep -E &quot;^[[:space:]]*#{$$}&quot;`.strip.split.map(&amp;:to_i)[1].to_s + &#39;KB&#39;
    	Mass.print
    end

    report

    # note I do not store the return value here
    CSSPool::CSS::Document.parse(File.new(&#39;/home/jason/big.css&#39;))

    ObjectSpace.garbage_collect
    sleep 1

    report

[ruby-mass](https://github.com/archan937/ruby-mass) supposedly lets me see all the objects in memory. [CSSPool](https://github.com/sparklemotion/csspool) is a CSS parser based on [racc](https://github.com/ruby/racc). /home/jason/big.css is [a 1.5MB CSS file](https://gist.github.com/JasonBarnabe/7799067).

This outputs:

    Memory 9264KB

    ==================================================
     Objects within [] namespace
    ==================================================
      String: 7261
      RubyVM::InstructionSequence: 1151
      Array: 562
      Class: 313
      Regexp: 181
      Proc: 111
      Encoding: 99
      Gem::StubSpecification: 66
      Gem::StubSpecification::StubLine: 60
      Gem::Version: 60
      Module: 31
      Hash: 29
      Gem::Requirement: 25
      RubyVM::Env: 11
      Gem::Specification: 8
      Float: 7
      Gem::Dependency: 7
      Range: 4
      Bignum: 3
      IO: 3
      Mutex: 3
      Time: 3
      Object: 2
      ARGF.class: 1
      Binding: 1
      Complex: 1
      Data: 1
      Gem::PathSupport: 1
      IOError: 1
      MatchData: 1
      Monitor: 1
      NoMemoryError: 1
      Process::Status: 1
      Random: 1
      RubyVM: 1
      SystemStackError: 1
      Thread: 1
      ThreadGroup: 1
      fatal: 1
    ==================================================

    Memory 258860KB

    ==================================================
     Objects within [] namespace
    ==================================================
      String: 7456
      RubyVM::InstructionSequence: 1151
      Array: 564
      Class: 313
      Regexp: 181
      Proc: 113
      Encoding: 99
      Gem::StubSpecification: 66
      Gem::StubSpecification::StubLine: 60
      Gem::Version: 60
      Module: 31
      Hash: 30
      Gem::Requirement: 25
      RubyVM::Env: 13
      Gem::Specification: 8
      Float: 7
      Gem::Dependency: 7
      Range: 4
      Bignum: 3
      IO: 3
      Mutex: 3
      Time: 3
      Object: 2
      ARGF.class: 1
      Binding: 1
      Complex: 1
      Data: 1
      Gem::PathSupport: 1
      IOError: 1
      MatchData: 1
      Monitor: 1
      NoMemoryError: 1
      Process::Status: 1
      Random: 1
      RubyVM: 1
      SystemStackError: 1
      Thread: 1
      ThreadGroup: 1
      fatal: 1
    ==================================================

You can see the memory going **way** up. Some of the counters go up, but no objects specific to CSSPool are present. I used ruby-mass&#39;s &quot;index&quot; method to inspect the objects that have references like so:

    Mass.index.each do |k,v|
    	v.each do |id|
    		refs = Mass.references(Mass[id])
    		puts refs if !refs.empty?
    	end
    end

But again, this doesn&#39;t give me anything related to CSSPool, just gem info and such.

I&#39;ve also tried outputting &quot;GC.stat&quot;...

    puts GC.stat
    CSSPool::CSS::Document.parse(File.new(&#39;/home/jason/big.css&#39;))
    ObjectSpace.garbage_collect
    sleep 1
    puts GC.stat

Result:

    {:count=&gt;4, :heap_used=&gt;126, :heap_length=&gt;138, :heap_increment=&gt;12, :heap_live_num=&gt;50924, :heap_free_num=&gt;24595, :heap_final_num=&gt;0, :total_allocated_object=&gt;86030, :total_freed_object=&gt;35106}
    {:count=&gt;16, :heap_used=&gt;6039, :heap_length=&gt;12933, :heap_increment=&gt;3841, :heap_live_num=&gt;13369, :heap_free_num=&gt;2443302, :heap_final_num=&gt;0, :total_allocated_object=&gt;3771675, :total_freed_object=&gt;3758306}

As I understand it, if an object is not referenced and garbage collection happens, then that object should be cleared from memory. But that doesn&#39;t seem to be what&#39;s happening here.

I&#39;ve also read about C-level memory leaks, and since CSSPool uses Racc which uses C code, I think this is a possibility. I&#39;ve run my code through Valgrind:

    valgrind --partial-loads-ok=yes --undef-value-errors=no --leak-check=full --fullpath-after= ruby leak.rb 2&gt; valgrind.txt

Results are [here](https://gist.github.com/JasonBarnabe/7862509). I&#39;m not sure if this confirms a C-level leak, as I&#39;ve also read that Ruby does things with memory that Valgrind doesn&#39;t understand.

Versions used:
&lt;ul&gt;
&lt;li&gt;Ruby 2.0.0-p247 (this is what my Rails app runs)&lt;/li&gt;
&lt;li&gt;Ruby 1.9.3-p392-ref (for testing with ruby-mass)&lt;/li&gt;
&lt;li&gt;ruby-mass 0.1.3&lt;/li&gt;
&lt;li&gt;CSSPool 4.0.0 from &lt;a href=&quot;https://github.com/sparklemotion/csspool/releases&quot;&gt;here&lt;/a&gt;&lt;/li&gt;
&lt;li&gt;CentOS 6.4 and Ubuntu 13.10&lt;/li&gt;
&lt;/ul&gt;

Finding the cause of a memory leak in Ruby

I am trying to use addr2line command in Unix but everytime it is giving the same output as ??:0. I am giving command as `addr2line -e  a.out  0x4005BDC` . I got this address while running this a.out executable with `valgrind` tool to find the memory leakage. I also compiled the source code with `-g` option. 

How to use the addr2line command in Linux?

I develop C++ applications in a Linux environment.  The tools I use every day include Eclipse with the CDT plugin, gdb and valgrind.  
What tools do other people use?  Is there anything out there for Linux that rivals the slickness of Microsoft Visual Studio?

What tools do you use to develop C++ applications on Linux?

When running my program with valgrind / callgrind I get the following message a lot:

```==21734== brk segment overflow in thread #1: can&#39;t grow to 0x4a39000```
(with different addresses)

Note that it is not preceded by a stack overflow message.

I can&#39;t find any documentation on this message and I have no idea what is overflowing exactly.

Can anybody help me figure out what the problem is? Is this a problem of valgrind, or of my program?

Valgrind reporting a segment overflow

In Linux, I have been using valgrind for checking if there are memory leaks in an application. What is the equivalent in Windows? Can this be done with Visual Studio 2010?


All Valgrind Solutions on Gang of Coders

Total of 20 Valgrind Solutions