3

私は現在、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のダブルフィールドです。valgrindの出力は次のとおりです。

==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_がどのようにリークを引き起こす可能性があるのか​​わかりません。

4

1 に答える 1

3

スタック トレースを見ると、リーク (実際にリークである場合、valgrind が誤検知を生成する可能性があります) は BLAS 呼び出し自体ではなく、Accelerate フレームワークがマルチに使用しているOS X Grand Central Dispatchユーザー空間ライブラリにあります。 -これらの BLAS 呼び出しでのスレッドのサポート。それについてあなたができることは本当に何もありません。リークがアプリケーションのパフォーマンスや安定性に影響する場合は、Apple にバグとして報告してください。

于 2012-01-06T01:21:16.910 に答える