Question

我一直在使用libcurl来处理获取/发布请求，并且valgrind总是向我显示相同数量的可访问块（21）。我在标准cURL的配置中缺少什么来避免这种情况？

这是带有“错误”的最简单的代码：

#include <stdio.h>
#include <stdlib.h>
#include <curl/curl.h>

int main(int argc, char const *argv[]) {

  CURL *curl;

  curl_global_init(CURL_GLOBAL_ALL);
  curl = curl_easy_init();
  ·
  ·
  ·
  curl_easy_cleanup(curl);
  curl_global_cleanup();

  return 0;

}

我用

进行编译

$ gcc -o test cURL.c -lcurl

Valgrind检查

$ valgrind --leak-check=full --track-origins=yes ./test

==4295== Memcheck, a memory error detector
==4295== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al.
==4295== Using Valgrind-3.13.0 and LibVEX; rerun with -h for copyright info
==4295== Command: ./test
==4295== 
==4295== 
==4295== HEAP SUMMARY:
==4295==     in use at exit: 858 bytes in 21 blocks
==4295==   total heap usage: 4,265 allocs, 4,244 frees, 185,353 bytes allocated
==4295== 
==4295== LEAK SUMMARY:
==4295==    definitely lost: 0 bytes in 0 blocks
==4295==    indirectly lost: 0 bytes in 0 blocks
==4295==      possibly lost: 0 bytes in 0 blocks
==4295==    still reachable: 858 bytes in 21 blocks
==4295==         suppressed: 0 bytes in 0 blocks
==4295== Reachable blocks (those to which a pointer was found) are not shown.
==4295== To see them, rerun with: --leak-check=full --show-leak-kinds=all
==4295== 
==4295== For counts of detected and suppressed errors, rerun with: -v
==4295== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)

Answer 1

libcurl链接了许多库，其中一些库没有像curl_global_cleanup这样的函数，该函数还原初始化并释放所有内存。当libcurl与NSS链接以获得TLS支持以及libssh2及其对libgcrypt的使用时，就会发生这种情况。在这方面，将GNUTLS作为TLS的实现更为简洁。

通常，这不是问题，因为这些辅助库仅用于在进程终止时释放内存的操作系统，因此不需要显式清理（甚至会减慢进程终止）。仅对于某些内存调试器，清除清理例程的效果是可见的，并且valgrind通过区分实际的泄漏（没有指针的内存）和在进程终止时仍可访问的内存来处理这种情况（因此可以如果进程尚未终止，请再次使用。

为什么libcurl在清除调用之后仍然留下可访问的块？

1 个答案: