c pthread 仍然可以访问-6ren

c pthread 仍然可以访问

转载作者：行者123 更新时间：2023-12-05 03:22:50

我在我的程序中使用 pthread。它运行良好，但 valgrind 检测到仍然可以访问。始终相同的字节:1654、4 个 block 。始终在 valgrind 中看到相同的功能。

Valgrind 日志:

==29908== Memcheck, a memory error detector
==29908== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al.
==29908== Using Valgrind-3.15.0 and LibVEX; rerun with -h for copyright info
==29908== Command: ./a.out
==29908== Parent PID: 23902
==29908== 
==29908== 
==29908== HEAP SUMMARY:
==29908==     in use at exit: 1,654 bytes in 4 blocks
==29908==   total heap usage: 8 allocs, 4 frees, 2,526 bytes allocated
==29908== 
==29908== 36 bytes in 1 blocks are still reachable in loss record 1 of 4
==29908==    at 0x483B7F3: malloc (in /usr/lib/x86_64-linux-gnu/valgrind/vgpreload_memcheck-amd64-linux.so)
==29908==    by 0x401F5CE: strdup (strdup.c:42)
==29908==    by 0x4019A81: _dl_load_cache_lookup (dl-cache.c:338)
==29908==    by 0x400A989: _dl_map_object (dl-load.c:2102)
==29908==    by 0x4015D36: dl_open_worker (dl-open.c:513)
==29908==    by 0x49DF8B7: _dl_catch_exception (dl-error-skeleton.c:208)
==29908==    by 0x40155F9: _dl_open (dl-open.c:837)
==29908==    by 0x49DE860: do_dlopen (dl-libc.c:96)
==29908==    by 0x49DF8B7: _dl_catch_exception (dl-error-skeleton.c:208)
==29908==    by 0x49DF982: _dl_catch_error (dl-error-skeleton.c:227)
==29908==    by 0x49DE994: dlerror_run (dl-libc.c:46)
==29908==    by 0x49DE994: __libc_dlopen_mode (dl-libc.c:195)
==29908==    by 0x486E99A: pthread_cancel_init (unwind-forcedunwind.c:53)
==29908== 
==29908== 36 bytes in 1 blocks are still reachable in loss record 2 of 4
==29908==    at 0x483B7F3: malloc (in /usr/lib/x86_64-linux-gnu/valgrind/vgpreload_memcheck-amd64-linux.so)
==29908==    by 0x400D5A7: _dl_new_object (dl-object.c:196)
==29908==    by 0x4006E96: _dl_map_object_from_fd (dl-load.c:997)
==29908==    by 0x400A61A: _dl_map_object (dl-load.c:2236)
==29908==    by 0x4015D36: dl_open_worker (dl-open.c:513)
==29908==    by 0x49DF8B7: _dl_catch_exception (dl-error-skeleton.c:208)
==29908==    by 0x40155F9: _dl_open (dl-open.c:837)
==29908==    by 0x49DE860: do_dlopen (dl-libc.c:96)
==29908==    by 0x49DF8B7: _dl_catch_exception (dl-error-skeleton.c:208)
==29908==    by 0x49DF982: _dl_catch_error (dl-error-skeleton.c:227)
==29908==    by 0x49DE994: dlerror_run (dl-libc.c:46)
==29908==    by 0x49DE994: __libc_dlopen_mode (dl-libc.c:195)
==29908==    by 0x486E99A: pthread_cancel_init (unwind-forcedunwind.c:53)
==29908== 
==29908== 384 bytes in 1 blocks are still reachable in loss record 3 of 4
==29908==    at 0x483DD99: calloc (in /usr/lib/x86_64-linux-gnu/valgrind/vgpreload_memcheck-amd64-linux.so)
==29908==    by 0x401330A: _dl_check_map_versions (dl-version.c:274)
==29908==    by 0x40160EC: dl_open_worker (dl-open.c:577)
==29908==    by 0x49DF8B7: _dl_catch_exception (dl-error-skeleton.c:208)
==29908==    by 0x40155F9: _dl_open (dl-open.c:837)
==29908==    by 0x49DE860: do_dlopen (dl-libc.c:96)
==29908==    by 0x49DF8B7: _dl_catch_exception (dl-error-skeleton.c:208)
==29908==    by 0x49DF982: _dl_catch_error (dl-error-skeleton.c:227)
==29908==    by 0x49DE994: dlerror_run (dl-libc.c:46)
==29908==    by 0x49DE994: __libc_dlopen_mode (dl-libc.c:195)
==29908==    by 0x486E99A: pthread_cancel_init (unwind-forcedunwind.c:53)
==29908==    by 0x486EBB3: _Unwind_ForcedUnwind (unwind-forcedunwind.c:127)
==29908==    by 0x486CF05: __pthread_unwind (unwind.c:121)
==29908== 
==29908== 1,198 bytes in 1 blocks are still reachable in loss record 4 of 4
==29908==    at 0x483DD99: calloc (in /usr/lib/x86_64-linux-gnu/valgrind/vgpreload_memcheck-amd64-linux.so)
==29908==    by 0x400D273: _dl_new_object (dl-object.c:89)
==29908==    by 0x4006E96: _dl_map_object_from_fd (dl-load.c:997)
==29908==    by 0x400A61A: _dl_map_object (dl-load.c:2236)
==29908==    by 0x4015D36: dl_open_worker (dl-open.c:513)
==29908==    by 0x49DF8B7: _dl_catch_exception (dl-error-skeleton.c:208)
==29908==    by 0x40155F9: _dl_open (dl-open.c:837)
==29908==    by 0x49DE860: do_dlopen (dl-libc.c:96)
==29908==    by 0x49DF8B7: _dl_catch_exception (dl-error-skeleton.c:208)
==29908==    by 0x49DF982: _dl_catch_error (dl-error-skeleton.c:227)
==29908==    by 0x49DE994: dlerror_run (dl-libc.c:46)
==29908==    by 0x49DE994: __libc_dlopen_mode (dl-libc.c:195)
==29908==    by 0x486E99A: pthread_cancel_init (unwind-forcedunwind.c:53)
==29908== 
==29908== LEAK SUMMARY:
==29908==    definitely lost: 0 bytes in 0 blocks
==29908==    indirectly lost: 0 bytes in 0 blocks
==29908==      possibly lost: 0 bytes in 0 blocks
==29908==    still reachable: 1,654 bytes in 4 blocks
==29908==         suppressed: 0 bytes in 0 blocks
==29908== 
==29908== For lists of detected and suppressed errors, rerun with: -s
==29908== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)

如果我将程序限制为 1 个线程，我将永远无法获得任何仍然可访问的线程。如果我将它限制在像 2 这样低的值，我有时会这样做，有时不会。任何高值 (48) 都意味着我几乎总是可以到达。

我设法在没有太多代码的情况下重现了这个问题，如下所示。我究竟做错了什么？如果我没有做错任何事情而只是 pthread 的事情，为什么它仍然可以访问？为什么它是半随机的取决于线程的数量？

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

#define NUMTHREADS  2 //can be anything higher than 1 to cause still reachables

void    *thread(void *arg)
{
    (void)arg;
    pthread_exit(EXIT_SUCCESS);
}

int main(void)
{
    int         i;
    pthread_t   threads[NUMTHREADS];

    i = -1;
    while (++i < NUMTHREADS)
        pthread_create(threads + i, NULL, &thread, NULL);
    i = -1;
    while (++i < NUMTHREADS)
        pthread_join(threads[i], NULL);
    return (0);
}

最佳答案

在您的thread 函数中，您正在做:

pthread_exit(EXIT_SUCCESS);

替换为:

return (void *) 0;

Perfect, thank you. Any downsides to exiting threads this way? Do you also have any idea what in pthread is causing these still reachables or why this solution works? –Modin

pthread_create 的 [linux，至少] 实现不将您为线程函数提供的参数(例如，在您的情况下 thread) 作为给 clone 系统调用的线程起始地址。它给出了指向内部/隐藏的“助手”启动函数的指针，该函数执行以下操作:

一些线程本地存储的初始化等(可能需要调用malloc)。
调用“真正的”函数
TLS 清理/析构函数

如果我们调用 pthread_exit，我们将绕过步骤 (3)。

要查看详细信息，我们必须获取 glibc 源代码并查看 nptl/pthread_create.c 中被 not 绕过的大约 10 个步骤返回。

就个人而言，我总是“展开”我的调用堆栈以使用 return (void *) 并且只调用 pthread_exit 作为“中止”

编辑:

如果我们查看 pthread_exit 的源代码，它会调用 __do_cancel [一个内部函数]。所以，这就像做:

pthread_cancel(pthread_self());

给定[修改后的]程序:

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

#define NUMTHREADS  8                   // can be anything higher than 1 to cause still reachables

void *
thread(void *arg)
{
#if DOEXIT
    (void) arg;
    pthread_exit(EXIT_SUCCESS);
#else
    return (void *) 0;
#endif
}

int
main(void)
{
    int i;
    pthread_t threads[NUMTHREADS];

    i = -1;
    while (++i < NUMTHREADS)
        pthread_create(threads + i, NULL, &thread, NULL);
    i = -1;
    while (++i < NUMTHREADS)
        pthread_join(threads[i], NULL);
    return (0);
}

注意在下面的测试输出中，valgrind 命令是:

valgrind --leak-check=full --show-leak-kinds=all -s ./fix0

这是使用 -DDOEXIT=1 编译的输出(执行 pthread_exit):

==1659955== Memcheck, a memory error detector
==1659955== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al.
==1659955== Using Valgrind-3.15.0 and LibVEX; rerun with -h for copyright info
==1659955== Command: ./fix0
==1659955==
==1659955==
==1659955== HEAP SUMMARY:
==1659955==     in use at exit: 1,616 bytes in 4 blocks
==1659955==   total heap usage: 13 allocs, 9 frees, 3,848 bytes allocated
==1659955==
==1659955== 21 bytes in 1 blocks are still reachable in loss record 1 of 4
==1659955==    at 0x483780B: malloc (vg_replace_malloc.c:309)
==1659955==    by 0x401C13D: strdup (strdup.c:42)
==1659955==    by 0x4016D0A: _dl_load_cache_lookup (dl-cache.c:306)
==1659955==    by 0x4009592: _dl_map_object (dl-load.c:2107)
==1659955==    by 0x4013A7D: dl_open_worker (dl-open.c:217)
==1659955==    by 0x49F5D66: _dl_catch_exception (dl-error-skeleton.c:196)
==1659955==    by 0x401363D: _dl_open (dl-open.c:588)
==1659955==    by 0x49F5250: do_dlopen (dl-libc.c:96)
==1659955==    by 0x49F5D66: _dl_catch_exception (dl-error-skeleton.c:196)
==1659955==    by 0x49F5E02: _dl_catch_error (dl-error-skeleton.c:215)
==1659955==    by 0x49F5356: dlerror_run (dl-libc.c:46)
==1659955==    by 0x49F53E9: __libc_dlopen_mode (dl-libc.c:195)
==1659955==
==1659955== 21 bytes in 1 blocks are still reachable in loss record 2 of 4
==1659955==    at 0x483780B: malloc (vg_replace_malloc.c:309)
==1659955==    by 0x400BCEF: _dl_new_object (dl-object.c:163)
==1659955==    by 0x400649F: _dl_map_object_from_fd (dl-load.c:1002)
==1659955==    by 0x4009319: _dl_map_object (dl-load.c:2241)
==1659955==    by 0x4013A7D: dl_open_worker (dl-open.c:217)
==1659955==    by 0x49F5D66: _dl_catch_exception (dl-error-skeleton.c:196)
==1659955==    by 0x401363D: _dl_open (dl-open.c:588)
==1659955==    by 0x49F5250: do_dlopen (dl-libc.c:96)
==1659955==    by 0x49F5D66: _dl_catch_exception (dl-error-skeleton.c:196)
==1659955==    by 0x49F5E02: _dl_catch_error (dl-error-skeleton.c:215)
==1659955==    by 0x49F5356: dlerror_run (dl-libc.c:46)
==1659955==    by 0x49F53E9: __libc_dlopen_mode (dl-libc.c:195)
==1659955==
==1659955== 384 bytes in 1 blocks are still reachable in loss record 3 of 4
==1659955==    at 0x4839B1A: calloc (vg_replace_malloc.c:762)
==1659955==    by 0x401142F: _dl_check_map_versions (dl-version.c:274)
==1659955==    by 0x4013B25: dl_open_worker (dl-open.c:266)
==1659955==    by 0x49F5D66: _dl_catch_exception (dl-error-skeleton.c:196)
==1659955==    by 0x401363D: _dl_open (dl-open.c:588)
==1659955==    by 0x49F5250: do_dlopen (dl-libc.c:96)
==1659955==    by 0x49F5D66: _dl_catch_exception (dl-error-skeleton.c:196)
==1659955==    by 0x49F5E02: _dl_catch_error (dl-error-skeleton.c:215)
==1659955==    by 0x49F5356: dlerror_run (dl-libc.c:46)
==1659955==    by 0x49F53E9: __libc_dlopen_mode (dl-libc.c:195)
==1659955==    by 0x48AE45A: pthread_cancel_init (unwind-forcedunwind.c:53)
==1659955==    by 0x48AE673: _Unwind_ForcedUnwind (unwind-forcedunwind.c:127)
==1659955==
==1659955== 1,190 bytes in 1 blocks are still reachable in loss record 4 of 4
==1659955==    at 0x4839B1A: calloc (vg_replace_malloc.c:762)
==1659955==    by 0x400BA11: _dl_new_object (dl-object.c:73)
==1659955==    by 0x400649F: _dl_map_object_from_fd (dl-load.c:1002)
==1659955==    by 0x4009319: _dl_map_object (dl-load.c:2241)
==1659955==    by 0x4013A7D: dl_open_worker (dl-open.c:217)
==1659955==    by 0x49F5D66: _dl_catch_exception (dl-error-skeleton.c:196)
==1659955==    by 0x401363D: _dl_open (dl-open.c:588)
==1659955==    by 0x49F5250: do_dlopen (dl-libc.c:96)
==1659955==    by 0x49F5D66: _dl_catch_exception (dl-error-skeleton.c:196)
==1659955==    by 0x49F5E02: _dl_catch_error (dl-error-skeleton.c:215)
==1659955==    by 0x49F5356: dlerror_run (dl-libc.c:46)
==1659955==    by 0x49F53E9: __libc_dlopen_mode (dl-libc.c:195)
==1659955==
==1659955== LEAK SUMMARY:
==1659955==    definitely lost: 0 bytes in 0 blocks
==1659955==    indirectly lost: 0 bytes in 0 blocks
==1659955==      possibly lost: 0 bytes in 0 blocks
==1659955==    still reachable: 1,616 bytes in 4 blocks
==1659955==         suppressed: 0 bytes in 0 blocks
==1659955==
==1659955== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)

