Subject: [boost] [coroutine] x86 msvc11 stack corruption
From: Tobias Loew (Tobias.Loew_at_[hidden])
Date: 2014-01-16 09:27:10
I use Boost 1.55 uni-directional coroutines to build an x86 MSVC11
I have a simple pull-type (boost::coroutines::coroutine<void>::pull_type)
that under certain reproducable conditions destroys the stack after
returning from the coroutine.
Here is the corrupted stack as shown by VS2012
> ebs2000.exe!CScriptMainFrame::DoRun(CPascalEditorDoc * 0x00000000, int
0x00000000, int 0x00000000) Line 3372 C++
ebs2000.exe!CScriptMainFrame::OnDebugStepover() Line 4916 C++
mfc110u.dll!_AfxDispatchCmdMsg(CCmdTarget *, unsigned int, int, void
(void) *, void *, unsigned int, AFX_CMDHANDLERINFO *) C++
[Frames below may be incorrect and/or missing]
mfc110u.dll!CCmdTarget::OnCmdMsg(unsigned int, int 0x00000000, void *,
AFX_CMDHANDLERINFO *) Line 364 C++
mfc110u.dll!CWnd::OnCommand(unsigned int 0x00018263, long 0x00000000) Line
mfc110u.dll!CFrameWnd::OnCommand(unsigned int 0x00018263, long 0x00000000)
Line 389 C++
This only happens in windows x86 32-bit release-builds when the coroutine
finishes upon a user-action that also includes a windows WM_SETFOCUS message
on my menu-bar.
If at least one of the following is true, the stack-corruption does NOT
- x64 build
- using a different pull-type, e.g.
- not returning form the coroutine, but pushing just before the end of the
coroutine and swapping the pull-type-variable with a default constructed
Even though I have a lot of workarounds, I still would like to know, why
I had to recompile
ml /safeseh /c make_i386_ms_pe_masm.asm
ml /safeseh /c jump_i386_ms_pe_masm.asm
to get SAFESEH-libraries.
-- View this message in context: http://boost.2283326.n4.nabble.com/coroutine-x86-msvc11-stack-corruption-tp4657990.html Sent from the Boost - Dev mailing list archive at Nabble.com.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk