Heap or Stack Corruptions?

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...
Without knowledge of which one it actually is, I wonder if the above
statements pose immediate danger or not?
Thanks
Jack

Jack
Mon Jan 07 06:24:58 CST 2008


> 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
Mon Jan 07 07:10:16 CST 2008

"Jack" <jl@knight.com> wrote in message
news:uiO8PVSUIHA.1212@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
Mon Jan 07 07:20:42 CST 2008

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

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

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

Ulrich
Mon Jan 07 07:13:11 CST 2008

Jack wrote:
> 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
Mon Jan 07 07:28:34 CST 2008

In article <uiO8PVSUIHA.1212@TK2MSFTNGP05.phx.gbl>, Jack <jl@knight.com> wrote:
>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
Mon Jan 07 07:27:49 CST 2008

"Jack" <jl@knight.com> wrote in message
news:uUEsXATUIHA.1168@TK2MSFTNGP02.phx.gbl
> <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.
>
> My head just hurts because the error just happened randomly.....

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.
--
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
Mon Jan 07 07:39:36 CST 2008

Hi Ulrich,
<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
Mon Jan 07 07:55:32 CST 2008


"Jack" <jl@knight.com> ¼¶¼g©ó¶l¥ó·s»D:eneu7KTUIHA.1208@TK2MSFTNGP03.phx.gbl...
> Hi Ulrich,
> <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;
>
lastcount = 10;


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

Alexander
Mon Jan 07 11:26:58 CST 2008

A tool like BoundsChecker, Insure++ or Purify is indispensable
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: agnickolov@mvps.org
MVP VC FAQ: http://vcfaq.mvps.org
=====================================

"Nathan Mates" <nathan@visi.com> wrote in message
news:13o4a82inpu8420@corp.supernews.com...
> In article <uiO8PVSUIHA.1212@TK2MSFTNGP05.phx.gbl>, Jack <jl@knight.com>
> wrote:
>>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

Giovanni
Mon Jan 07 12:57:45 CST 2008


"Jack" <jl@knight.com> ha scritto nel messaggio
news:uUEsXATUIHA.1168@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
Mon Jan 07 15:16:37 CST 2008

Before going for external tools, I would recomend enabling
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" <agnickolov@mvps.org> wrote in message
news:OMgZRJVUIHA.5164@TK2MSFTNGP03.phx.gbl...
>A tool like BoundsChecker, Insure++ or Purify is indispensable
> 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: agnickolov@mvps.org
> MVP VC FAQ: http://vcfaq.mvps.org
> =====================================
>
> "Nathan Mates" <nathan@visi.com> wrote in message
> news:13o4a82inpu8420@corp.supernews.com...
>> In article <uiO8PVSUIHA.1212@TK2MSFTNGP05.phx.gbl>, Jack <jl@knight.com>
>> wrote:
>>>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
>
>

Jack
Tue Jan 08 06:50:51 CST 2008

I bought a book called Advanced Windows Debugging
But had no time to read it at this moment... hope I can survive after that
:)
Thanks
Jack