Question

我有一个可连接的pthread运行器函数，定义如下：

void *sumOfProducts(void *param)
{
...
pthread_exit(0);
}

该线程应该加入主线程。

每当我通过Valgrind运行我的程序时，我会得到以下泄漏：

LEAK SUMMARY:
   definitely lost: 0 bytes in 0 blocks
   indirectly lost: 0 bytes in 0 blocks
     possibly lost: 0 bytes in 0 blocks
   still reachable: 968 bytes in 5 blocks
        suppressed: 0 bytes in 0 blocks

ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 15 from 10)

我检查了pthreads的手册页，其中说：

  The new thread terminates in one of the following ways:

   * It  calls  pthread_exit(3),  specifying  an exit status value that is
     available  to  another  thread  in  the  same  process   that   calls
     pthread_join(3).

   * It  returns  from  start_routine().   This  is  equivalent to calling
     pthread_exit(3) with the value supplied in the return statement.

   * It is canceled (see pthread_cancel(3)).

   * Any of the threads in the process calls exit(3), or the  main  thread
     performs  a  return  from main().  This causes the termination of all
     threads in the process.

奇迹般地，当我用return语句替换pthread_exit（）时，泄漏消失了。

return(NULL);

我的实际问题是三管齐下的：

有人可以解释为什么return语句没有泄漏？
两个语句之间是否存在一些根本区别，与退出线程有关？
如果是这样，什么时候应该优先于另一个呢？

Answer 1

以下最小测试用例展示了您描述的行为：

#include <pthread.h>
#include <unistd.h>

void *app1(void *x)
{
    sleep(1);
    pthread_exit(0);
}

int main()
{
    pthread_t t1;

    pthread_create(&t1, NULL, app1, NULL);
    pthread_join(t1, NULL);

    return 0;
}

valgrind --leak-check=full --show-reachable=yes显示从pthread_exit()调用的函数分配的5个块，这些块不同意但在进程退出时仍可访问。如果pthread_exit(0);被return 0;替换，则不会分配5个块。

但是，如果您测试创建并加入大量线程，您会发现退出时使用的未同步内存量不会增加。这个以及它仍然可以访问的事实表明你只是看到了glibc实现的奇怪之处。几个glibc函数在第一次被调用时用malloc()分配内存，它们在进程生命周期的剩余时间内保持分配。 glibc并不打算在进程退出时释放这个内存，因为它知道该进程正在被拆除 - 它只是浪费CPU周期。

Answer 2

不确定您是否仍然对此感兴趣，但我目前正在调试类似的情况。使用pthread_exit的线程会导致valgrind报告可访问的块。原因似乎在这里得到了很好的解释：

https://bugzilla.redhat.com/show_bug.cgi?id=483821

基本上似乎pthread_exit会导致dlopen在进程退出时从未明确清除。

Answer 3

看起来调用exit（）（显然，pthread_exit（））会自动分配已分配的变量。您必须返回或投掷才能正确放松。

每C++ valgrind possible leaks on STL string：

@Klaim：我不知道该文件在哪里说我错了，但是如果它确实是错的。引用C ++标准（第18.3 / 8节）： “由于调用exit（），自动对象不会被销毁。” - James McNellis 2010年9月10日19:11

由于做“返回0”而不是“pthread_exit（0）”似乎解决了你的问题（而且我的...谢谢），我假设两者之间的行为相似。

Answer 4

你真的在使用C ++吗？为了澄清 - 您的源文件以.c扩展名结尾，并且您使用gcc而不是g++进行编译？

您的函数似乎很有可能在函数返回时分配您希望自动清理的资源。像std::vector或std::string这样的本地C ++对象会执行此操作，如果您调用pthread_exit，它们的析构函数可能无法运行，但如果您返回则会被清除。

我的偏好是避免使用pthread_exit之类的低级API，并且在可能的情况下始终只是从线程函数返回。它们是等价的，除了pthread_exit是一个事实上的流控制结构，绕过你正在使用的语言，但return没有。

Answer 5

我有经验，valgrind很难跟踪为可连接线程状态分配的存储。（这与caf指示的方向相同。）

因为你似乎总是返回0的值，我想你可能需要从应用程序的角度加入你的线程？如果是这样，考虑从一开始就分离启动它们，这就避免了内存的分配。

缺点是你要么：

在...处实施自己的障碍你的main结束了。如果你知道的话事先的线程数，a 简单的静态分配 pthread_barrier会这样做。
或退出main pthread_exit这样你就不会杀掉剩下的正在运行的线程可能尚未完成。

Answer 6

Valgrind 很难跟踪 pthread_exit 变量，这就是为什么使用 pthread_exit 时它会显示内存泄漏并带有仍然可达的标签；但不是在返回的情况下。

pthread_exit与return

6 个答案: