0

Hello, I have completed PSET 4 and passed check50 (at least, for the less comfortable version). However, I somehow have a memory leak of 11 bytes that I cannot diagnose. My complete code is here: For convenience, the relevant section (i.e. where I am using malloc) is below:

// iterate over infile's scanlines
for (int i = 0, biHeight = abs(bi.biHeight); i < biHeight; i++)
{

    //allocate memory to store each line
    RGBTRIPLE *lineBuffer = malloc(bi.biWidth * sizeof(RGBTRIPLE));

    //check to make sure there is enough memory
    if (lineBuffer == NULL)
    {
        fprintf(stderr, "Not enough memory to store a scanline \n");
        exit(1);
    }

    //READ SCANLINE
    // iterate over pixels in scanline
    for (int j = 0; j < bi.biWidth; j++)
    {
        // temporary storage
        RGBTRIPLE triple;

        // read RGB triple from infile
        fread(&triple, sizeof(RGBTRIPLE), 1, inptr);

        // SAVE EACH PIXEL TO ALLOC MEMORY

        (lineBuffer + j)->rgbtRed = triple.rgbtRed;
        (lineBuffer + j)->rgbtGreen = triple.rgbtGreen;
        (lineBuffer + j)->rgbtBlue = triple.rgbtBlue;


    }

    // skip over padding, if any
    fseek(inptr, padding, SEEK_CUR);

    // write the pixels to the outfile, adjusting for scaling

    for (int m = 0; m < scaleFactor; m++)
    {

        writeLine(lineBuffer, outptr, scaleFactor, bi.biWidth, newPadding);
    }

    // free memory
    free(lineBuffer);

}

And here is the the function writeLine

void writeLine(RGBTRIPLE *line, FILE *dest, long scalingFactor, LONG 
width, int pad)
{
//PURPOSE: write each scanline to a new file, accounting for a given 
scaling factor

    // determine padding for scanlines (output file)
    for (int i = 0; i < width; i++)
    {
        for (int j = 0; j < scalingFactor; j++)
        {
            fwrite(line + i, sizeof(RGBTRIPLE), 1, dest);
        }
    }

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

My result from running valgrind resize 1 small.bmp large.bmp

  • ==6217== HEAP SUMMARY:
  • ==6217== in use at exit: 11 bytes in 1 blocks
  • ==6217== total heap usage: 1 allocs, 0 frees, 11 bytes allocated
  • ==6217==
  • ==6217== 11 bytes in 1 blocks are definitely lost in loss record 1 of 1
  • ==6217== at 0x4C2AB80: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
  • ==6217== by 0x401D3E: ??? (in /usr/bin/resize)
  • ==6217== by 0x400F9C: ??? (in /usr/bin/resize)
  • ==6217== by 0x4E58F44: (below main) (libc-start.c:287)
  • ==6217==
  • ==6217== LEAK SUMMARY:
  • ==6217== definitely lost: 11 bytes in 1 blocks
  • ==6217== indirectly lost: 0 bytes in 0 blocks
  • ==6217== possibly lost: 0 bytes in 0 blocks
  • ==6217== still reachable: 0 bytes in 0 blocks
  • ==6217== suppressed: 0 bytes in 0 blocks
  • ==6217==
  • ==6217== For counts of detected and suppressed errors, rerun with: -v
  • ==6217== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 0 from 0)

What I don't understand is that no matter the size of the input bmp (and varying bmp widths), my leakage is a constant 11 bytes. The error also persists if I implement the lineBuffer as an RGBTRIPLE array, instead of a struct pointer.

I'm relatively new to C, so it's possible that I'm missing something obvious. Any help is appreciated. Thank you!

1

You are running resize (which is a bash command) rather than ./resize which is your own program. The clue is in the valgrind line:

y 0x401D3E: ??? (in /usr/bin/resize)

Be sure you run

valgrind ./resize 1 small.bmp large.bmp

and not

valgrind resize 1 small.bmp large.bmp
| improve this answer | |
0

Is it possible that you're not running the code linked above? I ran the code and there was no memory leak. Perhaps you have multiple versions of the code?

| improve this answer | |
  • That's really strange. I keep getting the same error over and over again on my Cloud9 IDE. Maybe I'll try to run it locally and see what happens. Thank you! – Alex Sep 11 '18 at 4:11
  • Have you run update50 recently? – Cliff B Sep 11 '18 at 10:19
  • Yes, I just updated the IDE and tried again. I even re-pasted the code back into a new file. Is it possible this is a valgrind bug? – Alex Sep 11 '18 at 19:26

You must log in to answer this question.

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