LODSize = (1<<(mLODCount - LOD))+1;
//build the vertex data container; we have twice the vertex count
// for transparent & opaque vertices
mVertexData[LOD] = new TERRAIN_FVF_VERTEX1[ (LODSize-2)*(LODSize-2) * 2 ];
mGroundTypeTriangleCount[LOD] = new unsigned short[mNumGroundTypes*2];
mGroundTypeIndexOffset[LOD] = new unsigned short[mNumGroundTypes*2];Nasty wierd bugs (Part2)
Author
In a previous thread I mentioned that my renderstate manager was sometimes causing crashes in debug builds. I was advised to investigate it, but it now doesn't crash there anymore.
Instead I'm getting similar problems elsewhere in my code! These are not happening every time, or always in the same place (but in the same few locations). I either get an access violation reported, or the message "User breakpoint called from code at 0x7c901230". I'm also getting debug output like:
First-chance exception in 4E4_RTS.exe (NTDLL.DLL): 0xC0000005: Access Violation.
HEAP[4E4_RTS.exe]: HEAP[4E4_RTS.exe]: HEAP: Free Heap block 9b50880 modified at 9b50890 after it was freed
HEAP: Free Heap block 9b51000 modified at 9b51010 after it was freed
The kind of place where this occurs is for instance
I think I have the same problem!
I've been recently porting my GNU GCC code to VS 2005 Express edition and then it started!
It occurs at a certain point in the code and always on a "new" operator. If you put another new in front of it, like "new int", it just goes to the next line and crashes on the other "new" allocator. BUT, if you do "new int[1000]" (and so you allocate more), it doés crash.
Suppose it crashes here:
Object* crash = new Object;
Then it doesn't crash on the first line, but on the seconde line of this code:
int* a = new int;
Object* crash = new Object;
But, if you use thís code, it doés crash on the first line, because you allocate more memory:
int* a = new int[1000];
Object* crash = new Object;
The project itself consists out of a static library with system independant tools, also a static graphics lib that uses the previous lib and then the application that uses the graphics lib.
It even crashes when allocating a member from a std::vector when you add items to it.
I've been recently porting my GNU GCC code to VS 2005 Express edition and then it started!
It occurs at a certain point in the code and always on a "new" operator. If you put another new in front of it, like "new int", it just goes to the next line and crashes on the other "new" allocator. BUT, if you do "new int[1000]" (and so you allocate more), it doés crash.
Suppose it crashes here:
Object* crash = new Object;
Then it doesn't crash on the first line, but on the seconde line of this code:
int* a = new int;
Object* crash = new Object;
But, if you use thís code, it doés crash on the first line, because you allocate more memory:
int* a = new int[1000];
Object* crash = new Object;
The project itself consists out of a static library with system independant tools, also a static graphics lib that uses the previous lib and then the application that uses the graphics lib.
It even crashes when allocating a member from a std::vector when you add items to it.
Hi,
Sounds like a memory corruption error of some sort.
Try using _CrtCheckMemory() to check the validity of the debug heap from time to time:
_CrtCheckMemory() simply checks that everything is in order in the debug heap (only compiles to code if _DEBUG is defined).
Hopefully, this way you should be able to track down if memory is becoming corrupted and where it is being corrupted.
To be extra millitant you can turn on the debug flag _CRTDBG_CHECK_ALWAYS_DF to tell the debug runtime to call _CrtCheckMemory() each time an allocation is made:
You could also try out one of the numerous debug memory managers available (google should find a few), but sometimes integration can be awkward.
Hope this helps!
Mike.
Sounds like a memory corruption error of some sort.
Try using _CrtCheckMemory() to check the validity of the debug heap from time to time:
assert(_CrtCheckMemory())or_ASSERTE(_CrtCheckMemory())_CrtCheckMemory() simply checks that everything is in order in the debug heap (only compiles to code if _DEBUG is defined).
Hopefully, this way you should be able to track down if memory is becoming corrupted and where it is being corrupted.
To be extra millitant you can turn on the debug flag _CRTDBG_CHECK_ALWAYS_DF to tell the debug runtime to call _CrtCheckMemory() each time an allocation is made:
int curFlags = _CrtSetDbgFlag( _CRTDBG_REPORT_FLAG );curFlags |= _CRTDBG_CHECK_ALWAYS_DF;_CrtSetDbgFlag(curFlags);You could also try out one of the numerous debug memory managers available (google should find a few), but sometimes integration can be awkward.
Hope this helps!
Mike.
Give what MIkeWW said a go, but also remember that you don't have to wait until the next allocation is done to catch the error. That could be somewhere unrelated, making it difficult to track down the real problem.
Make sure you use assert()'s elsewhere in your program as well, especially to validate that the expressions used inside square brackets are >= 0 and < the array size.
Make sure you use assert()'s elsewhere in your program as well, especially to validate that the expressions used inside square brackets are >= 0 and < the array size.
Quote:Original post by iMalc
Give what MIkeWW said a go, but also remember that you don't have to wait until the next allocation is done to catch the error. That could be somewhere unrelated, making it difficult to track down the real problem.
Make sure you use assert()'s elsewhere in your program as well, especially to validate that the expressions used inside square brackets are >= 0 and < the array size.
Thanks, but I already do that. I have asserts and other error checking for any pointer or init that is called, for as far as I know.
My guess is that there's a problem with one of the references, but that's just a guess off course.
My errors are basically because for some reason new is returning 0.
I think I may have found the cause though, possibly I should feel ashamed: I think it's a threading issue. I have one extra thread which is used to let me have an animated load screen while levels are loaded etc. I think the problems are caused by code running in this aditional thread. I remember when you create a new project in VS6 you can choose between single/multi-threaded; are the standard libraries multi-thread safe or do I need to change the libraries I link to? If so how can I tell which - or maybe I should just create a new project with different settings?
I think I've got DX set to be multithreaded, but I haven't initialised COM this way.
I think I may have found the cause though, possibly I should feel ashamed: I think it's a threading issue. I have one extra thread which is used to let me have an animated load screen while levels are loaded etc. I think the problems are caused by code running in this aditional thread. I remember when you create a new project in VS6 you can choose between single/multi-threaded; are the standard libraries multi-thread safe or do I need to change the libraries I link to? If so how can I tell which - or maybe I should just create a new project with different settings?
I think I've got DX set to be multithreaded, but I haven't initialised COM this way.
Author
Oh, that was me. Meant to add, when I stop it using the extra thread and just do everything in the main thread I've yet to see a single crash.
AFAIK, when new returns 0 that means your program cannot allocate any memory, usualy because it is out of memory.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
