Hi Gavin, Thanks for offering the answer. First question, I have enabled the exception. -fno-exceptions will cause compiling error. Second, I don’t think any error had happened other than coroutine/context destruction. I even tried a very simple code: #include <iostream> #include "boost/coroutine2/all.hpp" using namespace boost::coroutines2; using namespace std; int main() { auto source = coroutine<int>::pull_type([](coroutine<int>::push_type& sink) { int a = 1; sink.operator()(10); }); cout << source.operator bool() << endl; source(); cout << source.operator bool() << endl; return 0; } forced_unwind was thrown as well. BTW, I have the following observation: 1. On Ubuntu 18.4 and windows 64-bit program (where program worked) and windows 32 bit(program cracked), I found force_unwind was all constructed and thrown during coroutine destruction(boost 1.67: fiber_fcontext.hpp:58). I believe boost handles the exception itself on Ubuntu and Windows 64-bit but leaves it unhandled on Windows 32, since my program never handles that exception and never defines noexcept. 2. When corountine2 destroyed, its state is complete | unwind (boost 1.67: push_control_block_cc.ipp:40). Br, Hao. Sent from Mailhttps://go.microsoft.com/fwlink/?LinkId=550986 for Windows 10 From: Gavin Lambert via Boost-usersmailto:boost-users@lists.boost.org Sent: 2018年12月14日 14:44 To: boost-users@lists.boost.orgmailto:boost-users@lists.boost.org Cc: Gavin Lambertmailto:boost@mirality.co.nz Subject: Re: [Boost-users] [corountine2/context] forced_unwind exception on Windows with TDM-GCC On 14/12/2018 16:16, Hao Jiang wrote:
I am porting my program from Linux to Windows with boost coroutine2. I found 32bit program throwing boost::context::detail::forced_unwind every time when coroutine destructed. But 64bit program works like charm.
terminate called after throwing an instance of 'boost::context::detail::forced_unwind'
Are you trying to compile with exceptions disabled or something? forced_unwind is part of the internal plumbing of Boost.Context and can be thrown from any yield point when the coroutine is destroyed while suspended. It's required that this exception is not swallowed and the whole call stack between the yield point and the "outside" of the coroutine is not noexcept. Having said that, I would think that normally that particular example should run to completion and not leave the coroutine suspended, so I wouldn't expect that exception there. Have you checked whether perhaps some other error is occurring first and then being "covered up" by the unwind? _______________________________________________ Boost-users mailing list Boost-users@lists.boost.org https://lists.boost.org/mailman/listinfo.cgi/boost-users