It just means that the permissions changed on a particularly large block of memory.

That can happen because of something like a call to `mprotect` or when a very large memory allocation or deallocation occurs - an `mmap` or `munmap` call for example.

The first one you list is setting about 320Mb of memory to `undefined` which is most likely a new allocation, which will be marked as undefined initially. The others are both setting similar sized blocks to `noaccess` which probably relates to a deallocation of memory.

I tend to write rather large templated header-only C++ libraries and my users commonly complain about compilation times. After thinking about the matter, it occurred to me that *I have no idea where the time is going*. Is there some simple way to profile the C++ compilation process with common compilers, such as g++, icc, and xlC? For instance, is it possible to get an idea of how much time is spent within [each of the phases of C++ compilation](http://www.drdobbs.com/cpp/c-compilation-speed/228701711)?

Profiling the C++ compilation process

In many Redis tutorials (such as [this one][1]), data is stored in a set, but with multiple values combined together in a string (i.e. a user account might be stored in the set as two entries, &quot;user:1000:username&quot; and &quot;user:1000:password&quot;).

However, Redis also has hashes. It seems that it would make more sense to have a &quot;user:1000&quot; hash, which contains a &quot;username&quot; entry and a &quot;password&quot; entry. Rather than concatenating strings to access a particular value, you just access them directly in the hash.

So why isn&#39;t it used as much? Are these just old tutorials? Or do Redis hashes have performance issues?


  [1]: http://redis.io/topics/twitter-clone

Redis set vs hash

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

When I was running my program against valgrind, I encountered the following warning.
<pre><code class="hljs language-sql">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)
</code></pre>
After some googling I found at <a href="http://www.network-theory.co.uk/docs/valgrind/valgrind_29.html" target="_blank" rel="noopener noreferrer">here</a> that it is a <code>Diagnostic message, mostly for benefit of the Valgrind developers, to do with memory permissions</code>, which doesn'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 <code>realloc</code>'s)
However, the warning appeared despite none of the allocations failed.
So, I'm wondering what this message really means? I don't have some sort of memory permission? (But allocation succeeded)

Is there any way in Linux to assign one CPU core to a particular given process and there should not be any other processes or interrupt handlers to be scheduled on this core?

I have read about process affinity in Linux **Binding Processes to CPUs using the taskset utility** but that&#39;s not solving my problem because **it just try to affine the given process to that core but it is possible that other processes may be scheduled on this core** and this is what I want to avoid.

Should we change the kernel code for scheduling?

Whole one core dedicated to single process

How do I printf `long long int` and also `unsigned long long int` in C99 using GCC? 

I have searched the other posts which suggest to use `%lld` but it gives these warnings:

&gt; warning#1: unknown conversion type character &#39;l&#39; in format [-Wformat]|  
&gt; warning#2: too many arguments for format [-Wformat-extra-args]|

For the following attempt:

    #include &lt;stdio.h&gt;
    
    int main()
    {
       long long int x = 0;
       unsigned long long int y = 0;
       printf(&quot;%lld\n&quot;, x);
       printf(&quot;%llu\n&quot;, y);
    }

Printf long long int in C with GCC?

Let&#39;s say I have this struct

    typedef struct person{
        char firstName[100], surName[51]
    } PERSON;

and I am allocating space by malloc and filling it with some values

    PERSON *testPerson = (PERSON*) malloc(sizeof(PERSON));
    strcpy(testPerson-&gt;firstName, &quot;Jack&quot;);
    strcpy(testPerson-&gt;surName, &quot;Daniels&quot;);

What is the correct and safe way to free all memory taken by that struct? Is &quot;free(testPerson);&quot; enough or do I need to free each struct&#39;s attribute one by one?

It leads me to another question - how are structures stored in memory? I noticed a strange behaviour - when I try to print structure address it&#39;s equal to it&#39;s first attribute&#39;s address.

    printf(&quot;Structure address %d == firstName address %d&quot;, testPerson, testPerson-&gt;firstName);

Which means that this
    free(testPerson)
should be equal to this
    free(testPerson-&gt;firstName);

and that&#39;s not what I want to do.

