检查fftw3与Valgrind的 [英] Checking fftw3 with valgrind

问题描述

在我的程序一步，我需要卷积的图像。要做到这一点，我利用 fftw3 提供的功能。当我在我的程序运行的valgrind 我得到这个堆栈跟踪。我的函数被调用卷积，它运行的 fftw3 fftw_plan_dft_r2c_2d 两次（一次在图像上，一旦上了卷积核，为了使其更具可读性，我删除了所有的地址和进程ID。

In one step of my program I need to convolve an image. To do that I am using the functions provided by fftw3. When I run valgrind on my program I get this stack trace. My function is called convolve and it runs fftw3's fftw_plan_dft_r2c_2d two times (once on the image, once on the convolution kernel. In order to make it more readable, I removed all addresses and process IDs.

HEAP SUMMARY:
    in use at exit: 62,280 bytes in 683 blocks
  total heap usage: 178,271 allocs, 177,588 frees, 36,617,058 bytes allocated

3,304 (24 direct, 3,280 indirect) bytes in 1 blocks are definitely lost in loss record 129 of 131
   at : malloc (vg_replace_malloc.c:291)
   by : fftw_malloc_plain (in ./prog)
   by : fftw_mkapiplan (in ./prog)
   by : fftw_plan_many_dft_r2c (in ./prog)
   by : fftw_plan_dft_r2c (in ./prog)
   by : fftw_plan_dft_r2c_2d (in ./prog)
   by : convolve (freqdomain.c:199)
   by : convolve (conv.c:290)
   by : main (main.c:332)

3,304 (24 direct, 3,280 indirect) bytes in 1 blocks are definitely lost in loss record 130 of 131
   at : malloc (vg_replace_malloc.c:291)
   by : fftw_malloc_plain (in ./prog)
   by : fftw_mkapiplan (in ./prog)
   by : fftw_plan_many_dft_r2c (in ./prog)
   by : fftw_plan_dft_r2c (in ./prog)
   by : fftw_plan_dft_r2c_2d (in ./prog)
   by : convolve (freqdomain.c:203)
   by : convolve (conv.c:290)
   by : main (main.c:332)

LEAK SUMMARY:
   definitely lost: 48 bytes in 2 blocks
   indirectly lost: 6,560 bytes in 60 blocks
     possibly lost: 0 bytes in 0 blocks
   still reachable: 55,672 bytes in 621 blocks
        suppressed: 0 bytes in 0 blocks
Reachable blocks (those to which a pointer was found) are not shown.
To see them, rerun with: --leak-check=full --show-leak-kinds=all

For counts of detected and suppressed errors, rerun with: -v
ERROR SUMMARY: 3 errors from 3 contexts (suppressed: 4 from 4)

诚如由人工，我用后整理 fftw_free 和 fftw_destroy_plan 。我想看看这是有什么我可以用这个做的还是这与 fftw3 的内部问题？由于没有释放的malloc 定位在FFTW源$ C ​​$ CS深。

As advised by the manual, after finishing I have used fftw_free and fftw_destroy_plan. I wanted to see that is there anything I can do with this or is this an internal issue with fftw3? Since the not freed malloc is positioned deep in the FFTW source codes.

编辑：包括fftw_cleanup（）后

下面你可以看到差异我加入后 fftw_cleanup（）。

Below you can see the diff after I added fftw_cleanup().

[me@mycomputer]$ diff NoCleanup WithCleanup 
2,3c2,3
<     in use at exit: 62,280 bytes in 683 blocks
<   total heap usage: 178,271 allocs, 177,588 frees, 36,617,058 bytes allocated
---
>     in use at exit: 9,008 bytes in 66 blocks
>   total heap usage: 178,271 allocs, 178,205 frees, 36,617,058 bytes allocated
5c5
< 3,304 (24 direct, 3,280 indirect) bytes in 1 blocks are definitely lost in loss record 129 of 131
---
> 3,304 (24 direct, 3,280 indirect) bytes in 1 blocks are definitely lost in loss record 39 of 40
16c16
< 3,304 (24 direct, 3,280 indirect) bytes in 1 blocks are definitely lost in loss record 130 of 131
---
> 3,304 (24 direct, 3,280 indirect) bytes in 1 blocks are definitely lost in loss record 40 of 40
31c31
<    still reachable: 55,672 bytes in 621 blocks
---
>    still reachable: 2,400 bytes in 4 blocks

中的退出，使用仍可达字节数已显著下降，释放的malloc还数取值有所增加。但主要的错误（ 3,304（24直接，间接3,280）的1块肯定是丢失的字节）仍然存在。

The number of still reachable bytes in use at exit has significantly decreased, also the number of freed mallocs has increased. But the main error (3,304 (24 direct, 3,280 indirect) bytes in 1 blocks are definitely lost) still remains.

推荐答案

我相信你的可能的有自己的code错误，但我认为一个测试，以缩小问题的范围

I believe you may have an error in your own code, but I do suggest a test to narrow down the issue.

我（随机）发现了一些样品code 调用 fftw_plan_dft_r2c_2d（）一次，FFTW库功能，以及其他部分。

I (randomly) found some sample code that calls fftw_plan_dft_r2c_2d() once, as well as other parts of FFTW library functions.

在我的环境：AMD64基于Debian 7.4喘息，libfftw 3.3.2 + Debian的补丁（3.3.2-3.1）和gcc 4.7.2（Debian的4.7.2-5）运行此测试$ C $在c Valgrind的似乎有否泄漏的内存，一旦你明确添加 fftw_cleanup（）到每个要么结束 TEST0＃函数或一次，返回之前。

In my environment: amd64 based Debian 7.4 "wheezy", libfftw 3.3.2 + Debian patches (3.3.2-3.1) and gcc 4.7.2 (Debian 4.7.2-5) running this test code under valgrind appears to have no leaked memory once you explicitly add fftw_cleanup() to either the end of each test0# function or once at the end of main(), before the return.

所以，除非FFTW库有当你调用 fftw_plan_dft_r2c_2d（）多次内存泄漏，我怀疑的错误是在你自己的code。

So unless the FFTW library has a memory leak when you call fftw_plan_dft_r2c_2d() multiple times, I suspect the error is in your own code.

随意调整下LGPL约翰Burkardt书面和许可的样本code重复调用 fftw_plan_dft_r2c_2d（）如果你相信有内存泄漏库而不是你的就用法。

Feel free to adapt the sample code written by John Burkardt and licensed under LGPL to repeatedly call fftw_plan_dft_r2c_2d() if you believe there is a memory leak in the library rather than your usage of it.

这篇关于检查fftw3与Valgrind的的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！