DaniWeb Forum Index > Software Development > C++

C++ RSS

Call Stack

Please support our C++ advertiser: Intel Parallel Studio Home

•

Join Date: Feb 2008

Posts: 517

Reputation: Jennifer84 is an unknown quantity at this point

Solved Threads: 1

Jennifer84 Jennifer84 is offline

Offline

Posting Pro

Call Stack

Feb 29th, 2008

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:

Help with Code Tags

C++ Syntax (Toggle Plain Text)

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)

 Help with Code Tags 
 C++ Syntax (Toggle Plain Text) 
      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++
      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.

Last edited by Jennifer84; Feb 29th, 2008 at 1:57 pm.

•

Join Date: Oct 2007

Posts: 1,953

Reputation: Duoas has much to be proud of

Solved Threads: 214

Duoas

Offline

Posting Virtuoso

Re: Call Stack

Feb 29th, 2008

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.

•

Join Date: Feb 2008

Posts: 517

Reputation: Jennifer84 is an unknown quantity at this point

Solved Threads: 1

Jennifer84 Jennifer84 is offline

Offline

Posting Pro

Re: Call Stack

Feb 29th, 2008

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)

 Help with Code Tags 
 C++ Syntax (Toggle Plain Text) 
void deallocate(pointer _Ptr, size_type)
{	// deallocate object at _Ptr, ignore size
::operator delete(_Ptr);
}
142
pointer allocate(size_type _Count)
{	// allocate array of _Count elements
return (_Allocate(_Count, (pointer)0));
}
void deallocate(pointer _Ptr, size_type)
{	// deallocate object at _Ptr, ignore size
::operator delete(_Ptr);
}
142
pointer allocate(size_type _Count)
{	// allocate array of _Count elements
return (_Allocate(_Count, (pointer)0));
}

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...

•

Join Date: Apr 2004

Posts: 4,364

Reputation: Dave Sinkula has a brilliant future

Solved Threads: 242

Dave Sinkula Dave Sinkula is offline

Offline

long time no c

Re: Call Stack

Feb 29th, 2008

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.

"One of the methods used by statists to destroy capitalism consists in establishing controls that tie a given industry hand and foot, making it unable to solve its problems, then declaring that freedom has failed and stronger controls are necessary." --Ayn Rand

•

Join Date: Feb 2008

Posts: 517

Reputation: Jennifer84 is an unknown quantity at this point

Solved Threads: 1

Jennifer84 Jennifer84 is offline

Offline

Posting Pro

Re: Call Stack

Feb 29th, 2008

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..

•

Originally Posted by Dave Sinkula

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.

•

Join Date: Apr 2004

Posts: 4,364

Reputation: Dave Sinkula has a brilliant future

Solved Threads: 242

Dave Sinkula Dave Sinkula is offline

Offline

long time no c

Re: Call Stack

Feb 29th, 2008

http://www.embedded.com/story/OEG20010416S0090

Used as

 Help with Code Tags 
 C++ Syntax (Toggle Plain Text) 
assert(index >= 0 && index < MAX);
assert(index >= 0 && index < MAX);

Or whatever is applicable. For example making sure you never walk off the end of an array.

•

Join Date: Feb 2008

Posts: 517

Reputation: Jennifer84 is an unknown quantity at this point

Solved Threads: 1

Jennifer84 Jennifer84 is offline

Offline

Posting Pro

Re: Call Stack

Feb 29th, 2008

Thank you for the info. I will read it and see what I can find out.

•

Originally Posted by Dave Sinkula

http://www.embedded.com/story/OEG20010416S0090

Used as
Help with Code Tags

C++ Syntax (Toggle Plain Text)
assert(index >= 0 && index < MAX);
assert(index >= 0 && index < MAX);
Or whatever is applicable. For example making sure you never walk off the end of an array.