Thanks

C - freeing structs

In one of my project source files, I found this C function definition:

    int (foo) (int *bar)
    {
        return foo (bar);
    }

Note: there is no asterisk next to `foo`, so it&#39;s not a function pointer. Or is it?
What is going on here with the recursive call?


What do the parentheses around a function name mean?

I am new to C/C++, so I have a couple of questions about a basic type: 


a) Can you explain to me the difference between `int64_t` and `long` (`long int`)? 
In my understanding, both are 64 bit integers. Is there any reason to choose one over the other?

b) I tried to look up the definition of `int64_t` on the web, without much success. Is there an authoritative source I need to consult for such questions?

c) For code using `int64_t` to compile, I am currently including `&lt;iostream&gt;`, which doesn&#39;t make much sense to me. Are there other includes that provide a declaration of `int64_t`?

Definition of int64_t

I just came [across this blog post][1] which mentions “stomping memory”:

&gt; a C++ program which is easily capable of stomping memory
    (something you probably have never even heard of if you were
    born in a managed code world.)

And in fact I have never heard of it!

So, what is this, a memory stomp, stomping memory? When does it occur?

  [1]: http://simpleprogrammer.com/2012/12/01/why-c-is-not-back/

What is a “memory stomp”?

Suppose I have a std::vector of structs. What happens to the memory if the vector is clear()&#39;d?

    std::vector&lt;myStruct&gt; vecs;
    vecs.resize(10000);
    vecs.clear();

Will the memory be freed, or still attached to the vecs variable as a reusable buffer?


 


Is std::vector memory freed upon a clear?

I am writing Python code to do some big number calculation, and have serious concern about the memory used in the calculation.

Thus, I want to count every bit of each variable.

For example, I have a variable **x**, which is a big number, and want to count the number of bits for representing **x**.

The following code is obviously useless:

    x=2**1000
    len(x)

Thus, I turn to use the following code:

    x=2**1000
    len(repr(x))

The variable **x** is (in decimal) is:
                       

&gt; 10715086071862673209484250490600018105614048117055336074437503883703510511249361224931983788156958581275946729175531468251871452856923140435984577574698574803934567774824230985421074605062371141877954182153046474983581941267398767559165543946077062914571196477686542167660429831652624386837205668069376

but the above code returns **303**

The above long long sequence is of length 302, and so I believe that **303** should be related to the string length only.

So, here comes my original question:

How can I know the memory size of variable **x**?

One more thing; in C/C++ language, if I define

    int z=1;

This means that there are 4 bytes= 32 bits allocated for **z**, and the bits are arranged as 00..001(31 0&#39;s and one 1).

Here, my variable **x** is huge, I don&#39;t know whether it follows the same memory allocation rule?  

Variable&#39;s memory size in Python

How are variables and memory managed in Python? Does it have a stack and a heap and what algorithm is used to manage memory? Given this knowledge are there any recommendations on memory management for large number/data crunching?

Does Python have a stack/heap and how is memory managed?

By considering that the memory is divided into four segments: data, heap, stack, and code, where do global variables, static variables, constant data types, local variables (defined and declared in functions), variables (in main function), pointers, and dynamically allocated space (using malloc and calloc) get stored in memory?

I think they would be allocated as follows:

- Global variables  -------&gt;  data
- Static variables  -------&gt;  data
- Constant data types -----&gt;  code
- Local variables (declared and defined in functions)  --------&gt;  stack
- Variables declared and defined in main function  -----&gt;  heap
- Pointers (for example, `char *arr`, `int *arr`) -------&gt;  heap
- Dynamically allocated space (using malloc and calloc) --------&gt; stack

I am referring to these variables only from the C perspective.

Please correct me if I am wrong as I am new to C.


Where in memory are my variables stored in C?

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?

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

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

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;

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?

Content Type	Original Author	Original Content on Stackoverflow
Question	Jimmy Lu	View Question on Stackoverflow
Solution 1 - C	TomH	View Answer on Stackoverflow

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

C Problem Overview

C Solutions

Solution 1 - C

Redis set vs hash

Profiling the C++ compilation process

Attributions