утечка памяти в dgemm_

Question

В настоящее время я работаю над приложением, которое включает в себя множество и много вызовов процедур blas. Регулярно проверяя утечки памяти, я обнаружил, что я теряю байты в вызове dgemm. Вызов выглядит следующим образом:

// 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. Выходной сигнал:

==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_ может вызвать утечку.

Answer 1

Посмотрите на трассировку стека, утечку (если она действительно является утечкой, valgrind может генерировать ложные срабатывания) не находится в самом BLAS-вызове, она находится в библиотеке пользовательского пространства OS X Grand Central Dispatch, которую использует система ускорения для нескольких -подтверждение поддержки в этих вызовах BLAS. На самом деле вы ничего не можете с этим поделать. Если утечка влияет на производительность или стабильность вашего приложения, сообщите об этом как об ошибке Apple.