pthread_create在valgrind中存在内存泄漏。

3

这是我代码的简化版本:

#include <pthread.h>
#include <stdio.h>

void* handle_client(void* arg);

int main(int argc, char *argv[])
{
    pthread_t pthr_handle;
    pthread_create(&pthr_handle, NULL, &handle_client, NULL);
    pthread_detach(pthr_handle);
    pthread_exit(NULL);
    return 0;
}

void* handle_client(void* arg)
{
    printf("Hello from thread!\n");
    pthread_exit(NULL);
    return NULL;
}

当我在这个程序上使用valgrind时,它显示:

可能已丢失:1个块中的272字节

问题是,并不是每次运行它都会显示这个错误。有时候它会说没有内存泄漏。因此我相信没有内存泄漏,而这个消息与主线程退出后仍在运行的线程有关。pthread_exit调用难道不应该使主线程等待其他线程退出吗?我能做些什么来让valgrind停止指责内存泄漏呢?


1
Valgrind本身可能无法处理仍在运行的线程,因此如果主线程退出而分离的线程仍未完成,则会看到内存泄漏。如果分离的线程在主线程退出之前完成,则一切都会很好。 - Some programmer dude
1
有什么方法可以让Valgrind停止指责内存泄漏吗?这里提供一个可能有用的链接:https://dev59.com/B2gu5IYBdhLWcg3wDS0G。但请记住,程序分配的内存在`main()`返回后会被归还给操作系统。 - ryyker
1个回答

3

Valgrind无法处理主线程之后分离线程退出时所执行的清理操作。

运行valgrind时,请添加--gen-suppressions=yes标志:

[dbush@db-centos7 ~]$ valgrind --leak-check=full --gen-suppressions=yes ./x1
==18866== Memcheck, a memory error detector
==18866== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al.
==18866== Using Valgrind-3.15.0 and LibVEX; rerun with -h for copyright info
==18866== Command: ./x1
==18866== 
Hello from thread!
==18866== 
==18866== HEAP SUMMARY:
==18866==     in use at exit: 560 bytes in 1 blocks
==18866==   total heap usage: 6 allocs, 5 frees, 2,192 bytes allocated
==18866== 
==18866== 560 bytes in 1 blocks are possibly lost in loss record 1 of 1
==18866==    at 0x4C2C089: calloc (vg_replace_malloc.c:762)
==18866==    by 0x4012784: _dl_allocate_tls (in /usr/lib64/ld-2.17.so)
==18866==    by 0x4E3F87B: pthread_create@@GLIBC_2.2.5 (in /usr/lib64/libpthread-2.17.so)
==18866==    by 0x400742: main (x1.c:12)
==18866== 
==18866== 
==18866== ---- Print suppression ? --- [Return/N/n/Y/y/C/c] ---- y
{
   <insert_a_suppression_name_here>
   Memcheck:Leak
   match-leak-kinds: possible
   fun:calloc
   fun:_dl_allocate_tls
   fun:pthread_create@@GLIBC_2.2.5
   fun:main
}
==18866== LEAK SUMMARY:
==18866==    definitely lost: 0 bytes in 0 blocks
==18866==    indirectly lost: 0 bytes in 0 blocks
==18866==      possibly lost: 560 bytes in 1 blocks
==18866==    still reachable: 0 bytes in 0 blocks
==18866==         suppressed: 0 bytes in 0 blocks
==18866== 
==18866== For lists of detected and suppressed errors, rerun with: -s
==18866== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 0 from 0)

在上述输出中,如果您回答“Y”以进行打印压制,则会生成一个压制记录。 您可以将此记录添加到文件中(在其中添加名称,例如“<insert_a_suppression_name_here>”),然后使用--suppressions标志将该文件传递给valgrind:

[dbush@db-centos7 ~]$ valgrind  --suppressions=sup1 ./x1
==18899== Memcheck, a memory error detector
==18899== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al.
==18899== Using Valgrind-3.15.0 and LibVEX; rerun with -h for copyright info
==18899== Command: ./x1
==18899== 
Hello from thread!
==18899== 
==18899== HEAP SUMMARY:
==18899==     in use at exit: 560 bytes in 1 blocks
==18899==   total heap usage: 6 allocs, 5 frees, 2,192 bytes allocated
==18899== 
==18899== LEAK SUMMARY:
==18899==    definitely lost: 0 bytes in 0 blocks
==18899==    indirectly lost: 0 bytes in 0 blocks
==18899==      possibly lost: 0 bytes in 0 blocks
==18899==    still reachable: 0 bytes in 0 blocks
==18899==         suppressed: 560 bytes in 1 blocks
==18899== 
==18899== For lists of detected and suppressed errors, rerun with: -s
==18899== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)

现在它显示为“被抑制”的泄漏,即您知道它的存在,并可以安全地忽略它。

网页内容由stack overflow 提供, 点击上面的
可以查看英文原文,
原文链接