Valgrind reports a memory leak when defining a char* array

Question

I have another valgrind error that I can't seem to figure out. I have some code that loads a script then uses strtok() to tokenize the data in said script that has been loaded into a buffer. I allocate memory on the heap for my buffer using the following:

char *pPngStr = new char[4096];

Then at the end of the function, I free the memory using:

delete[] pPngStr;

Valgrind reports the allocation as so:

173 bytes in 1 blocks are definitely lost in loss record 3,753 of 4,627

Valgrind also reports the line where I free the memory as:

Invalid free() / delete / delete[] / realloc()

This is all in the same function is the variable is local to only that function and not the class. I am at a loss as to how valgrind thinks that this is a memory leak. I am allocating all the memory I need then I am freeing it when I am done. I don't see what the problem is.

Here is the complete function (it may be a little messy):

void CSprite::LoadSprite()
{
FILE *pF = fopen("Data/Art/coin/coin.sprite", "rb");

if(!pF)
{
    return;
}

fseek(pF, 0, SEEK_END);
int length = ftell(pF);
fseek(pF, 0, SEEK_SET);

char *aData = new char[length];

fread(aData, 1, length, pF);

CheckGLError();

/**
  * The scripts are setup like so:
  ***********************************************
  * Pngs:
  * 4; // This is the number of frames.
  * <pngname>_001.png;
  * <pngname>_002.png;
  * <pngname>_003.png;
  * <pngname>_004.png;
  *
  * Properties:
  * name=<obj name>;
  * width=###;
  * height=###;
  * framerate=0.### // rate in seconds
  ************************************************
  */

mpSprite = new SGfxSprite;

char *pPngStr = new char[4096];
pPngStr = strtok(aData, "\n");

pPngStr = strtok(NULL, "\n");
int iNumFrames = atoi(pPngStr);
mpSprite->numFrames = iNumFrames;

mpSprite->textures = new GLuint[iNumFrames];
glGenTextures(iNumFrames, mpSprite->textures);

int i = 0; // used for loop only!
while(pPngStr != NULL)
{
    pPngStr = strtok(NULL, "\n");

    if(!strcmp(pPngStr, "Properties:") || i >= iNumFrames)
    {
        break;
    }

    if(mpPng->LoadPng(pPngStr))
    {
        CheckGLError();

        glBindTexture(GL_TEXTURE_2D, mpSprite->textures[i]);
        CheckGLError();

        glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_MIN_FILTER, GL_LINEAR_MIPMAP_LINEAR);
        CheckGLError();

        glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_MAG_FILTER, GL_LINEAR);
        CheckGLError();

        glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_WRAP_S, GL_CLAMP);
        CheckGLError();

        glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_WRAP_T, GL_CLAMP);
        CheckGLError();

        glTexParameteri(GL_TEXTURE_2D, GL_GENERATE_MIPMAP, GL_TRUE);
        CheckGLError();

        glTexImage2D(GL_TEXTURE_2D, 0, GL_RGBA, mpPng->miWidth, mpPng->miHeight, 0, GL_RGBA, GL_UNSIGNED_BYTE, mpPng->mpData);
        CheckGLError();
    }

    ++i;
}

pPngStr = strtok(NULL, "=\n");
pPngStr = strtok(NULL, "\n");
mpSprite->name = pPngStr;

pPngStr = strtok(NULL, "=\n");
pPngStr = strtok(NULL, "\n");
mpSprite->width = atoi(pPngStr);

pPngStr = strtok(NULL, "=\n");
pPngStr = strtok(NULL, "\n");
mpSprite->height = atoi(pPngStr);

pPngStr = strtok(NULL, "=\n");
pPngStr = strtok(NULL, "\n");
mpSprite->framerate = (atof(pPngStr) * 1000);

mpSprite->x = 0;
mpSprite->y = 0;

mpSprite->currentFrame = 0;
mpSprite->paintTimer = 0;

fclose(pF);

delete[] pPngStr, aData;

}

*PLEASE NOTE: this function contains OpenGL code and also invokes members from data structures that are not defined here. The code also compiles without any warnings or errors in Xubuntu 12.04 with g++ (gcc 4.6) using Qt Creator 2.4.1

Answer 1

The line that you have:

delete[] pPngStr, aData;

does not do what you think it does.

Try this instead:

delete[] pPngStr;
delete[] aData;

Note: Until you fix the bug that SJuan76 identifies, my answer is moot.

Answer 2

char *pPngStr = new char[4096];
pPngStr = strtok(aData, "\n");

Just in the line after the new, you are forgetting about the pointer that you go and using the variable to store other data. No doubt that there is a memory leak.