views:

554

answers:

2

EDIT: Just to make things clear, this problem was caused by a typo in my code, in

pointer = new BYTE(datasize);

should have been

pointer = new BYTE[datasize];

All is well!

END

Hi!

I'm having a weird stack overflow problem in Visual Studio 2005 in a C++ project..

In my code, I have a

BYTE* pointer;

This pointer is set to NULL, and then allocated with some memory and then cleared to 0x00. Like so:

pointer = NULL;
pointer = new BYTE(dataSize);
memset(pointer,0x00,dataSize);

Now, I've run this a few times, and get two different results.. Sometimes (in a later part of the program, when i'm deleting the pointer with delete[]) it says that the heap is corrupted, and upon inspection of the call stack it appears that _CrtIsValidHeapPointer is asserting that it is not a valid pointer. However I checked this pointer and it seems to be valid to me (it's got a memory address). Am I missing something?

In the other scenario, the app freezes for a really short time, and I get a stack overflow message. When I inspect the call stack, it looks like this

 something.dll!_heap_alloc_base(unsigned int size=568)  Line 105 + 0x28 bytes   C
something.dll!_heap_alloc_dbg(unsigned int nSize=532, int nBlockUse=2, const char * szFileName=0x0627fec8, int nLine=608)  Line 411 + 0x9 bytes C++
something.dll!_nh_malloc_dbg(unsigned int nSize=532, int nhFlag=0, int nBlockUse=2, const char * szFileName=0x0627fec8, int nLine=608)  Line 268 + 0x15 bytes C++
something.dll!_malloc_dbg(unsigned int nSize=532, int nBlockUse=2, const char * szFileName=0x0627fec8, int nLine=608)  Line 191 + 0x1b bytes C++
something.dll!_calloc_dbg(unsigned int nNum=1, unsigned int nSize=532, int nBlockUse=2, const char * szFileName=0x0627fec8, int nLine=608)  Line 563 + 0x15 bytes C++
something.dll!_getptd_noexit()  Line 608 + 0x18 bytes C
something.dll!_errno()  Line 281 + 0x5 bytes C
something.dll!_heap_alloc_dbg(unsigned int nSize=532, int nBlockUse=2, const char * szFileName=0x0627fec8, int nLine=608)  Line 415 + 0x5 bytes C++
something.dll!_nh_malloc_dbg(unsigned int nSize=532, int nhFlag=0, int nBlockUse=2, const char * szFileName=0x0627fec8, int nLine=608)  Line 268 + 0x15 bytes C++
something.dll!_malloc_dbg(unsigned int nSize=532, int nBlockUse=2, const char * szFileName=0x0627fec8, int nLine=608)  Line 191 + 0x1b bytes C++
something.dll!_calloc_dbg(unsigned int nNum=1, unsigned int nSize=532, int nBlockUse=2, const char * szFileName=0x0627fec8, int nLine=608)  Line 563 + 0x15 bytes C++
something.dll!_getptd_noexit()  Line 608 + 0x18 bytes C
something.dll!_errno()  Line 281 + 0x5 bytes C
something.dll!_heap_alloc_dbg(unsigned int nSize=532, int nBlockUse=2, const char * szFileName=0x0627fec8, int nLine=608)  Line 415 + 0x5 bytes C++
something.dll!_nh_malloc_dbg(unsigned int nSize=532, int nhFlag=0, int nBlockUse=2, const char * szFileName=0x0627fec8, int nLine=608)  Line 268 + 0x15 bytes C++
something.dll!_malloc_dbg(unsigned int nSize=532, int nBlockUse=2, const char * szFileName=0x0627fec8, int nLine=608)  Line 191 + 0x1b bytes C++
something.dll!_calloc_dbg(unsigned int nNum=1, unsigned int nSize=532, int nBlockUse=2, const char * szFileName=0x0627fec8, int nLine=608)  Line 563 + 0x15 bytes C++
something.dll!_getptd_noexit()  Line 608 + 0x18 bytes C
something.dll!_errno()  Line 281 + 0x5 bytes C
something.dll!_heap_alloc_dbg(unsigned int nSize=532, int nBlockUse=2, const char * szFileName=0x0627fec8, int nLine=608)  Line 415 + 0x5 bytes C++
something.dll!_nh_malloc_dbg(unsigned int nSize=532, int nhFlag=0, int nBlockUse=2, const char * szFileName=0x0627fec8, int nLine=608)  Line 268 + 0x15 bytes C++
something.dll!_malloc_dbg(unsigned int nSize=532, int nBlockUse=2, const char * szFileName=0x0627fec8, int nLine=608)  Line 191 + 0x1b bytes C++
something.dll!_calloc_dbg(unsigned int nNum=1, unsigned int nSize=532, int nBlockUse=2, const char * szFileName=0x0627fec8, int nLine=608)  Line 563 + 0x15 bytes C++
something.dll!_getptd_noexit()  Line 608 + 0x18 bytes C
something.dll!_errno()  Line 281 + 0x5 bytes C

There is a LOT of these calls, and I'm pretty certain this is causing the stack overflow.. Any idea what this problem might be? I've tried looking to see if I'm allocating/deallocating wrong, but I haven't written to the memory block that I allocated aside from the memset..

Is there something wrong with the way I'm allocating/deallocating memory?

I'm using this code to deallocate:

if (pointer != NULL){
    delete[] pointer;
    pointer = NULL;
}

This should make sure I'm not freeing memory that's already freed right?

Thanks..

EDIT: In the output window, I'm also getting a TON of these:

First-chance exception at 0x76df0839 in app.exe: 0xC0000005: Access violation reading location 0xfffffff8.
First-chance exception at 0x76e2871f in app.exe: 0xC0000005: Access violation reading location 0x00000004.
First-chance exception at 0x76e00a65 in app.exe: 0xC0000005: Access violation reading location 0xfffffff8.
First-chance exception at 0x76e00a65 in app.exe: 0xC0000005: Access violation reading location 0xfffffff8.
First-chance exception at 0x76e00a65 in app.exe: 0xC0000005: Access violation reading location 0xfffffff8.
First-chance exception at 0x76e00a65 in app.exe: 0xC0000005: Access violation reading location 0xfffffff8.
First-chance exception at 0x76e00a65 in app.exe: 0xC0000005: Access violation reading location 0xfffffff8.
First-chance exception at 0x76e00a65 in app.exe: 0xC0000005: Access violation reading location 0xfffffff8.
First-chance exception at 0x76e00a65 in app.exe: 0xC0000005: Access violation reading location 0xfffffff8.
First-chance exception at 0x76e00a65 in app.exe: 0xC0000005: Access violation reading location 0xfffffff8.
First-chance exception at 0x76e00a65 in app.exe: 0xC0000005: Access violation reading location 0xfffffff8.
First-chance exception at 0x76e00a65 in app.exe: 0xC0000005: Access violation reading location 0xfffffff8.
First-chance exception at 0x76e00a65 in app.exe: 0xC0000005: Access violation reading location 0xfffffff8.
First-chance exception at 0x76e00a65 in app.exe: 0xC0000005: Access violation reading location 0xfffffff8.
+6  A: 

I think you meant:

pointer = new BYTE[size];
Anders K.
OH SNAP! I WAS ALLOCATING WITH BYTE(size) instead of BYTE[SIZE]!! Silly me!!!
krebstar
DAMN THANKS MAN!!! I spent a whole day and I kept glossing over it!!!
krebstar
Oh I get it, `new byte(size)` and `new byte[size]` will allocate the same amount of memory but you **have** to `delete` the former and `delete []` the latter.
Igor Zevaka
@Igor: incorrect `new byte(size)` will allocate one byte and initialize it with the value `size`. `new byte[size]` will create `size` bytes with no default initialization.
Evan Teran
I did some reading on this and Evan Teran is correct.
krebstar
A: 

Your de-allocation code should be:

if (pointer != NULL){
    delete[] pointer;
    pointer = NULL;
}
Igor Zevaka
No, the NULL test is unnecessary.
Steve Fallows
is it ok to free (or try to free) a NULL pointer?
krebstar
Yeah, I was just responding to a typo in the OP :))
Igor Zevaka
Yes. The standard specifies that attempting to delete `null` is the same as doing nothing.
GMan