简体   繁体   English

valgrind在使用libcurl时检测到内存泄漏(没有ssl)

[英]valgrind detects memory leaks when using libcurl (no ssl)

In my C program I use some basic functions of libcurl. 在我的C程序中,我使用了libcurl的一些基本功能。 Today I ran valgrind in order to check if I have memory leaks and valgrind went crazy reporting multiple errors. 今天我跑了valgrind,以检查我是否有内存泄漏,valgrind疯狂报告多个错误。

I tracked it basically down to: 我跟踪它基本上是:

CURL *curl;
CURLcode res;

curl = curl_easy_init();
// ...
curl_easy_cleanup(curl);

If I remove the code that uses libcurl completely, valgrind doesnt report any errors. 如果我完全删除使用libcurl的代码,valgrind不会报告任何错误。

I already read that there are some problems using valgrind with libcurl and ssl, but I dont fetch any https urls or the like. 我已经读过使用valgrind与libcurl和ssl有一些问题,但是我不提取任何https网址等。

What can I do? 我能做什么? Can I make valgrind shut up about libcurl errors (possible false positives?) and report only errors from my code? 我可以让valgrind关闭libcurl错误(可能是误报吗?)并仅报告我的代码中的错误? Due to the huge amount of errors despite most simple usage of libcurl the output of valgrind is quite confusing. 尽管libcurl的使用最简单,但由于存在大量错误,因此valgrind的输出非常混乱。

Unfortunately I dont have a debug built of libcurl installed, so valgrind doesnt even report the line numbers/files where it deteced the leaks. 不幸的是我没有安装libcurl构建的调试,所以valgrind甚至不报告它检测到泄漏的行号/文件。 The error messages look like: 错误消息如下所示:

==27330== 
==27330== HEAP SUMMARY:
==27330==     in use at exit: 34,960 bytes in 2,406 blocks
==27330==   total heap usage: 20,130 allocs, 17,724 frees, 2,511,576 bytes allocated
==27330== 
==27330== 40 (20 direct, 20 indirect) bytes in 1 blocks are definitely lost in loss record 383 of 445
==27330==    at 0x4025BD3: malloc (vg_replace_malloc.c:236)
==27330==    by 0x4B173FD: ???
==27330==    by 0x4B17A8B: ???
==27330==    by 0x4B84957: ???
==27330==    by 0x4B849FD: ???
==27330==    by 0x4B72814: ???
==27330==    by 0x4B734C1: ???
==27330==    by 0x4B78DE2: ???
==27330==    by 0x4B7524B: ???
==27330==    by 0x49B2F76: ???
==27330==    by 0x49C9ECB: ???
==27330==    by 0x49BC96A: ???
...

I know this answer is coming a year later, but someone may still find it helpful. 我知道这个答案将在一年后出现,但有人可能仍然觉得它很有帮助。
After the call to curl_easy_cleanup(curl) , try adding a call to curl_global_cleanup() . 在调用curl_easy_cleanup(curl) ,尝试添加对curl_global_cleanup()的调用。

That worked for me. 这对我有用。

If you're starting with the first libcurl example (simple.c), they don't call curl_global_init(long flags) and curl_global_cleanup() at the end, and valgrind will report potential issues. 如果您从第一个libcurl示例(simple.c)开始,它们最后不会调用curl_global_init(long flags)curl_global_cleanup() ,而valgrind将报告潜在的问题。 As stated in the libcurl docs, you MUST call BOTH curl_global_init and curl_global_cleanup . 正如libcurl文档中所述,你必须调用curl_global_initcurl_global_cleanup I verified myself that this solves the problem; 我证实了自己解决了这个问题; valgrind will report that all heap blocks were freed. valgrind将报告所有堆块都被释放。

libcurl doesn't leak but it might use techniques that will alarm valgrind. libcurl不泄漏但它可能会使用会警告valgrind的技术。 So, to repeat from other answers, what are the errors that valgrind reports? 那么,从其他答案重复一遍,valgrind报告的错误是什么?

I don't expect you have the libcurl sources but, if you do, where do the valgrind errors point you? 我不希望你有libcurl源,但是,如果你这样做,valgrind错误指向哪里?

What errors do you actually get? 你真正得到了什么错误?

And just as importantly - are the leaks a static amount, or do they grow over time? 同样重要的是 - 泄漏是静态的,还是随着时间的推移而增长? A small one-time static leak is far less important than something that is leaking as time goes on. 随着时间的推移,小的一次性静态泄漏远不如泄漏的东西重要。

It is also possible this is a false positive from Valgrind; 这也可能是Valgrind的误报; depends on the specific errors and where you see them. 取决于具体的错误以及您看到的位置。

Most likely valgrind is just getting things wrong concerning libcurl . 很可能valgrind只是在解决libcurl Often for such libraries it doesn't see one end of the allocation/deallocation correctly and gets confused. 通常对于这样的库,它没有正确地看到分配/解除分配的一端并且混淆。 A good OS distribution should provide you with "suppression" files for this, but obviously yours didn't do that. 一个好的操作系统发行版应该为你提供“抑制”文件,但很明显你的文件并没有这样做。 You can deal with that yourself with the options --suppressions and --gen-suppressions or even put such things in a config file. 您可以使用选项--suppressions--gen-suppressions来处理这些问题,甚至可以将这些内容放在配置文件中。

I asked on the mailing list and nobody could exactly tell me where my problem is, as I am still sture that I installed the debug version of the newest libcurl release, but still I couldnt see any debug symbols. 我在邮件列表上询问,没有人可以确切地告诉我我的问题在哪里,因为我仍然确定我安装了最新的libcurl版本的调试版本,但我仍然看不到任何调试符号。

Anyhow, I set up a new virtual machine and compiled libcurl from source and the strange error messages disappeared. 无论如何,我设置了一个新的虚拟机,并从源代码编译了libcurl,奇怪的错误信息消失了。

A shame that I didnt find anything more useful though which might have helped others with the same problem… 遗憾的是,我没有找到任何更有用的东西,虽然这可能帮助其他人解决同样的问题......

声明:本站的技术帖子网页,遵循CC BY-SA 4.0协议,如果您需要转载,请注明本站网址或者原文地址。任何问题请咨询:yoyou2525@163.com.

 
粤ICP备18138465号  © 2020-2024 STACKOOM.COM