在我的程序的一个步骤中，我需要对图像进行卷积。为此，我使用fftw3提供的功能。当我在我的程序上运行valgrind时，我得到了这个堆栈跟踪。我的函数名为convolve，它运行fftw3的{{1}}两次（一次在图像上，一次在卷积内核上。为了使其更具可读性，我删除了所有地址和进程ID。
fftw_plan_dft_r2c_2d根据手册的建议，完成后我使用了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位于FFTW源代码的深处。
编辑：包括fftw_cleanup（）
之后在我添加malloc之后，您可以看到diff。
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
个字节数明显减少，释放的still reachable个数也增加了。但主要错误（malloc）仍然存在。
答案 0 :(得分：2)
FFTW的规划器保存了一些其他持久性数据，例如累积的智慧和当前配置中可用的算法列表。如果你想要释放所有这些并将FFTW重置为原始状态，那么当你启动程序时，你可以调用：
void fftw_cleanup(void);
答案 1 :(得分：1)
我相信您可能在您自己的代码中出错，但我建议您进行测试以缩小问题范围。
我（随机）发现一些sample code一次调用fftw_plan_dft_r2c_2d()，以及FFTW库函数的其他部分。
在我的环境中：运行此测试的基于amd64的Debian 7.4＆＃34; wheezy＆＃34;，libfftw 3.3.2 + Debian补丁（3.3.2-3.1）和gcc 4.7.2（Debian 4.7.2-5）一旦你明确地将fftw_cleanup()添加到每个test0#函数的末尾或者在main（）的末尾，在返回之前，valgrind下的代码似乎有没有泄漏的内存
因此，当您多次调用fftw_plan_dft_r2c_2d()时，除非FFTW库有内存泄漏，否则我怀疑错误是在您自己的代码中。
如果您认为库中存在内存泄漏而不是使用它，请随意调整John Burkardt编写的示例代码并根据LGPL许可重复调用fftw_plan_dft_r2c_2d()。
答案 2 :(得分：1)
我发现只需调用* fftw_destroy_plan *也会从valgrind输出中删除丢失的块消息。
当然，调用* fftw_cleanup *会把所有事情都搞定。