c++ - 释放范围内的所有指针后仍可访问内存

Question

在我的主要功能中，我使用 new 创建了三个对象。然后我删除它们。通过 Valgrind 运行显示 8 字节的仍可访问的内存。我试过将整个 main 函数放在一个循环中，以便它运行多次。它仍然只有 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(它是设置的成员)。我曾尝试将 _access 更改为指针并在构造函数/析构函数中分配/删除无济于事。升级锁在超出范围时应该被解构。

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

我意识到这不是一个主要问题，但它很烦人(而且同伴不让我忘记它)

有什么想法吗？

Answer 1

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

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

Is that really a memory leak?

很可能不会。有问题的内存由 pthread_key_create 的删除器释放，这意味着当(主)线程退出时。 valgrind 显然在此之前进行了泄漏检查。

虽然有discussions关于这是否不是 Boost 错误，我认为您不应该为您的应用程序担心这个问题:它是 (a) 不会增长的一次性泄漏，并且 (b) 不是由问题引起的你的代码。