vector resizing, heap errors

[pramod_49]

hi,

i am using vectors in my c++ program. when i resize them multiple times in different function calls, the compiler is giving the following error,

"Damage: After Normal Block(#231) at 0x00432f90"

can anybody help me out on this?

thanks.

[arunkumar_gona]

Iam not sure what exactly might be happening in your case but this error can happen when you cross the variables memory limits or when memory overwite's happen.

[pramod_49]

Thanks for the reply,

i got rid of the problem.

I was clearing the two dimensional vector,vector<vector(float)> before resize it. After commenting out the vector.clear() code line i am not experiencing the problem any more. i guess that was the one giving the error.

[cup]

This normally indicates that there is something going wrong somewhere else in your code. Something is walking all over your heap.

By not clearing, will you eventually run out of memory or is it one of those mini programs where memory leakage isn't a problem.

[pramod_49]

I don't think anything else is wrong with my program because only one function has modifiable access to the vector. Whatever is happening it is only in that single function. Also i am not using the heap for any other purpose.

Anyway it is one of those programs( my summer honors project actually) where small memory leaks even if they lurk in, it doesn't matter.

[Paul McKenzie]

Originally posted by pramod_49
I don't think anything else is wrong with my program because only one function has modifiable access to the vector. Whatever is happening it is only in that single function. Also i am not using the heap for any other purpose.

Anyway it is one of those programs( my summer honors project actually) where small memory leaks even if they lurk in, it doesn't matter. Beware!! This doesn't mean that your program will run on your professor's computer! You will be embarassed when your program crashes and burns as soon as it is run on another computer due to illegal memory accesses (which I can bet money on that this is what's happening in your code)

Since you're only storing floats in the vector, there should be nothing wrong in the vector<> code. It is virtually unbreakable, since you are storing only a POD (plain-old-data) type. If you were storing objects then maybe the object doesn't behave correctly when things are copied and moved (which is what vector does). However this is not the case here.

Even though you claim you are not accessing the heap in any way, are you still using pointers? Are you still using arrays? Are you still (somewhere) doing memcpy's, memset's, or using the C-string functions such as strcpy() or strcat()? If so, you may just be overwriting memory, and your memory overwrites are corrupting the heap or other memory that the vector needs to operate correctly, even though you may never have a single call to "new" or "malloc".

Again, your vector is virtually unbreakable since it is only storing floats. Usage of clear() or resize() in any combination under the sun won't do any harm whatsoever. The only issue is if you are accessing a vector element with opertor [], and the index is out of bounds. This of course is a memory overwrite, since operator[] does not warn you of out-of-bounds accesses (in that case, use the at() function, since vector throws an exception if you try to access an invalid index). Therefore the problem is more than likely that you are corrupting something within your program with a memory overwrite. This is the only explanation why clear() is acting erratically when it shouldn't. Eliminating a clear() call on a vector of floats (or even a vector of vector of floats) shouldn't mysteriously make a heap management error disappear.

And as I stated in the first sentence, don't be surprised when your professor tries to run your program, and he/she gets a segmentation fault or GPF, causing you to wind up getting a "C-" instead of an "A". So whatever time you have, check all of the things that I've mentioned. If not, cross your fingers and hope that the lurking memory access errors don't show up. If you've ever worked in this industry, they show up at the worst times.

Regards,

Paul McKenzie

[pramod_49]

Hi guys,

I took paul's advice above to check my entire code for any out of bounds array accesses. I painstakingly converted all my subscripting accesses of the vector ( about 200 accesses) to use the vector.at() function.

But now i have a new unhandled exception, whose location i am not able to figure out. I am doing the project in VC++ using OpenGL, and the error is

" Unhandled exception in NURBSEditor.exe (KERNEL32.DLL):
0xE06D7363): Microsoft C++ Exception"

Also i do not have any strcat, strcpy etc. in the program apart from vector allocation and subscripting accesses(all of which i converted to vector.at()). No mallocs, no news too.

I do not have a clue to what is happening in my case,
so please help me.

[Paul McKenzie]

Originally posted by pramod_49
Hi guys,

I took paul's advice above to check my entire code for any out of bounds array accesses. I painstakingly converted all my subscripting accesses of the vector ( about 200 accesses) to use the vector.at() function.

But now i have a new unhandled exception, whose location i am not able to figure out. I am doing the project in VC++ using OpenGL, and the error is

" Unhandled exception in NURBSEditor.exe (KERNEL32.DLL):
0xE06D7363): Microsoft C++ Exception"

Also i do not have any strcat, strcpy etc. in the program apart from vector allocation and subscripting accesses(all of which i converted to vector.at()). No mallocs, no news too.

I do not have a clue to what is happening in my case,
so please help me. If you run your program in the debugger, what does the call stack say when the error occurs? The way you debug this is to check the call stack. The call stack shows what functions were called that led up to the error.

Regards,

Paul McKenzie

[pramod_49]

Thanks again Paul,

as said before, i changed my entire code to use the at() function. Then i used the C++ exception handling to narrow down the problem to a block containing an errant for loop. It is in that loop all the mischeif has been happening.

As you pointed out there is nothing wrong with vector resize and clear being simultaneously used. The real problem was that, while accessing a 2D vector of floats, of which the second dimension has four elements, -

- the loop was accessing indices 1,2,3,4 instead of 0,1,2,3.

After i corrected that silly typo, the code now runs without any errors what so ever. ( I tried it out on 4 machines :) ).

[Paul McKenzie]

Great :)

Regards,

Paul McKenzie