gpt4 book ai didi

c++ new运算符通过libstdc++占用大量内存(67MB)

转载 作者:塔克拉玛干 更新时间:2023-11-02 23:38:20 24 4
gpt4 key购买 nike

我对 libstdc++ 中的 new 运算符有一些疑问。我用 C++ 编写了一个程序,但在内存管理方面遇到了一些问题。

在用 gdb 调试以确定是什么在消耗我的 ram 之后,我得到了以下 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

那只是从中剪下来的。然而,一切都很正常。其中一些属于标准库的代码,一些属于堆,一些属于我创建的线程的堆栈部分。

但是。有这一节我不明白为什么要分配它:

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

这两个部分是在看似随机的时间创建的。有几个小时的调试没有时间上的相似性,也没有在某个创建的线程左右。我用 awatch *0x7ffff0000000 设置了一个硬件观察点,并再次给它几次 run

这两个部分几乎同时在不可调试函数的同一代码部分中创建(gdb 在堆栈中将其显示为 in ?? () from/lib/x86_64-linux-gnu/libc .so.6).更准确地说,这是它发生的示例堆栈:

#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

这里是另一个例子(来自 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

整个事情表明它发生在从 pthread 库调用的 calloc 或在另一种情况下它是 new operatormalloc 从中调用。它是哪个 new 并不重要 - 在几次运行中,它几乎在我的代码中的每个 new 或线程创建时发生。它唯一“不变”的是它每次都出现在 libc.so.6 中。

无论代码在哪一点,
无论与malloc还是calloc一起使用,
无论程序运行了多长时间,
无论创建了多少线程后,
它始终是该部分:0x7ffff0000000 - 0x7ffff4000000。

每次程序运行时。但每次都在程序的另一点。我真的很困惑,因为它分配了 67MB 的虚拟空间,但它没有使用它。当观察它在那里创建的变量时,特别是观察那些在 malloccalloc 被 libc 调用时创建的变量,这些空间都没有被它们使用。它们是在远离该地址范围 (0x7ffff0000000 - 0x7ffff4000000) 的堆部分中创建的。


编辑:

我也检查了父进程的堆栈大小,得到了 8388608 字节的使用量,即 0x800000 (~8MB)。为了获得这些值,我做了:

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);

请帮助我。我真的很困惑。

最佳答案

看起来是在为线程分配栈空间。
当您在线程中进行函数调用时,将使用该空间。

但实际上正在做什么与您无关。它是 pthread_create() 内部实现的一部分,它可以在那里做任何它喜欢的事情。

关于c++ new运算符通过libstdc++占用大量内存(67MB),我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/13850362/

24 4 0
Copyright 2021 - 2024 cfsdn All Rights Reserved 蜀ICP备2022000587号
广告合作:1813099741@qq.com 6ren.com