需要 valgrind 帮助
我的应用程序在一种情况下导致 10m 的内存泄漏。但是当我用 valgrind 调试时，以下是泄漏摘要。
812 ==18074== LEAK SUMMARY:
813 ==18074== definitely lost: 0 bytes in 0 blocks.
814 ==18074== possibly lost: 3,424 bytes in 20 blocks.
815 ==18074== still reachable: 10,422 bytes in 47 blocks.
816 ==18074== suppressed: 0 bytes in 0 blocks.
我能从这个总结中得到什么？我能说申请没有问题吗？
有人也可以解释以下内容吗？创建线程时可能出现什么问题？我什至没有传递动态分配的东西作为线程参数。
795 ==18074== 2,448 bytes in 17 blocks are possibly lost in loss record 32 of 33
796 ==18074== at 0x40056BF: calloc (vg_replace_malloc.c:279)
797 ==18074== by 0xC0D71A: _dl_allocate_tls (in /lib/ld-2.3.4.so)
798 ==18074== by 0xD8A91E: pthread_create@@GLIBC_2.1 (in /lib/tls/libpthread-2.3.4.so)
799 ==18074== by 0x8056A28: Server::intithreads() (ServerProcess.cpp:899)
800 ==18074== by 0x8054E39: main (ServerProcess.h:85)
My application is causing 10m of memory leak in one scenario. But when i debugged with valgrind, the following is the leak summary.
812 ==18074== LEAK SUMMARY:
813 ==18074== definitely lost: 0 bytes in 0 blocks.
814 ==18074== possibly lost: 3,424 bytes in 20 blocks.
815 ==18074== still reachable: 10,422 bytes in 47 blocks.
816 ==18074== suppressed: 0 bytes in 0 blocks.
what could i derive from this summary? can i say that there is no problem with application?
can somebody explain the following also? what could be the issue in creating thread? I am not even passing something dynamically allocated as thread argument.
795 ==18074== 2,448 bytes in 17 blocks are possibly lost in loss record 32 of 33
796 ==18074== at 0x40056BF: calloc (vg_replace_malloc.c:279)
797 ==18074== by 0xC0D71A: _dl_allocate_tls (in /lib/ld-2.3.4.so)
798 ==18074== by 0xD8A91E: pthread_create@@GLIBC_2.1 (in /lib/tls/libpthread-2.3.4.so)
799 ==18074== by 0x8056A28: Server::intithreads() (ServerProcess.cpp:899)
800 ==18074== by 0x8054E39: main (ServerProcess.h:85)
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
我不会太担心“仍然可达”的块。由于所有块都会在程序退出时释放，因此无需专门释放每个块。为了改善这种情况，您可以尝试在程序的中间阶段释放块，之后就不需要它们了。另一方面，“可能丢失”的块的性质稍微严重一些。
无论如何，来自 Valgrind 手册：
I wouldn't worry much about the "still reachable" blocks. Since all blocks are freed upon program exit, it isn't necessary to specifically free each block. To better the situation, you can try freeing blocks at intermediate stages in your program, beyond which you don't require them. On the other hand, "possibly lost" blocks are of slightly more serious nature.
In any case, from the Valgrind manual:
根据内存泄漏报告，您的应用程序可能存在问题。
如果“肯定丢失”、“可能丢失”或“仍然可达”中的任何一个大于 0，则存在内存泄漏。
“肯定丢失”意味着有未释放的内存，并且在程序终止时不存在指向它的变量，因为例如变量超出了范围。这意味着泄漏将很难修复，因为您需要找到丢弃它们的位置。
“可能丢失”表示存在未释放的内存，并且您确实在程序终止时有指向它的变量，但它们可能无法用于释放内存，因为它们是内部指针，而不是指针到块的开头，您需要将其传递给
free。“仍然可达”表示存在未释放的内存，但在程序终止时由变量直接指向它。这意味着虽然存在泄漏，但它不会增长，因此不会那么严重。
There may be problems with your application according to the memory leak report.
If any of "definitely lost", "possibly lost" or "still reachable" are greater than 0, then you have a memory leak.
"Definitely lost" means that there was unfreed memory, and no variables pointing to it existed at program termination, because for example the variables went out of scope. This means that the leak will be difficult to fix, because you will need to find where you discarded them.
"Possibly lost" indicates that there was unfreed memory, and you did have variables pointing to it at program termination, but they were probably not usable to free the memory, because they were internal pointers, rather than pointers to the beginning of the block, which you need to pass to
free."Still reachable" indicates that there was unfreed memory, but it was directly pointed to by variables at program termination. This means that although there is a leak, it is not one that can grow and so is not so serious.