这是使用 -DDOEXIT=0 编译时的输出(是否 return (void *) 0;):

==1660133== Memcheck, a memory error detector
==1660133== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al.
==1660133== Using Valgrind-3.15.0 and LibVEX; rerun with -h for copyright info
==1660133== Command: ./fix0
==1660133==
==1660133==
==1660133== HEAP SUMMARY:
==1660133==     in use at exit: 0 bytes in 0 blocks
==1660133==   total heap usage: 8 allocs, 8 frees, 2,176 bytes allocated
==1660133==
==1660133== All heap blocks were freed -- no leaks are possible
==1660133==
==1660133== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)

关于c pthread 仍然可以访问，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/72610256/

文章推荐： c - 如何将 Zig String 文字传递给 C

文章推荐： c++ - 如何在删除操作中推导出多态对象的大小？

文章推荐： smalltalk:关于方法 - "withArgs:executeMethod:"

c++ - C c;之间有什么区别吗？和 C c = C();?
#include using namespace std; class C{ private: int value; public: C(){ value = 0;
c++ - C 风格字符串差异 : C/C++
这个问题已经有答案了: What is the difference between char a[] = ?string?; and char *p = ?string?;? (8 个回答) 已关闭
c++ - c\c++ 转换为 C#
关闭。此题需要details or clarity 。目前不接受答案。想要改进这个问题吗？通过 editing this post 添加详细信息并澄清问题. 已关闭 7 年前。此帖子已于 8 个月
c# - C、C++、C# 的功能测试工具
除了调试之外，是否有任何针对 c、c++ 或 c# 的测试工具，其工作原理类似于将独立函数复制粘贴到某个文本框，然后在其他文本框中输入参数？最佳答案也许您会考虑单元测试。我推荐你谷歌测试和谷歌模拟
c# - C/C++/C# 在监视器上设置窗口位置
我想在第二台显示器中移动一个窗口 (HWND)。问题是我尝试了很多方法，例如将分辨率加倍或输入负值，但它永远无法将窗口放在我的第二台显示器上。关于如何在 C/C++/c# 中执行此操作的任何线索最
c# - C/C++/C#中的DES实现
我正在寻找 C/C++/C## 中不同类型 DES 的现有实现。我的运行平台是Windows XP/Vista/7。我正在尝试编写一个 C# 程序，它将使用 DES 算法进行加密和解密。我需要一些实
c# - 在条件中使用赋值是否安全？ C/C++、C#
很难说出这里要问什么。这个问题模棱两可、含糊不清、不完整、过于宽泛或夸夸其谈，无法以目前的形式得到合理的回答。如需帮助澄清此问题以便重新打开，visit the help center . 关闭 1
c++ - C/C++/C# 强制窗口在最上面
有没有办法强制将另一个窗口置于顶部？不是应用程序的窗口，而是另一个已经在系统上运行的窗口。 (Windows, C/C++/C#) 最佳答案 SetWindowPos(that_window_ha
c# - 套接字服务器应用程序的选择 : C/C++ or C#
假设您可以在 C/C++ 或 Csharp 之间做出选择，并且您打算在 Windows 和 Linux 服务器上运行同一服务器的多个实例，那么构建套接字服务器应用程序的最明智选择是什么？最佳答案如
c++ - C/C++ 运行时库和 C/C++ 标准库的区别
你们能告诉我它们之间的区别吗？顺便问一下，有什么叫C++库或C库的吗？最佳答案 C++ 标准库和 C 标准库是 C++ 和 C 标准定义的库，提供给 C++ 和 C 程序使用。那是那些词的共同
c++ - &C::c 和 &(C::c) 有什么区别？
下面的测试代码，我将输出信息放在注释中。我使用的是 gcc 4.8.5 和 Centos 7.2。 #include #include class C { public:
c++ - 什么 C++(通用 (c/c++) 与 (通用 c)/c++ )
很难说出这里问的是什么。这个问题是含糊的、模糊的、不完整的、过于宽泛的或修辞性的，无法以目前的形式得到合理的回答。如需帮助澄清此问题以便重新打开它，visit the help center 。已关
c# - 通过网络在 C/C++ 服务器、C/C++ 和 C# 客户端之间发送数据结构
我的客户将使用名为 annoucement 的结构/类与客户通信。我想我会用 C++ 编写服务器。会有很多不同的类继承annoucement。我的问题是通过网络将这些类发送给客户端我想也许我应该使用
c# - C/C++ - 如何将 Buffer.BlockCopy (C#) 转换为 C/C++
我在 C# 中有以下函数: public Matrix ConcatDescriptors(IList> descriptors) { int cols = descriptors[0].Co
c++ - C/C++ - 对其他人隐藏 C 或 C++ 函数代码
我有一个项目要编写一个函数来对某些数据执行某些操作。我可以用 C/C++ 编写代码，但我不想与雇主共享该函数的代码。相反，我只想让他有权在他自己的代码中调用该函数。是否可以？我想到了这两种方法 - 在
c# - 在托管代码(C++、C、C++/CLI、C#)中使用非托管代码时处理错误
我使用的是编写糟糕的第 3 方 (C/C++) Api。我从托管代码(C++/CLI)中使用它。有时会出现“访问冲突错误”。这使整个应用程序崩溃。我知道我无法处理这些错误[如果指针访问非法内存位置等，
c# - C#、C/C++ 或 Objective-C 中的眼动追踪库
关闭。这个问题不符合Stack Overflow guidelines .它目前不接受答案。我们不允许提问寻求书籍、工具、软件库等的推荐。您可以编辑问题，以便用事实和引用来回答。关闭 7 年前。
c++ - C/C++/Objective-C 文本识别库
已关闭。此问题不符合Stack Overflow guidelines 。目前不接受答案。要求我们推荐或查找工具、库或最喜欢的场外资源的问题对于 Stack Overflow 来说是偏离主题的，因为
c# - 将 C/C++ 函数导入 C#
我有一些 C 代码，将使用 P/Invoke 从 C# 调用。我正在尝试为这个 C 函数定义一个 C# 等效项。 SomeData* DoSomething(); struct SomeData {
c - C语言中 "c -= --c - c++;"的结果应该是什么？
这个问题已经有答案了: Why are these constructs using pre and post-increment undefined behavior? (14 个回答) 已关闭 6

行者123

个人简介

我是一名优秀的程序员,十分优秀！

作者热门文章

滴滴打车优惠券免费领取

全站热门文章

首页

博学

6Ren·AI

商城

c pthread 仍然可以访问