concurrency::task destructor causes call to abort in valid use-case

Question

Could you please tell me if the approach I use to handle the use-case is invalid and if so, what is the right way to handle:

task<int> do_work(int param)
{
    // runs some work on a separate thread, returns task with result or throws exception on failure
}

void foo()
{
    try
    {
        auto result_1 = do_work(10000);
        auto result_2 = do_work(20000);

        // do some extra work

        process(result_1.get(), result_2.get());
    }
    catch (...)
    {
        // logs the failure details
    }
}

So the code tries to execute two jobs in parallel and then process the results. If one of the jobs throws an exception, then call task::get will re-throw the exception. The issue happens if both tasks throw an exception. In this case the first call to task::get will cause stack unwind, so the destructor of the second task will be called and will in turn cause one more exception to be re-thrown during stack unwind which causes 'abort' to be called.

This approach seemed completely valid to me until I faced with the issue.

Possibly related http://stackoverflow.com/questions/4766768/unhandled-forced-unwind-causes-abort?rq=1 — Cory Kramer, Jul 03 '14 at 16:48
@StackedCrooked... This is actually the main question. Either I get it wrong or `task` destructor really re-throws the exception that was caught in the `do_work` function. — topoden, Jul 03 '14 at 17:32
@Cyber... I do not see how it is related. Could you explain please? — topoden, Jul 03 '14 at 18:24

null · Answer 1 · 2014-07-04T12:24:26.803

In simple words you have an un-handled (unobserved) exception as the exception thrown in one of your tasks does not get caught by the task, one of its continuations, or the main app, because the exception re-thrown from task::get for the first task unwinds the stack before the call to task::get happens for the second task.

A more simplified code shows that std::terminate is called because the exception thrown in the task does not get handled. Uncommenting the result.get() will prevent the call to std::terminate, as task::get will re-throw the exception.

#include <pplx/pplx.h>
#include <pplx/pplxtasks.h>
#include <iostream>

int main(int argc, char* argv[])
{
    try
    {
        auto result = pplx::create_task([] ()-> int
        {
            throw std::exception("task failed");
        });

        // actually need wait here till the exception is thrown, e.g.
        // result.wait(), but this will re-throw the exception making this a valid use-case

        std::cout << &result << std::endl; // use it
        //std::cout << result.get() << std::endl;
    }
    catch (std::exception const& ex)
    {
        std::cout << ex.what() << std::endl;
    }

    return 0;
}

have a look at the suggestion in pplx::details::_ExceptionHandler::~_ExceptionHolder()

//pplxwin.h
#define _REPORT_PPLTASK_UNOBSERVED_EXCEPTION() do { \
    __debugbreak(); \
    std::terminate(); \
} while(false)


//pplxtasks.h
pplx::details::_ExceptionHandler::~_ExceptionHolder()
{
    if (_M_exceptionObserved == 0)
    {
        // If you are trapped here, it means an exception thrown in task chain didn't get handled.
        // Please add task-based continuation to handle all exceptions coming from tasks.
        // this->_M_stackTrace keeps the creation callstack of the task generates this exception.
        _REPORT_PPLTASK_UNOBSERVED_EXCEPTION();
    }
}

In the original code the first call to task::get raises the exception thrown in that task, which obviously prevents the second call to task::get so the exception of the second task does not get handled (remains "unobserved").

the destructor of the second task will be called and will in turn cause one more exception to be re-thrown during stack unwind which causes 'abort' to be called.

The destructor of the second task does not re-throw the exception it just calls std::terminate() (which calls std::abort())

see. Exception Handling in the Concurrency Runtime

I see, thank you. So destructor does not re-throw (which is good), it just calls `std::terminate` (which is actually bad and does not change my question). The question is whether or not it is right to use the approach that I used. I seemed to me that the approach is absolutely valid: user fires several parallel tasks, then later gets their results and processes them. Now I see that it simply will not work if at least two tasks fail... — topoden, Jul 04 '14 at 16:41

concurrency::task destructor causes call to abort in valid use-case

1 Answers1