在释放了所有作用域内指针之后仍然可访问内存

Still Reachable Memory after all in scope pointers are Freed

本文关键字：之后 内存 访问 指针 放了 释放 作用域      更新时间：2023-10-16

在我的主函数中，我用new创建了三个对象。然后我删除了它们。运行Valgrind显示了8字节的仍然可访问的内存。我试着把整个主函数固定在一个循环中，这样它就可以运行多次。它仍然只有8个字节。

我的主页-

int main()
{
settings *st = new settings();
thread_data *td = new thread_data(st);
client_handler *cl = new client_handler(td);
delete cl;
delete td;
delete st;
}

相关valgrind输出-

==24985== 8 bytes in 1 blocks are still reachable in loss record 1 of 1
==24985==    at 0x4C2CD7B: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==24985==    by 0x4E494F9: boost::detail::get_once_per_thread_epoch() (in /usr/lib/libboost_thread.so.1.49.0)
==24985==    by 0x4E4182F: ??? (in /usr/lib/libboost_thread.so.1.49.0)
==24985==    by 0x4E41B08: boost::detail::get_current_thread_data() (in /usr/lib/libboost_thread.so.1.49.0)
==24985==    by 0x4E41D58: boost::this_thread::interruption_enabled() (in /usr/lib/libboost_thread.so.1.49.0)
==24985==    by 0x4E41D88: boost::this_thread::disable_interruption::disable_interruption() (in /usr/lib/libboost_thread.so.1.49.0)
==24985==    by 0x421854: boost::shared_mutex::lock_upgrade() (shared_mutex.hpp:195)
==24985==    by 0x423A3B: boost::upgrade_lock<boost::shared_mutex>::lock() (locks.hpp:875)
==24985==    by 0x422FA6: boost::upgrade_lock<boost::shared_mutex>::upgrade_lock(boost::shared_mutex&) (locks.hpp:766)
==24985==    by 0x41E15C: settings::load() (settings.cpp:91)
==24985==    by 0x41D796: settings::settings() (settings.cpp:34)
==24985==    by 0x40A3BB: main (main.cpp:26)

settings:：load()只从构造函数调用一次。91号线是的第一条线

bool settings::load()
{
boost::upgrade_lock<boost::shared_mutex> lock(_access);
boost::upgrade_to_unique_lock<boost::shared_mutex> uniqueLock(lock);

我不明白记忆怎么还可以得到。设置对象将被删除_当调用设置构造函数(它是设置的成员)时，应该删除访问权限。我尝试将_access更改为指针&在构造函数/析构函数中分配/删除无效。当升级锁超出范围时，应该对其进行解构。

即使内存泄漏(据我所知，boost:：thread(1.49版本)中没有已知的错误)，内存肯定会丢失吗？

我意识到这不是一个大问题，但这是一个令人恼火的问题(同行不会让我忘记这件事)

有什么想法吗？

根据Boost线程泄漏C++和http://boost.2283326.n4.nabble.com/thread-Memory-leak-in-Boost-Thread-td2648030.html这不是Boost中的实际内存泄漏，而是Valgrind中的问题。

IIUC报告泄漏是因为Boost在Valgrind无法再检测到的时候释放了内存。来自第二个链接：

这真的是内存泄漏吗？

很可能不是。有问题的内存由pthreadkeycreate的deleter释放，这意味着当(主)线程退出时。valgrind显然在那之前做过泄漏检查。

虽然有人讨论这是否不是Boost错误，但我认为您不应该担心应用程序的这个问题：它(a)是一个不会增长的一次性泄漏，(b)不是由代码中的问题引起的。

相关文章：