I have a Form application. From Form1 I open Form3. On Form3 I have a button that consists of 20 pages of code. (The code reads .txt files store values into vectors)

9/10 Times when pressing this button the program function perfectly but 1/10 times I run the program, an Error message comes up:

Debug Error!

HEAP CORRUPTION DETECTED: before Normal block(#1262858) at 0x268F3148.
CRT detected that the application wrote to memory before start of heap buffer.

I did run the program using the F5 key in VC++ 2008, so I can see on what line this error occur. Every time it points to line 141.
The problem for me is this now:

The code that it refer to is code I haven´t wrote. The call Stack look like this:
(Note! I have taken away a lot of lines from this Call Stack just to simplify it)
(I have take many lines away but it begins with the Optimize_Click on the bottom and then Line 141 comes where the problem occurs)

Form1.exe!operator delete(void* pUserData = 0x2467FB58) Line 56	C++

      Form1.exe!std::allocator<int>::deallocate(int* _Ptr = 0x2467FB58, unsigned int __unnamed001 = 200) Line 141	C++

       Form1.exe!std::vector<int,std::allocator<int> >::_Tidy() Line 1139	C++

       Form1.exe!Form1::Form3::Optimize_Click(System::Object^ sender = 0x014cde68, System::EventArgs^ e = 0x0151aadc) Line 4218 + 0x50 bytes	C++

My real question is now, what I see on line 141 above is this:

Form1.exe!std::allocator<int>::deallocate(int* _Ptr = 0x2467FB58, unsigned int __unnamed001 = 200) Line 141 C++


To me this dont tell me anything as this doesn´t refer to acutal code that I have written.
Is it possible to in anyway let C++ find the problem area in the code that I actually have written inside the Optimize_Click.

You are clobbering a pointer or freeing memory too soon somewhere. Then, when the delete operator tries to free the memory, you crash.

Check that you aren't deleting something twice, or assigning a value to a pointer previously assigned a value with new.

If you can't find it, post your code and we'll take a look.

Thanks for answer. I think I have to ask first, because my code is about 20 pages but I think that the problem occurs in an specific area in the code.

Question is this then:
When doubleclick on the line that shows the problem (Line 141), it takes me to a code window(xmemory) that contains of a lot of code that I haven´t wrote. The lines is this:
(It points to Line 141 here)

138	void deallocate(pointer _Ptr, size_type)
139		{	// deallocate object at _Ptr, ignore size
140		::operator delete(_Ptr);
141		}
142
143	pointer allocate(size_type _Count)
144		{	// allocate array of _Count elements
145		return (_Allocate(_Count, (pointer)0));
146		}

This code doesn´t tell me excatly what vector or variable that contains the problem in my code that I have written. Is it possible to orientate to the area in "my" code that I have written through this.
Thank you...

The issue with this sort of thing is that the problem is often not where it is detected. So looking at the place that it was detected my prove fruitless.

There are some utilities that help detect memory abuses, but I cannot recommend any. What I have done instead is to sprinkle the code with debugging test code, perhaps assert ions, in order to find the culprit.

So this meens Ex, if my code is 9 lines. I will first try out the first 3 then the second 3 and finally the last 3 lines and se wich of these lines that the Error occurs on if I understand right.
The real example will then ofcourse be areas of code that do compiles etc...

I might wonder thought what assert ions is, is this something that helps to detect Errors or memory leaks.
Thank you..

The issue with this sort of thing is that the problem is often not where it is detected. So looking at the place that it was detected my prove fruitless.

There are some utilities that help detect memory abuses, but I cannot recommend any. What I have done instead is to sprinkle the code with debugging test code, perhaps assert ions, in order to find the culprit.

This article has been dead for over six months. Start a new discussion instead.