walkSingleFrame run against local process on WIndows crashes

[jgerie]

This is a variation on issue #63 which I reported. My ultimate goal is to walk the stack in the local process, not in an external process. When I try my test program against the local process, the first call to walkSingleFrame dies with:

Program: StackTest.exe
File: f:\dd\vctools\crt\crtw32\misc\dbgheap.c
Line: 1424

Expression: _pFirstBlock == pHead

My test program is:
self_stackwalk.txt

The call stack from the debugger is:

MSVCR120D!_free_dbg_nolock+0x49d
MSVCR120D!_free_dbg+0x4e
MSVCR120D!operator delete+0xbc
stackwalk!std::allocatorstd::_Container_proxy::deallocate+0x10
stackwalk!std::_String_alloc<0,std::_String_base_types<char,std::allocator > >::_Free_proxy+0x38
stackwalk!std::_String_alloc<0,std::_String_base_types<char,std::allocator > >::~_String_alloc<0,std::_String_base_types<char,std::allocator > >+0xf
stackwalk!std::basic_string<char,std::char_traits,std::allocator >::~basic_string<char,std::char_traits,std::allocator >+0x1b
stackwalk!Dyninst::Stackwalker::Walker::newWalker+0x235
StackTest!main+0xaa
StackTest!__tmainCRTStartup+0x11a
StackTest!mainCRTStartup+0xd
KERNEL32!BaseThreadInitThunk+0x24
ntdll!__RtlUserThreadStart+0x2f
ntdll!_RtlUserThreadStart+0x1b

The frame "stackwalk!Dyninst::Stackwalker::Walker::newWalker+0x235" is the return statement in "Walker* Walker::newWalker(std::string exec_name)", so it appears to be dying while deallocating the local variables in that function.

My build and test environment for DynInst is:

• Windows 10, 64-bit
• Visual Studio 12
• Cmake 3.5.2 (cmake-3.5.2-win32-x86)
• Boost 1.59 (I downloaded a pre-built Windows version, boost_1_59_0-msvc-12.0-32)
• DynInst 9.1.0
• I'm building exclusively 32-bit binaries, even though the OS is 64-bit
• For most of my testing and debugging, I'm using a Debug build of DynInst. I tried a Release build first and then moved to Debug to try to figure out the problems.

[wrwilliams]

In order to use C++ interfaces across a module boundary, the caller and callee need to be built with matching configurations--first-party stackwalking with a debug build of Dyninst will need to be linked into a debug build of your target application, and likewise for release. I have seen this behavior before as a result of this problem--destructors, copy constructors, or uses of variables breaking as they cross the border due to differences in object layout.

[jgerie]

Thanks. I fixed the compile switches and this problem has disappeared. I am closing this issue. But I also opened issue #72 - a problem in walking the local process stack that surfaces after this configuration mismatch issue is fixed.