Sign in to follow this  
Icebone1000

new causing std::bad_alloc(unhandled exception)

Recommended Posts

Icebone1000    1958
Whats the reasons new can cause those exceptions? Is this because theres no more memory? When this happens, the debug points to the new implementation(new.cpp):

void *__CRTDECL operator new(size_t size) _THROW1(_STD bad_alloc)
{ // try to allocate size bytes
void *p;
while ((p = malloc(size)) == 0)
if (_callnewh(size) == 0)
{ // report no memory
static const std::bad_alloc nomem;
_RAISE(nomem);
}//***DEBUG GREEN ARROW AT THIS LINE***

return (p);
}



Im not understanding whats happening at all, but I kind know the cause..
I have a piece of code that goes like this:

1#import a file specified by user
2#import the file "file1"
3#import the file "file2"

file1 and file2 are always the same, this code works fine, no heap problem..
This was fine untill I started to import this specific file("inputedfile"), the file is also imported fine(no heap problems), but them importing file1 causes the exception..
So obviously(I guess) "inputedfile" is the problem..but Im not sure why(is it consuming all the heap mem?)

The most weird thing is that: changing the importing order like that:
1#import a file specified by user
2#import the file "file2"
3#import the file "file1"
STILL gives the heap problem at file1, and file1 is WAY SMALLER than file2..that I cant understand..the problem happens at a call to new, where it is creating a d3d vertex structure for ONLY 6 vertices, a simple plane(file2 creates the same for 2280 vertices, a sphere)

Cutting file1 out of the code have another behavior, no heaps problems importing anything, but after some loops on the main loop, it will crashs(triggered a breakpoint), and that debug green arrow with a little blue ball shows up here(malloc.c):

__forceinline void * __cdecl _heap_alloc (size_t size)

{
#ifndef _WIN64
void *pvReturn;
#endif /* _WIN64 */

if (_crtheap == 0) {
_FF_MSGBANNER(); /* write run-time error banner */
_NMSG_WRITE(_RT_CRT_NOTINIT); /* write message */
__crtExitProcess(255); /* normally _exit(255) */
}

#ifdef _WIN64
return HeapAlloc(_crtheap, 0, size ? size : 1);
#else /* _WIN64 */
if (__active_heap == __SYSTEM_HEAP) {
return HeapAlloc(_crtheap, 0, size ? size : 1);
} else
if ( __active_heap == __V6_HEAP ) {
if (pvReturn = V6_HeapAlloc(size)) {
return pvReturn;
}
}
#ifdef CRTDLL
else if ( __active_heap == __V5_HEAP )
{
if (pvReturn = V5_HeapAlloc(size)) {
return pvReturn;
}
}
#endif /* CRTDLL */

if (size == 0)
size = 1;

size = (size + BYTES_PER_PARA - 1) & ~(BYTES_PER_PARA - 1);

return HeapAlloc(_crtheap, 0, size);

#endif /* _WIN64 */
}//***DEBUG GREEN ARROW WITH BLUE BALL AT THIS LINE***





So..Im more curious about those weird behaviors then its cause..I know the problem is the inportedfile, and I dont have a clue why I just dont get a heap message at the inported file since he is the problem...

After finishing debug, the output have those messages:
Quote:

First-chance exception at 0x76ed2b8a in Physics_plus_DX11_practicing.exe: 0xC0000005: Access violation reading location 0xffffffffffffffff.
First-chance exception at 0x000007fefd0aaa7d in Physics_plus_DX11_practicing.exe: Microsoft C++ exception: std::bad_alloc at memory location 0x0015f3b8..
Unhandled exception at 0x000007fefd0aaa7d in Physics_plus_DX11_practicing.exe: Microsoft C++ exception: std::bad_alloc at memory location 0x0015f3b8..

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this