问题描述
我正在使用 NVIDIA 硬件在 Ubuntu 12.04 上测试我的代码.
I'm testing my code on Ubuntu 12.04 with NVIDIA hardware.
没有实际的 OpenCL 处理发生；但我的初始化代码仍在运行.此代码调用 clGetPlatformIDs.但是，Valgrind 报告内存泄漏:
No actual OpenCL processing takes place; but my initialization code is still running. This code calls clGetPlatformIDs. However, Valgrind is reporting a memory leak:
==2718== 8 bytes in 1 blocks are definitely lost in loss record 4 of 74
==2718== at 0x4C2B6CD: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==2718== by 0x509ECB6: ??? (in /usr/lib/nvidia-current/libOpenCL.so.1.0.0)
==2718== by 0x50A04E1: ??? (in /usr/lib/nvidia-current/libOpenCL.so.1.0.0)
==2718== by 0x509FE9F: clGetPlatformIDs (in /usr/lib/nvidia-current/libOpenCL.so.1.0.0)
我不知道这甚至是可能的.这可以解决吗?请注意，当前没有进行特殊的取消初始化——在此之后我需要调用什么吗?docs 没有提及任何内容关于必须取消分配任何东西.
I was unaware this was even possible. Can this be fixed? Note that no special deinitialization is currently taking place--do I need to call something after this? The docs don't mention anything about having to deallocate anything.
推荐答案
关于:请查看:devgurus.amd.com/thread/136242.valgrind 无法通过设计处理自定义内存分配器，而 OpenCL 可能正在使用它"
regarding: "Check this out: devgurus.amd.com/thread/136242. valgrind cannot deal with custom memory allocators by design, which OpenCL is likely using"
引用给出的链接:在出口处不释放池的行为可能被称为库的错误."
to quote from the link given: "The behaviour not to free pools at the exit could be called a bug of the library though."
如果您想创建一个内存池并从中分配，请继续；但你仍然应该正确地释放它.整个内存池的复杂性不亚于常规内存引用的复杂性，并且至少应该受到同样的关注，如果不是更多，则是常规引用的关注.此外，8 字节结构极不可能是内存池.
If you want to create a pool of memory and allocate from that, go ahead; but you still should properly deallocate it. The complexity of a memory pool as a whole is no less complex then the complexity of a regular memory reference and deserves at least the same attention, if not more, then that of regular references. Also, an 8 byte structure is highly unlikely to be a memory pool.
如果 clGetPlatformIds 旨在返回分配的内存，Tim Child 会对您如何使用它有一个观点.但是，阅读 http://www.khronos.org/registry/cl/sdk/1.0/docs/man/xhtml/clGetPlatformIDs.html 我不太相信应该是这种情况.
Tim Child would have a point about how you use clGetPlatformIds if it was designed to return allocated memory. However, reading http://www.khronos.org/registry/cl/sdk/1.0/docs/man/xhtml/clGetPlatformIDs.html I am not sufficiently convinced this should be the case.
有问题的泄漏可能严重也可能不严重，可能会或可能不会通过连续调用累积，但您可能只能选择将错误报告给 nvidia，希望他们修复它或找到不同的 opencl 实现为发展.尽管如此，从 valgrind 的角度来看，opencl 库可能有理由创建对未使用的数据的引用.
The leak in question may or may not be serious, may or may not accumulate by successive calls, but you might be left only with the option to report the bug to nvidia in hopes they fix it or to find a different opencl implementation for development. Still, there might be reasons for an opencl library to create references to data which from the viewpoint of valgrind are not in use.
遗憾的是，这仍然给我们留下了由我们无法控制的外部因素引起的内存泄漏，并且仍然给我们留下了过多的 valgrind 输出.
Sadly, this still leaves us with a memory leak caused by an external factor we cannot control, and it still leaves us with excess valgrind output.
假设您非常确定您不对这次泄漏负责(例如，我们知道一个事实，即 nvidia 工程师在 OpenCL.so 中分配了一个随机值，他并没有解除分配只是为了冒犯您).Valgrind 有一个标志 --gen-suppressions=yes，您可以使用它来抑制有关特定警告的警告，您可以使用 --suppressions=$filename 将这些警告反馈给 valgrind.阅读 valgrind 页面，了解有关其工作原理的更多详细信息.
Say you are sufficiently sure you are not responsible for this leak (say, we know for a fact that an nvidia engineer allocated a random value in OpenCL.so which he didn't deallocate just to spite you). Valgrind has a flag --gen-suppressions=yes, with which you can suppress warnings about particular warnings, which you can feed back to valgrind using --suppressions=$filename. Read the valgrind page for more details about how it works.
不过要非常小心使用抑制.显然，抑制错误并不能修复它们，自由使用该机制会导致您抑制代码所产生的错误，而不是 nvidia 或 valgrind.不要压制您不确定它们来自哪里的警告，或定期重申您的压制.
Be very wary of using suppressions though. Obviously suppressing errors does not fix them, and liberal usage of the mechanism will lead to situations where you suppress errors made by your code, rather then nvidia or valgrind. Do not suppress warnings of which you are not absolutely sure of where they come from, or regularly reassert your suppressions.
这篇关于clGetPlatformIDs 内存泄漏的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持！