What may cause this problem?

I am working on a simulation program, which simulates a complex dynamic environment with lots of class

construction and destructions. I used <vector> to store pointers to these classes.

The program showed some error message after running for about 40 minutes. (This is very frustrating, each time I

put some message into the code to locate the error, I have to wait for 40 min to see the message show up. If

anybody knows a better way of debuging this kind of error, please let me know!)

If I run the exe directly, then the program shows some error(not mentioning any specific information about the

error, no error report at all), then no matter what my choice is(retry, ignore, abort), the program break down.

If I run the program under F5 mode, then It show message "Unhandled exception in simulation.exe(KERNEL32.DLL)

:0xE06D7363: Microsoft C++ Exception. "Then I clicked OK, then the compiler showed the assemble language code

that caused the error, as shown below:


7C812A25 test esi,esi
7C812A27 mov dword ptr [ebp-4Ch],eax
7C812A2A mov dword ptr [ebp-44h],7C812A09h
7C812A31 je 7C812AD0
7C812A37 mov ecx,dword ptr [ebp+10h]
7C812A3A cmp ecx,0Fh
7C812A3D ja 7C844790
7C812A43 test ecx,ecx
7C812A45 mov dword ptr [ebp-40h],ecx
7C812A48 je 7C812A51
7C812A4A push edi
7C812A4B lea edi,[ebp-3Ch]
7C812A4E rep movs dword ptr [edi],dword ptr [esi]
7C812A50 pop edi
7C812A51 lea eax,[ebp-50h]
7C812A54 push eax
7C812A55 call dword ptr ds:[7C801508h]
7C812A5B pop esi <<======This is the place where VC stoped!!!
7C812A5C leave
7C812A5D ret 10h
7C812A60 test edi,edi
7C812A62 jle 7C80BD9E
7C812A68 mov edx,dword ptr [ebp-4]
7C812A6B mov dword ptr [ebp+0Ch],edx
7C812A6E movzx edx,word ptr [esi]
7C812A71 mov edi,dword ptr [ebp-8]
7C812A74 mov dl,byte ptr [edx+edi]
7C812A77 mov byte ptr [ecx],dl
7C812A79 mov edi,dword ptr [eax+0Ch]
7C812A7C movzx edx,dl
7C812A7F mov dx,word ptr [edi+edx*2]
7C812A83 cmp dx,word ptr [esi]
7C812A86 jne 7C84B42F

Then I click F5 again, the program just continue to run. (This is also a little weird to me, but last time I had

a problem that does not corrupt the program under the debug mode, so I am not too surprised)



I googled it briefly, I guess it's related with "corrupted stack", but I know nothing about 'assemble language'

or 'stack' at all, can anybody help me to analyze what might cause this problem? How can I locate the

problematic code more easily?
Thanks.

You have a pointer problem. Check that you are not writing beyond an arrays or anything of that nature. If you are using char arrays instead of C++ strings, then definitely check that you don't have a problem with them.

From what it sounds like, you're having pointer trouble with your allocation and/or deallocation of memory.

Could you please explain how you know it's a pointer problem?

Sure.

Quote:

---

Originally Posted by pingpangpang

I used <vector> to store pointers to these classes.

---

This tells me you're explicitly dealing with lots of pointers. The chances of something going wrong increases proportionally to the amount of control you exercise with regard to memory management.

Quote:

---

Originally Posted by pingpangpang

The program showed some error message after running for about 40 minutes.

---

Delayed reaction here means it's not an obvious problem. The ticking time bomb scenario doesn't usually show up if you do something obviously wrong. Something subtle like pointer errors would make more sense.

For example, in the old fashioned world of deprecated C, the function gets() returns a char * into the buffer you give it. Now it might appear to work perfectly find while the user enters simple little strings, but if a string is given to it that is larger than the buffer, you'll have a crash.

It's for this reason, in addition to the ability that such a program can be taken over by a malicious user that functions like gets() are discouraged and why C++ in general ignores a lot of C functions and appears to "reinvent the wheel".

Quote:

---

Originally Posted by pingpangpang

If I run the exe directly, then the program shows some error(not mentioning any specific information about the

error, no error report at all), then no matter what my choice is(retry, ignore, abort), the program break down.

---

Just a guess it's having trouble writing/reading to memory, in which case it would be pointer related.

Quote:

---

Originally Posted by pingpangpang

7C812A5B pop esi <<======This is the place where VC stoped!!!

---

ESI is a CPU register used for pointers like C-style strings, if I remember correctly, although I'm sure it could have other usages. The fact that it crashes upon popping it off the stack shows you could have an issue with the stack. This means you possibly wrote too far into memory... ie. overran a buffer.

Quote:

---

Originally Posted by pingpangpang

I googled it briefly, I guess it's related with "corrupted stack"

---

Corrupted stack is always related to the programmer doing something that allows a buffer to be overrun or something similar. This is what I described with gets().

:)

MacGyver steals the show.