这个valgrind输出是否意味着存在内存泄漏? (重命名的问题)

时间:2010-06-07 09:10:48

标签: c linux valgrind

(原标题:可能的内存泄漏问题)

我写下两个c程序如下,在使用Valgrind的memcheck过程中,给出了很多内存泄漏信息。

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)

1 个答案:

答案 0 :(得分:2)

从标记为“肯定丢失”的两条记录开始,因为那些当然内存泄漏:

==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)

这表明calloc()me_search.c的第1315行分配的内存已泄露。 get_mem2D()me_search.c的第1393行调用了get_mem3D()时发生了这种情况,后者又被GetMemory()中的第109行调用,main()中的第149行调用{{1}} 1}}。

这些行号应该足以开始计算为什么泄露了。