Boost C++ Libraries: Ticket #10964: future>::unwrap().then() Deadlocks

owner, status changed

viboes — Sat, 24 Jan 2015 10:47:31 GMT

owner changed from Anthony Williams to viboes
status new → assigned

milestone changed

viboes — Sat, 24 Jan 2015 15:50:34 GMT

milestone To Be Determined → Boost 1.58.0

https://github.com/boostorg/thread/commit/c16ec42941a92210033bddee3ef4eb42fd2b1a03

viboes — Sat, 31 Jan 2015 10:12:14 GMT

The following doesn't work after the patch

    boost::async(f).then(
        TestCallback()).unwrap().then(TestCallback()).get();

viboes — Sun, 01 Feb 2015 13:57:55 GMT

This commit should fix it

https://github.com/boostorg/thread/commit/45510facc743aa348e501642ce3d607d12dc7cfc

status changed; resolution set

viboes — Mon, 02 Feb 2015 05:48:22 GMT

status assigned → closed
resolution → fixed

Merge to master https://github.com/boostorg/thread/commit/71997bd9aa43e1da2f05cdd46219d152a1c2321f

status, milestone changed; resolution deleted

viboes — Tue, 08 Sep 2015 19:32:13 GMT

status closed → reopened
resolution fixed
milestone Boost 1.58.0 → To Be Determined

The problem is yet there

See http://www.boost.org/development/tests/develop/developer/output/Flast-FreeBSD10-gcc-6-0-0~gnu++11-boost-bin-v2-libs-thread-test-test_10964-test-gcc-6-0-0-debug-threading-multi.html

and

http://www.boost.org/development/tests/develop/developer/output/Flast-FreeBSD10-gcc-5-1-0~gnu++11-boost-bin-v2-libs-thread-test-ex_future_unwrap-test-gcc-5-1-0-debug-threading-multi.html

terminate called after throwing an instance of 'boost::exception_detail::clone_impl<boost::exception_detail::error_info_injector<boost::lock_error> >'
  what():  boost: mutex lock failed in pthread_mutex_lock: Resource deadlock avoided

status changed

viboes — Tue, 08 Sep 2015 19:41:35 GMT

status reopened → new

status changed

viboes — Fri, 25 Sep 2015 05:46:05 GMT

status new → assigned

code@… — Tue, 06 Oct 2015 01:57:11 GMT

I can look into this if you don't have the time.

viboes — Sat, 10 Oct 2015 15:07:31 GMT

Yes, please. Any help will be welcome, an hint, a trace back, requesting for something you don't understand and find weird.

It would be great if you test with the branch https://github.com/boostorg/thread/tree/feature/make_executors_copyable, which make use of non-blocking futures also.

BTW, what is your name?

code@… — Sat, 10 Oct 2015 21:06:21 GMT

Lee Clagett. I've discussed Futures with you on the mailing list before. Unfortunately my name is after the @ in my email, so it doesn't show here, didn't think about that.

viboes — Sat, 10 Oct 2015 23:51:46 GMT

Glad to meet you Lee.

status changed; resolution set

viboes — Sun, 15 Nov 2015 00:00:44 GMT

status assigned → closed
resolution → fixed

It seems that https://github.com/boostorg/thread/commit/60a8cb9b5c69423ee0bea403cacc971606575f01 fixes it.

I don't see anymore the errors.

code@… — Sun, 15 Nov 2015 03:06:36 GMT

I noticed that too. Looks like this is going to be a fun one.

I tried to recreate this issue on OSX (closest to FreeBSD I had), but no luck. And Clang's tsan isn't supported on OSX, at least on my version. I now have a FreeBSD VM, but I just found out that tsan isn't supported on this platform either! I'll run the tests on this system anyway, before moving to one my Linux systems with tsan. After that its begging Flast to do some investigating for me with some code auditing on the side.

code@… — Sun, 15 Nov 2015 03:07:47 GMT

Oh, and is it possible that he had a bad build? I feel like that may have happened on one of his systems, I'll try to ask him that ASAP.

Thu, 06 Jul 2017 06:46:05 GMT

I’ve encountered a similar problem while using deferred continuations (see https://stackoverflow.com/questions/44748568/boostfuture-deferred-continuation-unwrapping-deadlocks).

#define BOOST_THREAD_VERSION 5
#include <iostream>
#include <boost/thread/future.hpp>
int main(int argc, char* argv[])
{
    boost::promise<int> promise;
    boost::future<int> future = promise.get_future();
    promise.set_value(42);
    int result = future.then(
        boost::launch::deferred,
        [](boost::future<int> result)
        {
            return boost::make_ready_future(result.get());
        }
    ).unwrap().get();
    std::cout << "Result is: " << result << std::endl;
    return 0;
}

This code causes a deadlock. If the launch policy is replaced by boost::launch::async, it works as intended.

status changed; resolution deleted

Thu, 06 Jul 2017 06:46:54 GMT

status closed → reopened
resolution fixed

cc set

Thu, 06 Jul 2017 06:48:11 GMT

cc contact@… added

viboes — Sun, 27 Aug 2017 19:49:00 GMT

@Matteo Please, create a new issue, as the case you are describing is different than the original one.

viboes — Mon, 28 Aug 2017 04:38:09 GMT

See "VS 2017.4 Preview deadlocks on Test 10964" https://github.com/boostorg/thread/issues/132

viboes — Mon, 28 Aug 2017 05:01:53 GMT

Matteo, could you try with

#define BOOST_THREAD_VERSION 4

Version 5 has not been delivered officially.

The main difference of version 5 would be that BOOST_THREAD_ASYNC_FUTURE_WAITS is not defined (BOOST_THREAD_FUTURE_BLOCKING neither).

          ~future_async_shared_state_base()
          {
#ifdef BOOST_THREAD_FUTURE_BLOCKING
            join();
#elif defined BOOST_THREAD_ASYNC_FUTURE_WAITS
            unique_lock<boost::mutex> lk(this->mutex);
            while(!this->done)
            {
              this->waiters.wait(lk);
            }
#endif
          }

but I have no tested it too much. It seems that there are some big implications.

status changed; resolution set

viboes — Mon, 28 Aug 2017 05:05:56 GMT

status reopened → closed
resolution → fixed