Strange program hang, what does this mean in debug?

Question

Strange program hang, what does this mean in debug?

After attaching windbg I found the following:

(1714.258): Access violation - code c0000005 (first chance)
First chance exceptions are reported before any exception handling.
This exception may be expected and handled.
eax=015b5c74 ebx=178a13e0 ecx=dddddddd edx=009a8ca0 esi=09fbf698 edi=09fbf594
eip=005ae2f7 esp=09fbf4a4 ebp=09fbf594 iopl=0         nv up ei ng nz na pe nc
cs=001b  ss=0023  ds=0023  es=0023  fs=003b  gs=0000             efl=00010286
TestApplication!std::_Container_base::_Orphan_all+0x57:
005ae2f7 c70100000000    mov     dword ptr [ecx],0    ds:0023:dddddddd=????????

Call stack:

TestApplication!std::_Container_base::_Orphan_all+0x57
TestApplication!std::vector >::operator=+0x37
TestApplication!boost::asio::detail::win_iocp_io_service::do_one+0x189
TestApplication!boost::asio::detail::win_iocp_io_service::run+0xa2
TestApplication!boost::asio::io_service::run+0x3a

Answer 1

The ecx register has an invalid address (dddddddd). I would suggest this is a case of memory corruption. Consider turning gflags on for the process.

Answer 2

If you are using MSVC and the Debug build configuration, 0xdddddddd usually means that you are attempting to access freed memory. The debug CRT memory manager fills free memory with 0xdd.

MSN

Answer 3

The problem

1. First chance exceptions means that the debugger is giving you, the person who is using the debugger, the first chance to debug the exception, before it throws it back at the program to handle the issue.

2. In this case the exception is "Access violation". This means that your program is trying to read / write from an illegal memory location.

3. Access violations are serious coz it could be corrupting some memory which is critical for your program and this would be the likely reason that your program hangs.

4. From the faulting instruction it seems as if you are trying to get the contents of a 4 byte value from an illegal instruction.

Debugging the Problem

1. If this is your code then you can easily debug this issue by setting the debug symbol location to the output folder of your compiler (this would contain the relevant pdb files)

2. When you get this exception get the call stack (one of the view windows would have it)

3. This would show you the location in your code where the faulting stack has originated.

4. Now open the file that contains this source and set a breakpoint there and the program would hit this point and stop inside the windebugger. Debug from this point and you would know exactly from which line of code this violation is thrown

Tip : Boost comes with source so you can easily put a break point inside this code. Be sure to press F11 while debugging when you get to asio::detail::win_iocp_io_service::do_one.

Answer 4

The callstack is entirely STL/Boost code. Unless something what you're doing is out of the ordinary, I wont assume that the bug is in any section of the callstack you pasted.

A couple of things to check:

1. Any Boost specific #defines that should be defined but arent?

2. Secure SCL & Iterator debugging. Try enabling/disabling it.

3. Are you mixing debug & release code. (bad idea with STL/Boost containers)