Search Results

Search found 2 results on 1 pages for 'maitiano'.

Page 1/1 | 1 

  • Possible memory leak problem

    - by MaiTiano
    I write two pieces of c programs like following, during memcheck process using Valgrind, a lot of mem leak information is given. 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); } Now I hope to make sure where are the possible problems in my program? Here I may post some valgrind information to let you know about the actual error information. ==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)

    Read the article

  • A error about "Address 0x0 is not stack'd, malloc'd or (recently) free'd" in c program under linux

    - by MaiTiano
    There is a piece of my program: height = atoi(argv[3]); width = atoi(argv[2]); sprintf(seqName,"%s", argv[1]); // strcpy(seqName, argv[1]); After compiling it, a exe file test is generated, then I use Valgrind to check it. Then I got the following message, however I cannot understand what it tends to tell me. Can anyone provide some kind help, Thanks. 1 contexts (suppressed: 13 from 8) 1 contexts (suppressed: 13 from 8) jl@ubuntu:~/work/dsr_analysis$ valgrind --tool=memcheck --leak-check=yes ./test ==28940== Memcheck, a memory error detector ==28940== Copyright (C) 2002-2009, and GNU GPL'd, by Julian Seward et al. ==28940== Using Valgrind-3.6.0.SVN-Debian and LibVEX; rerun with -h for copyright info ==28940== Command: ./test ==28940== ==28940== Invalid read of size 1 ==28940== at 0x40260CA: strcpy (mc_replace_strmem.c:311) ==28940== by 0x804A5C6: main (me_search.c:1428) ==28940== Address 0x0 is not stack'd, malloc'd or (recently) free'd ==28940== ==28940== ==28940== Process terminating with default action of signal 11 (SIGSEGV) ==28940== Access not within mapped region at address 0x0 ==28940== at 0x40260CA: strcpy (mc_replace_strmem.c:311) ==28940== by 0x804A5C6: main (me_search.c:1428) ==28940== If you believe this happened as a result of a stack ==28940== overflow in your program's main thread (unlikely but ==28940== possible), you can try to increase the size of the ==28940== main thread stack using the --main-stacksize= flag. ==28940== The main thread stack size used in this run was 8388608. ==28940== ==28940== HEAP SUMMARY: ==28940== in use at exit: 0 bytes in 0 blocks ==28940== total heap usage: 0 allocs, 0 frees, 0 bytes allocated ==28940== ==28940== All heap blocks were freed -- no leaks are possible ==28940== ==28940== For counts of detected and suppressed errors, rerun with: -v ==28940== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 13 from 8)1 contexts (suppressed: 13 from 8) 1 contexts (suppressed: 13 from 8)

    Read the article

1