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 Mail for Windows 10

From: Gavin Lambert via Boost-users
Sent: 2018年12月14日 14:44
To: boost-users@lists.boost.org
Cc: Gavin Lambert
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