2

According to valgrind I have a memory leak in my version of resize.

Here's the valgrind output:

==22900== Memcheck, a memory error detector
==22900== Copyright (C) 2002-2013, and GNU GPL'd, by Julian Seward et al.
==22900== Using Valgrind-3.10.1 and LibVEX; rerun with -h for copyright info
==22900== Command: resize
==22900== 
COLUMNS=250;
LINES=14;
export COLUMNS LINES;
==22900== 
==22900== HEAP SUMMARY:
==22900==     in use at exit: 597 bytes in 4 blocks
==22900==   total heap usage: 4 allocs, 0 frees, 597 bytes allocated
==22900== 
==22900== 8 bytes in 1 blocks are definitely lost in loss record 1 of 4
==22900==    at 0x4C2AB80: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==22900==    by 0x401D3E: ??? (in /usr/bin/resize)
==22900==    by 0x400EDC: ??? (in /usr/bin/resize)
==22900==    by 0x4E58F44: (below main) (libc-start.c:287)
==22900== 
==22900== 10 bytes in 1 blocks are definitely lost in loss record 2 of 4
==22900==    at 0x4C2AB80: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==22900==    by 0x401D3E: ??? (in /usr/bin/resize)
==22900==    by 0x400EA4: ??? (in /usr/bin/resize)
==22900==    by 0x4E58F44: (below main) (libc-start.c:287)
==22900== 
==22900== 11 bytes in 1 blocks are definitely lost in loss record 3 of 4
==22900==    at 0x4C2AB80: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==22900==    by 0x401D3E: ??? (in /usr/bin/resize)
==22900==    by 0x400F9C: ??? (in /usr/bin/resize)
==22900==    by 0x4E58F44: (below main) (libc-start.c:287)
==22900== 
==22900== LEAK SUMMARY:
==22900==    definitely lost: 29 bytes in 3 blocks
==22900==    indirectly lost: 0 bytes in 0 blocks
==22900==      possibly lost: 0 bytes in 0 blocks
==22900==    still reachable: 568 bytes in 1 blocks
==22900==         suppressed: 0 bytes in 0 blocks
==22900== Reachable blocks (those to which a pointer was found) are not shown.
==22900== To see them, rerun with: --leak-check=full --show-leak-kinds=all
==22900== 
==22900== For counts of detected and suppressed errors, rerun with: -v
==22900== ERROR SUMMARY: 3 errors from 3 contexts (suppressed: 0 from 0)

And here's my source:

#include <stdio.h>
#include <stdlib.h>

#include "bmp.h"

int main(int argc, char* argv[])
{
        // ensure proper usage
    if (argc != 4)
    {
    printf("Usage: ./resize n infile outfile\n");
    return 1;
}

int foo = atoi(argv[1]);

if(foo > 100 || foo < 1)
{
    printf("Please enter a size-factor between 1 - 100!\n");
    return 1;
}

char* infile = argv[2];
char* outfile = argv[3];

FILE* inptr = fopen(infile, "r");
if (inptr == NULL)
{
    printf("Could not open %s.\n", infile);
    return 2;
}

FILE* outptr = fopen(outfile, "w");
if (outptr == NULL)
{
    fclose(inptr);
    fprintf(stderr, "Could not create %s.\n", outfile);
    return 3;
}

BITMAPFILEHEADER bf;
fread(&bf, sizeof(BITMAPFILEHEADER), 1, inptr);

BITMAPINFOHEADER bi;
fread(&bi, sizeof(BITMAPINFOHEADER), 1, inptr);

if (bf.bfType != 0x4d42 || bf.bfOffBits != 54 || bi.biSize != 40 || 
    bi.biBitCount != 24 || bi.biCompression != 0)
{
    fclose(outptr);
    fclose(inptr);
    fprintf(stderr, "Unsupported file format.\n");
    return 4;
} 

int initWidth = bi.biWidth;
int initHeight = bi.biHeight;

bi.biWidth *= foo;
bi.biHeight     oo;

int initPad =  (4 - (initWidth * sizeof(RGBTRIPLE)) % 4) % 4;
int pad =  (4 - (bi.biWidth * sizeof(RGBTRIPLE)) % 4) % 4;

bi.biSizeImage = abs(bi.biHeight) * ((bi.biWidth * sizeof (RGBTRIPLE)) + pad);

bf.bfSize = bi.biSizeImage + sizeof (BITMAPFILEHEADER) + sizeof (BITMAPINFOHEADER); 

fwrite(&bf, sizeof(BITMAPFILEHEADER), 1, outptr);

fwrite(&bi, sizeof(BITMAPINFOHEADER), 1, outptr);

RGBTRIPLE *buffer = malloc(sizeof(RGBTRIPLE) * (bi.biWidth));

for (int i = 0, biHeight = abs(initHeight); i < biHeight; i++)
{
    int bar = 0;
    for (int j = 0; j < initWidth; j++)
    {
        RGBTRIPLE triple;

        fread(&triple, sizeof(RGBTRIPLE), 1, inptr);

        for(int boo = 0; boo < foo; boo++)
        {
            *(buffer+(bar)) = triple;
            bar++;
        }
    }

    fseek(inptr, initPad, SEEK_CUR);

       for(int r = 0; r < foo; r++)
       {
            fwrite((buffer), sizeof(RGBTRIPLE), bi.biWidth, outptr);

            for (int k = 0; k < pad; k++)
                fputc(0x00, outptr);
       }        
}

free(buffer);

fclose(inptr);

fclose(outptr);

return 0;
}

I absolutely cannot place this memory leak, and it's starting to bug me! Any idea?

  • Interesting. After fixing the typo (missing text " *=f") in the code, I ran your program to test it and try to duplicate the problem. check50 passed completely and valgrind reported no memory leaks. Is it possible that you're running an older version of the executable, or compiling a different version of the code? – Cliff B Nov 6 '16 at 21:00
  • That's so unusual! It's always passed check50, but the exact code there shows me a memory leak with valgrind. I even recompiled, just to make sure. – Charon Nov 6 '16 at 21:07
  • Are you using the cloud9 IDE or some other environment? I'm suspicious that something other than your code is amiss because valgrind is not identifying the lines of code where the problems lie - only the files. – Cliff B Nov 6 '16 at 21:12
  • I am indeed using cloud9, yes. I've run update50, as well. – Charon Nov 6 '16 at 21:29
5

Actually, your apparent problem is that you are running valgrind against a different executable binary, also called resize.

~/workspace/ $ which resize
/usr/bin/resize
~/workspace/ $ whatis resize
resize (1)           - set environment and terminal settings to current xterm window size

Try running valgrind against ./resize (in the appropriate pset directory) instead.

Hope this helps!

  • 1
    That makes much more sense. – Cliff B Nov 7 '16 at 2:22
  • 1
    You sir...are a genius! Thank you so, so much. I literally spent more than 12 hours on this problem. – Charon Nov 7 '16 at 5:23

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .