memory problems

[Pete]

I've run into an interesting memory problem. I think I'm running out of
heap space, but I'm not sure....

I'm creating two new arrays like such....

pImage = new UBYTE [nImageSize];
pImageTemp = new UBYTE [nImageSize];

where nImageSize = 262144. new is NOT returning NULL at this point, which
gives me the impression that new succeeded.

After a little error checking, the code goes to the following statement....

for(int tries = 0;tries <10 && fread (pImageTemp, sizeof (UBYTE),
nImageSize, pFile) != nImageSize; tries++)
{
fclose (pFile);
if (tries == 9)
{
delete [] pImage;
delete [] pImageTemp;
return 0;
}

Now given a pFile named "cloak.tga" (which BTW, was opened succesfully),
this code will successfully load "cloak.tga" most of the time. However, at
an arbitrary point ( say the 4th or 5th time I call this code) fread will
fail. Once it fails it enters the above loop to try freading 9 more times.
Once it fails the first time it will ALWAYS fail the next 9 times. At this
point, when

delete [] pImageTemp;

is called, I get the following error message:

HEAP[Bruteball.exe]: Heap block at 070ADB18 modified at 070ADF50
past requested size of 430

So am I running out of Heap space? If so, why isn't new returning NULL?
Anyone have any ideas of how to fix this issue?

Thanks,
-Pete

 

[David White]

I've run into an interesting memory problem. I think I'm running out of
heap space, but I'm not sure....

I'm creating two new arrays like such....

pImage = new UBYTE [nImageSize];
pImageTemp = new UBYTE [nImageSize];

where nImageSize = 262144. new is NOT returning NULL at this point, which
gives me the impression that new succeeded.

After a little error checking, the code goes to the following statement....

for(int tries = 0;tries <10 && fread (pImageTemp, sizeof (UBYTE),
nImageSize, pFile) != nImageSize; tries++)
{
fclose (pFile);
if (tries == 9)
{
delete [] pImage;
delete [] pImageTemp;
return 0;
}

Now given a pFile named "cloak.tga" (which BTW, was opened succesfully),
this code will successfully load "cloak.tga" most of the time. However, at
an arbitrary point ( say the 4th or 5th time I call this code) fread will
fail. Once it fails it enters the above loop to try freading 9 more times.

Once it fails the first time it will ALWAYS fail the next 9 times.

But you are closing the file in the loop, so it has to fail every other
time.

At this
point, when

delete [] pImageTemp;

is called, I get the following error message:

HEAP[Bruteball.exe]: Heap block at 070ADB18 modified at 070ADF50
past requested size of 430

So am I running out of Heap space? If so, why isn't new returning NULL?

Unless it's an old compiler it will never return null. 'new' throws an
exception if it fails, so if it returns at all it succeeded.

Anyone have any ideas of how to fix this issue?

I don't think you are running out of memory. It looks like a memory
corruption caused by writing to where you are not supposed to. I can't tell
from the code you've posted what's wrong. Try deleting the memory
immediately after allocating it and see if the error still occurs. If it
doesn't then you know you are doing something later that's causing the
corruption. If you post the code for a complete, small-as-possible program
that exhibits the problem then the cause of the problem might be more
apparent.

Thanks,

Thank you. I'm sure many regulars are relieved and grateful for your
on-topic question.

DW

 

[Pete]

LOL! Good point about the fclose(). I just added that retry loop last
minute to try and debug. Course if your debugging code has a bug in it, its
not that useful, LOL!

Thanks for the feedback. I managed to figure out what was wrong. This code
is used to colorize and overlay a bunch of grayscale tga files into the same
memory chunk, so that a single openGL texture can be created out of about
15 overlaped tga files. Its for a random anime face generator. Turns out
at some point I got the brilliant idea to save space by turning a couple all
ALPHA tga files (bald guys) into 16x16, in my 256x256 image directory. Of
course trying to fit a 256x256 image in the space of a 16x16 image
apparently causes some problems Funny thing is I didn't make the same
"optimization" in my 64x64 image dirrectory, so I wasn't having a problem
with the smaller images. LOL! I'm a moron.

Thanks again for the feedback.

-Pete

I've run into an interesting memory problem. I think I'm running out of
heap space, but I'm not sure....

I'm creating two new arrays like such....

pImage = new UBYTE [nImageSize];
pImageTemp = new UBYTE [nImageSize];

where nImageSize = 262144. new is NOT returning NULL at this point, which
gives me the impression that new succeeded.

After a little error checking, the code goes to the following statement....

for(int tries = 0;tries <10 && fread (pImageTemp, sizeof (UBYTE),
nImageSize, pFile) != nImageSize; tries++)
{
fclose (pFile);
if (tries == 9)
{
delete [] pImage;
delete [] pImageTemp;
return 0;
}

Now given a pFile named "cloak.tga" (which BTW, was opened succesfully),
this code will successfully load "cloak.tga" most of the time. However, at
an arbitrary point ( say the 4th or 5th time I call this code) fread will
fail. Once it fails it enters the above loop to try freading 9 more times.

Once it fails the first time it will ALWAYS fail the next 9 times.

But you are closing the file in the loop, so it has to fail every other
time.

At this
point, when

delete [] pImageTemp;

is called, I get the following error message:

HEAP[Bruteball.exe]: Heap block at 070ADB18 modified at 070ADF50
past requested size of 430

So am I running out of Heap space? If so, why isn't new returning

NULL?

Unless it's an old compiler it will never return null. 'new' throws an
exception if it fails, so if it returns at all it succeeded.

Anyone have any ideas of how to fix this issue?

I don't think you are running out of memory. It looks like a memory
corruption caused by writing to where you are not supposed to. I can't tell
from the code you've posted what's wrong. Try deleting the memory
immediately after allocating it and see if the error still occurs. If it
doesn't then you know you are doing something later that's causing the
corruption. If you post the code for a complete, small-as-possible program
that exhibits the problem then the cause of the problem might be more
apparent.

Thanks,

Thank you. I'm sure many regulars are relieved and grateful for your
on-topic question.

DW