C 此valgrind输出是否意味着内存泄漏？（改名为问题） （原标题：可能的内存泄漏问题）

我编写了两个c程序，如下所示，在使用Valgrind的memcheck过程中，给出了大量的mem泄漏信息

int
GetMemory(int framewidth,
          int frameheight,
          int SR/*, int blocksize*//*,int ALL_REF_NUM*/)
{
    //int i,j;
    int memory_size = 0;
    //int refnum = ALL_REF_NUM;
    int input_search_range = SR;

    memory_size += get_mem2D(&curFrameY, frameheight, framewidth);
    memory_size += get_mem2D(&curFrameU, frameheight>>1, framewidth>>1);
    memory_size += get_mem2D(&curFrameV, frameheight>>1, framewidth>>1);

    memory_size += get_mem3D(&prevFrameY, refnum, frameheight, framewidth);// to allocate reference frame buffer accoding to the reference frame number 
    memory_size += get_mem3D(&prevFrameU, refnum, frameheight>>1, framewidth>>1);
    memory_size += get_mem3D(&prevFrameV, refnum, frameheight>>1, framewidth>>1);

    memory_size += get_mem2D(&mpFrameY, frameheight, framewidth);
    memory_size += get_mem2D(&mpFrameU, frameheight>>1, framewidth>>1);
    memory_size += get_mem2D(&mpFrameV, frameheight>>1, framewidth>>1);

    memory_size += get_mem2D(&searchwindow, input_search_range*2 + blocksize, input_search_range*2 + blocksize);// to allocate search window according to the searchrange

    /*memory_size +=*/ get_mem1D(/*&SAD_cost, height, width*/);
    // memory_size += get_mem2D(&searchwindow, 80, 80);// if searchrange is 32, then only 32+1+32+15 pixels is needed in each row and col, therefore the range of 
    // search window is enough to be set to 80 !

    memory_size += get_mem2Dint(&all_mv, height/blocksize, width/blocksize);

    return 0;

}


void
FreeMemory(int refno)
{
    free_mem2D(curFrameY);
    free_mem2D(curFrameU);
    free_mem2D(curFrameV);

    free_mem3D(prevFrameY,refno);
    free_mem3D(prevFrameU,refno);
    free_mem3D(prevFrameV,refno);

    free_mem2D(mpFrameY);
    free_mem2D(mpFrameU);
    free_mem2D(mpFrameV);

    free_mem2D(searchwindow);
    free_mem1D();
    free_mem2Dint(all_mv);
}

void free_mem1D()
{
    free(SAD_cost);
}

现在我希望确定我的计划中可能存在的问题在哪里？ 在这里，我可能会发布一些valgrind信息，让您了解实际的错误信息

==29105==    by 0x804A906: main (me_search.c:1480)
==29105== 
==29105== 
==29105== HEAP SUMMARY:
==29105==     in use at exit: 124,088 bytes in 18 blocks
==29105==   total heap usage: 37 allocs, 21 frees, 749,276 bytes allocated
==29105== 
==29105== 272 bytes in 1 blocks are still reachable in loss record 1 of 18
==29105==    at 0x402425F: calloc (vg_replace_malloc.c:467)
==29105==    by 0x804A296: get_mem2D (me_search.c:1315)
==29105==    by 0x804885E: GetMemory (me_search.c:117)
==29105==    by 0x804A757: main (me_search.c:1456)
==29105== 
==29105== 352 bytes in 1 blocks are still reachable in loss record 2 of 18
==29105==    at 0x4024F20: malloc (vg_replace_malloc.c:236)
==29105==    by 0x409537E: __fopen_internal (iofopen.c:76)
==29105==    by 0x409544B: fopen@@GLIBC_2.1 (iofopen.c:107)
==29105==    by 0x804A660: main (me_search.c:1439)
==29105== 
==29105== 584 bytes in 1 blocks are still reachable in loss record 3 of 18
==29105==    at 0x402425F: calloc (vg_replace_malloc.c:467)
==29105==    by 0x804A296: get_mem2D (me_search.c:1315)
==29105==    by 0x8048724: GetMemory (me_search.c:106)
==29105==    by 0x804A757: main (me_search.c:1456)
==29105== 
==29105== 584 bytes in 1 blocks are still reachable in loss record 4 of 18
==29105==    at 0x402425F: calloc (vg_replace_malloc.c:467)
==29105==    by 0x804A296: get_mem2D (me_search.c:1315)
==29105==    by 0x8048747: GetMemory (me_search.c:107)
==29105==    by 0x804A757: main (me_search.c:1456)
==29105== 
==29105== 584 bytes in 1 blocks are still reachable in loss record 5 of 18
==29105==    at 0x402425F: calloc (vg_replace_malloc.c:467)
==29105==    by 0x804A296: get_mem2D (me_search.c:1315)
==29105==    by 0x8048809: GetMemory (me_search.c:114)
==29105==    by 0x804A757: main (me_search.c:1456)
==29105== 
==29105== 584 bytes in 1 blocks are still reachable in loss record 6 of 18
==29105==    at 0x402425F: calloc (vg_replace_malloc.c:467)
==29105==    by 0x804A296: get_mem2D (me_search.c:1315)
==29105==    by 0x804882C: GetMemory (me_search.c:115)
==29105==    by 0x804A757: main (me_search.c:1456)
==29105== 
==29105== 584 bytes in 1 blocks are definitely lost in loss record 7 of 18
==29105==    at 0x402425F: calloc (vg_replace_malloc.c:467)
==29105==    by 0x804A296: get_mem2D (me_search.c:1315)
==29105==    by 0x804A4F8: get_mem3D (me_search.c:1393)
==29105==    by 0x804879B: GetMemory (me_search.c:110)
==29105==    by 0x804A757: main (me_search.c:1456)
==29105== 
==29105== 584 bytes in 1 blocks are definitely lost in loss record 8 of 18
==29105==    at 0x402425F: calloc (vg_replace_malloc.c:467)
==29105==    by 0x804A296: get_mem2D (me_search.c:1315)
==29105==    by 0x804A4F8: get_mem3D (me_search.c:1393)
==29105==    by 0x80487C9: GetMemory (me_search.c:111)
==29105==    by 0x804A757: main (me_search.c:1456)
==29105== 
==29105== 1,168 bytes in 1 blocks are still reachable in loss record 9 of 18
==29105==    at 0x402425F: calloc (vg_replace_malloc.c:467)
==29105==    by 0x804A296: get_mem2D (me_search.c:1315)
==29105==    by 0x8048701: GetMemory (me_search.c:105)
==29105==    by 0x804A757: main (me_search.c:1456)
==29105== 
==29105== 1,168 bytes in 1 blocks are still reachable in loss record 10 of 18
==29105==    at 0x402425F: calloc (vg_replace_malloc.c:467)
==29105==    by 0x804A296: get_mem2D (me_search.c:1315)
==29105==    by 0x80487E6: GetMemory (me_search.c:113)
==29105==    by 0x804A757: main (me_search.c:1456)
==29105== 
==29105== 1,168 bytes in 1 blocks are definitely lost in loss record 11 of 18
==29105==    at 0x402425F: calloc (vg_replace_malloc.c:467)
==29105==    by 0x804A296: get_mem2D (me_search.c:1315)
==29105==    by 0x804A4F8: get_mem3D (me_search.c:1393)
==29105==    by 0x804876D: GetMemory (me_search.c:109)
==29105==    by 0x804A757: main (me_search.c:1456)
==29105== 
==29105== 6,336 bytes in 1 blocks are definitely lost in loss record 12 of 18
==29105==    at 0x4024F20: malloc (vg_replace_malloc.c:236)
==29105==    by 0x804A25C: get_mem1D (me_search.c:1295)
==29105==    by 0x8048866: GetMemory (me_search.c:119)
==29105==    by 0x804A757: main (me_search.c:1456)

---

从标记为“肯定丢失”的两条记录开始，因为它们肯定是内存泄漏：

==29105== 1,168 bytes in 1 blocks are definitely lost in loss record 11 of 18
==29105== at 0x402425F: calloc (vg_replace_malloc.c:467)
==29105== by 0x804A296: get_mem2D (me_search.c:1315)
==29105== by 0x804A4F8: get_mem3D (me_search.c:1393)
==29105== by 0x804876D: GetMemory (me_search.c:109)
==29105== by 0x804A757: main (me_search.c:1456)

这表明

me\u search.c

第1315行的

calloc（）

分配的内存泄漏。这发生在

get\u mem2D（）

中的

me\u search.c

的第1393行调用

get\u mem2D（）

时，而

GetMemory（）

中的第109行又调用了

main（）

中的第1456行

---

这些行号应该足以找出它泄漏的原因。

是什么让你认为内存泄漏？你想找什么？你想完成什么？这个代码应该做什么？请添加更多信息以帮助那些试图帮助你的人。因为我发现我无法在linux环境下在firefox浏览器中编辑帖子。因此，我先通过程序，然后到另一台电脑编辑这篇文章。很抱歉给您带来不便。您是否已验证FreeMemory是否正在调整？您的确切意思是什么？我是一名新的c程序员，因此，我可能会犯一些幼稚的错误。如果您在控制台中运行它，您应该在FreeMemory中添加一些

printf

语句，以便确保它被调用。