Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

c++ new operator takes lots of memory (67MB) via libstdc++

I have some issues with the new operator in libstdc++. I wrote a program in C++ and had some problems with the memory management.

After having debugged with gdb to determine what is eating up my ram I got the following for info proc mappings

Mapped address spaces:

      Start Addr           End Addr       Size     Offset objfile
        0x400000           0x404000     0x4000          0                             /home/sebastian/Developement/powerserverplus-svn/psp-job-distributor/Release/psp-job-distributor
        0x604000           0x605000     0x1000     0x4000                             /home/sebastian/Developement/powerserverplus-svn/psp-job-distributor/Release/psp-job-distributor
        0x605000           0x626000    0x21000          0                                   [heap]
  0x7ffff0000000     0x7ffff0021000    0x21000          0        
  0x7ffff0021000     0x7ffff4000000  0x3fdf000          0       
  0x7ffff6c7f000     0x7ffff6c80000     0x1000          0        
  0x7ffff6c80000     0x7ffff6c83000     0x3000          0        
  0x7ffff6c83000     0x7ffff6c84000     0x1000          0        
  0x7ffff6c84000     0x7ffff6c87000     0x3000          0        
  0x7ffff6c87000     0x7ffff6c88000     0x1000          0        
  0x7ffff6c88000     0x7ffff6c8b000     0x3000          0        
  0x7ffff6c8b000     0x7ffff6c8c000     0x1000          0        
  0x7ffff6c8c000     0x7ffff6c8f000     0x3000          0        
  0x7ffff6c8f000     0x7ffff6e0f000   0x180000          0                     /lib/x86_64-linux-gnu/libc-2.13.so
  0x7ffff6e0f000     0x7ffff700f000   0x200000   0x180000                     /lib/x86_64-linux-gnu/libc-2.13.so
  0x7ffff700f000     0x7ffff7013000     0x4000   0x180000                     /lib/x86_64-linux-gnu/libc-2.13.so
  0x7ffff7013000     0x7ffff7014000     0x1000   0x184000                     /lib/x86_64-linux-gnu/libc-2.13.so

That's just snipped out of it. However, everything is normal. Some of this belongs to the code for the standard libs, some if it is heap and some of it are stack sections for threads I created.

But. there is this one section I id not figure out why it is allocated:

  0x7ffff0000000     0x7ffff0021000    0x21000          0        
  0x7ffff0021000     0x7ffff4000000  0x3fdf000          0 

These two sections are created at a seemlike random time. There is several hours of debugging no similarity in time nor at a certain created thread or so. I set a hardware watch point with awatch *0x7ffff0000000 and gave it several runs again.

These two sections are created at nearly the same time within the same code section of a non-debuggable function (gdb shows it in stack as in ?? () from /lib/x86_64-linux-gnu/libc.so.6). More exact this is a sample stack where it occured:

#0  0x00007ffff6d091d5 in ?? () from /lib/x86_64-linux-gnu/libc.so.6
#1  0x00007ffff6d0b2bd in calloc () from /lib/x86_64-linux-gnu/libc.so.6
#2  0x00007ffff7dee28f in _dl_allocate_tls () from /lib64/ld-linux-x86-64.so.2
#3  0x00007ffff77c0484 in pthread_create@@GLIBC_2.2.5 () from /lib/x86_64-linux-gnu/libpthread.so.0
#4  0x00007ffff79d670e in Thread::start (this=0x6077c0) at ../src/Thread.cpp:42
#5  0x000000000040193d in MultiThreadedServer<JobDistributionServer_Thread>::Main (this=0x7fffffffe170) at /home/sebastian/Developement/powerserverplus-svn/mtserversock/src/MultiThreadedServer.hpp:55
#6  0x0000000000401601 in main (argc=1, argv=0x7fffffffe298) at ../src/main.cpp:29

Another example would be here (from a differet run):

#0  0x00007ffff6d091d5 in ?? () from /lib/x86_64-linux-gnu/libc.so.6
#1  0x00007ffff6d0bc2d in malloc () from /lib/x86_64-linux-gnu/libc.so.6
#2  0x00007ffff751607d in operator new(unsigned long) () from /usr/lib/x86_64-linux-gnu/libstdc++.so.6
#3  0x000000000040191b in MultiThreadedServer<JobDistributionServer_Thread>::Main (this=0x7fffffffe170) at /home/sebastian/Developement/powerserverplus-svn/mtserversock/src/MultiThreadedServer.hpp:53
#4  0x0000000000401601 in main (argc=1, argv=0x7fffffffe298) at ../src/main.cpp:29

The whole thing says that it occurs at the calloc called from the pthread lib or in another situation it was the new operator or the malloc called from it. It doesn't matter which new it is - in several runs it occured at nearly every new or thread creation in my code. The only "constant" thing with it is that it occurs every time in the libc.so.6.

No matter at which point of the code,
no matter if used with malloc or calloc,
no matter after how much time the program ran,
no matter after how many threads have been created,
it is always that section: 0x7ffff0000000 - 0x7ffff4000000.

Everytime the program runs. But everytime at another point in the program. I am really confused because it allocated 67MB of virtual space but it does not use it. When watching the variables it created there, especially watched those which are created when malloc or calloc were called by libc, none of this space is used by them. They are created in a heap section which is far away from that address range (0x7ffff0000000 - 0x7ffff4000000).


Edit:

I checked the stack size of the parent process too and got a usage of 8388608 Bytes, which is 0x800000 (~8MB). To get these values I did:

pthread_attr_t attr;
size_t stacksize;
struct rlimit rlim;

pthread_attr_init(&attr);
pthread_attr_getstacksize(&attr, &stacksize);
getrlimit(RLIMIT_STACK, &rlim);
fit into a size_t variable. */
printf("Resource limit: %zd\n", (size_t) rlim.rlim_cur);
printf("Stacksize: %zd\n", stacksize);
pthread_attr_destroy(&attr);

Please help me with that. I am really confused about that.

like image 485
Sebastian Büttner Avatar asked Dec 12 '12 23:12

Sebastian Büttner


1 Answers

It looks like it is allocating a stack space for a thread.
The space will be used as you make function calls in the thread.

But really what is is doing is none of your business. It is part of the internal implementation of pthread_create() it can do anything it likes in there.

like image 75
Martin York Avatar answered Oct 04 '22 21:10

Martin York