dgemm_中的内存泄漏 [英] memory leak in dgemm_
问题描述
我目前正在开发一个涉及对blas例程的大量调用的应用程序.例行检查我发现的内存泄漏，发现我在 dgemm 调用中丢失了字节.呼叫看起来像这样:
I am currently working on an application which involves lots and lots of calls to blas routines. Routinely checking for memory leaks I discovered, that I am loosing bytes in a dgemm call. The call looks like this:
// I want to multiply 2 nxn matrices and put the result into C - an nxn matrix
double zero = 0.0;
double one = 1.0;
double n; // matrix dimension
char N = 'N';
dgemm_(&N, &N, &n, &n, &n, &one, A, &n, B, &n, &zero, C, &n);
A，B和C是大小为n * n的双字段. valgrind输出为:
A,B and C are double fields of size n*n. The valgrind output is:
==78182== 18 bytes in 1 blocks are definitely lost in loss record 2 of 30
==78182== at 0xB936: malloc_zone_malloc (vg_replace_malloc.c:267)
==78182== by 0xF0B8C6: malloc_set_zone_name (in /usr/lib/system/libsystem_c.dylib)
==78182== by 0xF0BDF2: _malloc_initialize (in /usr/lib/system/libsystem_c.dylib)
==78182== by 0xF0C201: malloc_create_zone (in /usr/lib/system/libsystem_c.dylib)
==78182== by 0xE0533B: _dispatch_ccache_init (in /usr/lib/system/libdispatch.dylib)
==78182== by 0xE08223: dispatch_once_f (in /usr/lib/system/libdispatch.dylib)
==78182== by 0xE05305: _dispatch_continuation_alloc_from_heap (in /usr/lib/system/libdispatch.dylib)
==78182== by 0xE072C8: dispatch_group_async_f (in /usr/lib/system/libdispatch.dylib)
==78182== by 0x96465F: dgemmGCD (in /System/Library/Frameworks/Accelerate.framework/Versions/A/Frameworks/vecLib.framework/Versions/A/libBLAS.dylib)
==78182== by 0x4F1A47: cblas_dgemm (in /System/Library/Frameworks/Accelerate.framework/Versions/A/Frameworks/vecLib.framework/Versions/A/libBLAS.dylib)
==78182== by 0x4B8914: DGEMM (in /System/Library/Frameworks/Accelerate.framework/Versions/A/Frameworks/vecLib.framework/Versions/A/libBLAS.dylib)
==78182== by 0x100035587: nrg::NRGFD::buildDM() (NRGFD.cpp:1785)
==78182==
==78182== 22 bytes in 1 blocks are definitely lost in loss record 3 of 30
==78182== at 0xB936: malloc_zone_malloc (vg_replace_malloc.c:267)
==78182== by 0xF0B8C6: malloc_set_zone_name (in /usr/lib/system/libsystem_c.dylib)
==78182== by 0xE08223: dispatch_once_f (in /usr/lib/system/libdispatch.dylib)
==78182== by 0xE05305: _dispatch_continuation_alloc_from_heap (in /usr/lib/system/libdispatch.dylib)
==78182== by 0xE072C8: dispatch_group_async_f (in /usr/lib/system/libdispatch.dylib)
==78182== by 0x96465F: dgemmGCD (in /System/Library/Frameworks/Accelerate.framework/Versions/A/Frameworks/vecLib.framework/Versions/A/libBLAS.dylib)
==78182== by 0x4F1A47: cblas_dgemm (in /System/Library/Frameworks/Accelerate.framework/Versions/A/Frameworks/vecLib.framework/Versions/A/libBLAS.dylib)
==78182== by 0x4B8914: DGEMM (in /System/Library/Frameworks/Accelerate.framework/Versions/A/Frameworks/vecLib.framework/Versions/A/libBLAS.dylib)
==78182== by 0x100035587: nrg::NRGFD::buildDM() (NRGFD.cpp:1785)
==78182== by 0x10003C5E6: nrg::NRGFD::solve() (NRGFD.cpp:147)
==78182== by 0x10001AC83: main (main.cpp:63)
我检查了矩阵的尺寸.他们是预期的.我不知道dgemm_调用如何造成这种泄漏.我可以理解非法的读写.但是我不明白dgemm_怎么会引起泄漏.
I checked the dimensions of the matrizes. They are as expected. I don't get how a dgemm_ call could create such a leak. I could understand illegal writes or reads. But I don't understand how dgemm_ could cause a leak.
推荐答案
查看堆栈跟踪信息，泄漏(如果确实是泄漏，则valgrind会生成误报)不在BLAS调用本身中，而是在 OS X Grand Central Dispatch 在这些BLAS调用中Accelerate框架用于多线程支持的用户空间库.实际上，您对此无能为力.如果泄漏影响了应用程序的性能或稳定性，请将其作为错误报告给Apple.
Looking at the stack trace, the leak (if it really is a leak, valgrind can generate false positives) isn't in the BLAS call itself, it is in the OS X Grand Central Dispatch userspace library which the Accelerate framework is using for multi-threading support in those BLAS calls. There isn't really anything you can do about it. If the leak effects the performance or stability of your application, then report it as a bug to Apple.
这篇关于dgemm_中的内存泄漏的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
