Heap or Stack Corruptions?
Jack
{
CSimplusDoc *pDoc = GetDocument();
int lastcount = 0;
D3DXVECTOR3 a(10.0f, 0.0f, 14.0f);
D3DXVECTOR3 b(20.0f, 0.0f, 24.0f);
m_iTotalCharToProcess = 1;
FINFO *m_finfo = new FINFO; <<<<< Kazboom
char strg[50];
I am tracking an error of my application. I've got a heap or stack
corruption near m_finfo...
Without knowledge of which one it actually is, I wonder if the above
statements pose immediate danger or not?
Thanks
Jack
Jack
> FINFO *m_finfo = new FINFO; <<<<< Kazboom
Don't take it too literal as this is just an experiment.... I put m_ there
on purpose.....
Jack
Igor Tandetnik
news:uiO8PVSU...@TK2MSFTNGP05.phx.gbl
> void CSimplusView::ProcessMovement()
> {
> CSimplusDoc *pDoc = GetDocument();
>
> int lastcount = 0;
> D3DXVECTOR3 a(10.0f, 0.0f, 14.0f);
> D3DXVECTOR3 b(20.0f, 0.0f, 24.0f);
> m_iTotalCharToProcess = 1;
> FINFO *m_finfo = new FINFO; <<<<< Kazboom
> char strg[50];
>
> I am tracking an error of my application. I've got a heap or stack
> corruption near m_finfo...
The problem is, heap corruption has likely happened earlier, possibly in
a code completely unrelated to FINFO. It just manifests now when an
unrelated allocation just happens to hit corrupted data structures in
the heap manager.
The only way I know of to debug heap corruption bugs is to carefully
review all your code. Look for buffer overruns of buffers allocated on
the heap, as well as double deallocation (freeing a pointer that was
already freed once).
--
With best wishes,
Igor Tandetnik
With sufficient thrust, pigs fly just fine. However, this is not
necessarily a good idea. It is hard to be sure where they are going to
land, and it could be dangerous sitting under them as they fly
overhead. -- RFC 1925
Jack
>> FINFO *m_finfo = new FINFO; <<<<< Kazboom
>> char strg[50];
>>
>> I am tracking an error of my application. I've got a heap or stack
>> corruption near m_finfo...
>
> The problem is, heap corruption has likely happened earlier, possibly in a
> code completely unrelated to FINFO. It just manifests now when an
> unrelated allocation just happens to hit corrupted data structures in the
> heap manager.
Dear Igor
My head just hurts because the error just happened randomly.....
I commented out some code in this method, it ran fine with just several
memory leaks... at least it ran to the end without crashing. Do you want me
to show you that code? Igor... Yes...???
MessageBox = Unhandled exception 0x7c921230 in Simplus.exe. User breakpoint.
Crashed in here
// Malloc.c
if (size == 0)
size = 1;
#ifndef _WIN64
if (__active_heap != __SYSTEM_HEAP)
size = (size + BYTES_PER_PARA - 1) & ~(BYTES_PER_PARA - 1);
#endif /* _WIN64 */
return HeapAlloc(_crtheap, 0, size); <<<<<<<<<<<<<< my goodness :(
Thanks
Jack
Ulrich Eckhardt
> CSimplusDoc *pDoc = GetDocument();
This can fail at a very early stage of view creation!
> int lastcount = 0;
> D3DXVECTOR3 a(10.0f, 0.0f, 14.0f);
> D3DXVECTOR3 b(20.0f, 0.0f, 24.0f);
> m_iTotalCharToProcess = 1;
> FINFO *m_finfo = new FINFO; <<<<< Kazboom
What if you remove the assignment, i.e. only write 'new FINFO;'? What if you
create the object on the stack, i.e. 'FINFO m_finfo;'? What is in the
constructor of FINFO? What if you move the line further up or down?
> char strg[50];
Ew, such strings are always an invitation for buffer overflows!
> I am tracking an error of my application. I've got a heap or stack
> corruption near m_finfo...
> Without knowledge of which one it actually is, I wonder if the above
> statements pose immediate danger or not?
None of these cause errors per se, but of course it might depend on the
circumstances. The problem with corruption errors is usually that they
don't become visible till some time after the corruption took place.
Lastly, but I think you indicated you were aware of it, 'm_' locals tend to
easily be confused with equally named members.
Uli
Nathan Mates
>I am tracking an error of my application. I've got a heap or stack
>corruption near m_finfo...
If you're using the debug version of the CRT, you can ask that to
check if your heap's corrupted. Look at
http://msdn2.microsoft.com/en-us/library/e73x0s4b(VS.71).aspx and
related pages for more info. If you have a repeatable crash, then
sprinkle some calls to _CrtCheckMemory() throughout.
Some apps like Boundschecker (see
http://www.compuware.com/products/devpartner/visualc.htm ) may be able
to automate some of the checks for heap corruption. It's been years
since I used that program, and when it worked, it worked well. The
downsides were (1) it slows application execution down to a crawl when
applied, and (2) it was fairly pricey. Not sure if either/both of
those complaints have been fixed.
Nathan Mates
--
<*> Nathan Mates - personal webpage http://www.visi.com/~nathan/
# Programmer at Pandemic Studios -- http://www.pandemicstudios.com/
# NOT speaking for Pandemic Studios. "Care not what the neighbors
# think. What are the facts, and to how many decimal places?" -R.A. Heinlein
Igor Tandetnik
> <snip>
>>> FINFO *m_finfo = new FINFO; <<<<< Kazboom
>>> char strg[50];
>>>
>>> I am tracking an error of my application. I've got a heap or stack
>>> corruption near m_finfo...
>>
>> The problem is, heap corruption has likely happened earlier,
>> possibly in a code completely unrelated to FINFO. It just manifests
>> now when an unrelated allocation just happens to hit corrupted data
>> structures in the heap manager.
>
Heap corruption often manifests in seemingly random ways.
> I commented out some code in this method, it ran fine with just
> several memory leaks... at least it ran to the end without crashing.
> Do you want me to show you that code? Igor... Yes...???
Again - the actual bug is likely in a different, completely unrelated
piece of code. The code that crashes is simply unlucky to hit the data
structures that were already corrupted before. The crashing code is
likely innocent.
Jack
<snip>
>
> This can fail at a very early stage of view creation!
>
>> int lastcount = 0;
>> D3DXVECTOR3 a(10.0f, 0.0f, 14.0f);
>> D3DXVECTOR3 b(20.0f, 0.0f, 24.0f);
>> m_iTotalCharToProcess = 1;
>> FINFO *m_finfo = new FINFO; <<<<< Kazboom
>
> What if you remove the assignment, i.e. only write 'new FINFO;'? What if
> you
> create the object on the stack, i.e. 'FINFO m_finfo;'? What is in the
> constructor of FINFO? What if you move the line further up or down?
>
No, because I need to hold a lot of unpredicted m_finfo in the future, keep
that pointer??
FINFO is basically a struct with a D3DXVECTOR3 and float (Direction) inside
it
I shuffled the variables everywhere, but still came up with errors....
>> char strg[50];
>
> Ew, such strings are always an invitation for buffer overflows!
>
I can wipe this out. No use now just for testing
>> I am tracking an error of my application. I've got a heap or stack
>> corruption near m_finfo...
>> Without knowledge of which one it actually is, I wonder if the above
>> statements pose immediate danger or not?
>
> None of these cause errors per se, but of course it might depend on the
> circumstances. The problem with corruption errors is usually that they
> don't become visible till some time after the corruption took place.
>
Let's see the whole thing
//////////////////////////////////////////////////////////
void CSimplusView::ProcessMovement()
{
CSimplusDoc *pDoc = GetDocument();
int lastcount = 0;
D3DXVECTOR3 a(10.0f, 0.0f, 14.0f);
D3DXVECTOR3 b(20.0f, 0.0f, 24.0f);
m_iTotalCharToProcess = 1;
FINFO m_finfo; // = new FINFO;
SetupDirOffsets();
SetupHeuristicTable();
SetupSqrtTable();
SetupTurnTable();
if (pDoc->m_CharInfo[SUPERVISOR]->fS == 1.0f)
{
D3DXVECTOR3 vDist = b - a;//m_CharInfo[i].vEndPos -
m_CharInfo[i].vStartPos;
pDoc->m_CharInfo[SUPERVISOR]->fDist = D3DXVec3Length(&vDist);
// reset
pDoc->m_CharInfo[SUPERVISOR]->fS = 0.0f;
// Finding the path to the destination
// Swap y,z for Findpather
a.y = a.z;
b.y = b.z;
a.z = 0;
b.z = 0;
FindPath(a,b, 3.0f, m_finfo);
// the outcome is D3DXVECTOR3 (x, y, 0);
// but a,b are D3DXVECTOR3 (x, 0, z);
/* for (int w = 0; m_finfo[w].pos.y != a.y && m_finfo[w].pos.x != a.x; w++)
// brute force
{
m_finfo[w].pos.z = m_finfo[w].pos.y;
m_finfo[w].pos.y = 0;
} */////////////////////////// Error 1
// Swap back a/b
a.z = a.y;
b.z = b.y;
a.y = 0;
b.y = 0;
} else if (pDoc->m_CharInfo[SUPERVISOR]->fS < 1.0f) {
// must use D3DXVECTOR3(x, 0, z);
static int countb = 0;
pDoc->m_CharInfo[SUPERVISOR]->fS +=
((pDoc->m_CharInfo[SUPERVISOR]->fSpeed /
pDoc->m_CharInfo[SUPERVISOR]->fDist) * m_fElapsedTime);
pDoc->m_Supervisor->SetPos(GotoWaypoint(m_finfo[countb].pos,
m_finfo[countb+1].pos, pDoc->m_CharInfo[SUPERVISOR]->fS));
countb++;
if (countb > lastcount) { // we hv reached the destination
countb = 0; // find a new waypoint
} //////////////////// Error 2 1/5/2007 (Not too sure about the
algorithm)
}
else if (pDoc->m_CharInfo[SUPERVISOR]->fS > 1.0f) {
pDoc->m_CharInfo[SUPERVISOR]->fS = 1.0f;
}
}
> Lastly, but I think you indicated you were aware of it, 'm_' locals tend
> to
> easily be confused with equally named members.
:) I am just too lazy....
Thanks
Jack
>
> Uli
>
Jack
Alexander Nickolov
in this situation. Note you can use BoundsChecker now without
code instrumentation and the slowdown is not nearly as dramatic
(it's more like 3-6 times as opposed to 50-100 times slower).
--
=====================================
Alexander Nickolov
Microsoft MVP [VC], MCSD
email: agnic...@mvps.org
MVP VC FAQ: http://vcfaq.mvps.org
=====================================
"Nathan Mates" <nat...@visi.com> wrote in message
news:13o4a82...@corp.supernews.com...
Giovanni Dicanio
"Jack" <j...@knight.com> ha scritto nel messaggio
news:uUEsXATU...@TK2MSFTNGP02.phx.gbl...
>> The problem is, heap corruption has likely happened earlier, possibly in
>> a code completely unrelated to FINFO. It just manifests now when an
>> unrelated allocation just happens to hit corrupted data structures in the
>> heap manager.
>
> Dear Igor
> My head just hurts because the error just happened randomly.....
Igor wrote several good points for you:
"The only way I know of to debug heap corruption bugs is to carefully
review all your code. Look for buffer overruns of buffers allocated on
the heap, as well as double deallocation (freeing a pointer that was
already freed once)."
I'd like to add that you should avoid using those old-style raw unsafe C
arrays.
It could be possible that somewhere in your source code you have some raw C
array with an index out of range, and so you are corrupting heap.
You should really consider review your code, and e.g. use robust C++
container classes, like std::vector (and its at() method, which throws an
exception if array index is out of range), or C++ string classes, like ATL
(and MFC) CStringA/W.
If you have lots of pointers, you may consider using boost:: or tr1::
shared_ptr.
You can also mix shared_ptr with STL containers like std::vector,
implementing a robust and safe kind of "garbage collection" :) in C++.
Giovanni
Ivan Brugiolo [MSFT]
Full-PageHeap on the executable image, to catch the heap corruption
as soon as possible.
Full-PageHeap can be enabled, amond other methods with
gflags.exe -p /enable <imagename.exe> /full
Support for enabling runtime instrumentation and integrated
debugging in devenv.exe is available starting VS2005
in the High-End SKUs (the team-architect edition, IIRC).
If this is not viable, the windbg//cdb/ntsd have debugging support
for PageHeap via the `!heap` debugger extension.
Chapter 5 and 6 of this book
http://www.amazon.com/Advanced-Debugging-Addison-Wesley-Microsoft-Technology/dp/0321374460/ref=pd_bbs_sr_1?ie=UTF8&s=books&qid=1199740546&sr=8-1
are devoted to explain the techniques in great details
--
--
This posting is provided "AS IS" with no warranties, and confers no rights.
Use of any included script samples are subject to the terms specified at
http://www.microsoft.com/info/cpyright.htm
"Alexander Nickolov" <agnic...@mvps.org> wrote in message
news:OMgZRJVU...@TK2MSFTNGP03.phx.gbl...
Jack
But had no time to read it at this moment... hope I can survive after that
:)
Thanks
Jack