core dumps when destructing ContinuatioTaskHandle

Anybody had observed the following core dump when using the library along with azure storage sdk?
Thread 21 "test_azure" received signal SIGTRAP, Trace/breakpoint trap.
[Switching to Thread 0x7fffe8e6a700 (LWP 6014)]
0x00007ffff7bcb269 in raise (sig=5) at ../sysdeps/unix/sysv/linux/pt-raise.c:35
35 ../sysdeps/unix/sysv/linux/pt-raise.c: No such file or directory.
(gdb) bt
#0 0x00007ffff7bcb269 in raise (sig=5) at ../sysdeps/unix/sysv/linux/pt-raise.c:35
#1 0x00000000004d09b4 in pplx::details::_ExceptionHolder::~_ExceptionHolder (this=0x7a6c20, __in_chrg=) at /usr/local/include/pplx/pplxtasks.h:965
#2 0x00000000004f8a32 in __gnu_cxx::new_allocatorpplx::details::_ExceptionHolder::destroypplx::details::_ExceptionHolder (this=0x7a6c20, __p=0x7a6c20)
at /usr/include/c++/5/ext/new_allocator.h:124
#3 0x00000000004f361f in std::allocator_traits<std::allocatorpplx::details::_ExceptionHolder >::destroypplx::details::_ExceptionHolder (__a=..., __p=0x7a6c20)
at /usr/include/c++/5/bits/alloc_traits.h:542
#4 0x00000000004eae87 in std::_Sp_counted_ptr_inplace<pplx::details::_ExceptionHolder, std::allocatorpplx::details::_ExceptionHolder, (__gnu_cxx::_Lock_policy)2>::_M_dispose (this=0x7a6c10) at /usr/include/c++/5/bits/shared_ptr_base.h:531
#5 0x00000000004da364 in std::_Sp_counted_base<(__gnu_cxx::_Lock_policy)2>::_M_release (this=0x7a6c10) at /usr/include/c++/5/bits/shared_ptr_base.h:150
#6 0x00000000004d639f in std::__shared_count<(__gnu_cxx::_Lock_policy)2>::~__shared_count (this=0x7fffc801b5c8, __in_chrg=)
at /usr/include/c++/5/bits/shared_ptr_base.h:659
#7 0x00000000004d0ff0 in std::__shared_ptr<pplx::details::_ExceptionHolder, (__gnu_cxx::_Lock_policy)2>::~__shared_ptr (this=0x7fffc801b5c0, __in_chrg=)
at /usr/include/c++/5/bits/shared_ptr_base.h:925
#8 0x00000000004d1028 in std::shared_ptrpplx::details::_ExceptionHolder::~shared_ptr (this=0x7fffc801b5c0, __in_chrg=)
at /usr/include/c++/5/bits/shared_ptr.h:93
#9 0x00000000004d126c in pplx::details::_Task_impl_base::~_Task_impl_base (this=0x7fffc801b5b0, __in_chrg=) at /usr/local/include/pplx/pplxtasks.h:1729
#10 0x00000000004f306e in pplx::details::_Task_impl::~_Task_impl (this=0x7fffc801b5b0, __in_chrg=)
at /usr/local/include/pplx/pplxtasks.h:2432
#11 0x00000000004f89a9 in __gnu_cxx::new_allocator<pplx::details::_Task_impl >::destroy<pplx::details::_Task_impl > (this=0x7fffc801b5b0,
__p=0x7fffc801b5b0) at /usr/include/c++/5/ext/new_allocator.h:124
#12 0x00000000004f355f in std::allocator_traits<std::allocator<pplx::details::_Task_impl > >::destroy<pplx::details::_Task_impl > (__a=...,
__p=0x7fffc801b5b0) at /usr/include/c++/5/bits/alloc_traits.h:542
#13 0x00000000004ea97d in std::_Sp_counted_ptr_inplace<pplx::details::_Task_impl, std::allocator<pplx::details::_Task_impl >, (__gnu_cxx::_Lock_policy)2>::_M_dispose (this=0x7fffc801b5a0) at /usr/include/c++/5/bits/shared_ptr_base.h:531
#14 0x00007ffff6a86732 in pplx::task::_ContinuationTaskHandle<void, void, azure::storage::cloud_blob::download_range_to_stream_async(Concurrency::streams::basic_ostream, unsigned long, unsigned long, azure::storage::access_condition const&, azure::storage::blob_request_options const&, azure::storage::operation_context)::{lambda(pplx::task)#1}::operator()(pplx::task) const::{lambda()#1}::operator()() const::{lambda()#1}::operator()() const::{lambda(pplx::task)#1}, std::integral_constant<bool, true>, pplx::details::_TypeSelectorNoAsync>::~_ContinuationTaskHandle() () from /usr/local/lib/libazurestorage.so.5
#15 0x00000000004d6ae5 in pplx::details::_AutoDeleterpplx::details::_TaskProcHandle::~_AutoDeleter (this=0x7fffe8e69bb0, __in_chrg=)
at /usr/local/include/pplx/pplx.h:99
#16 0x00000000004d03b6 in pplx::details::_TaskProcHandle::_RunChoreBridge (_Parameter=0x7fffc801b6c0) at /usr/local/include/pplx/pplx.h:115
#17 0x00007ffff76e25c2 in boost::asio::detail::completion_handler<boost::_bi::bind_t<void, void ()(void), boost::_bi::list1<boost::_bi::value<void*> > > >::do_complete(boost::asio::detail::task_io_service*, boost::asio::detail::task_io_service_operation*, boost::system::error_code const&, unsigned long) ()
from /usr/local/lib/libcpprest.so.2.10
#18 0x00007ffff76e3921 in boost::asio::detail::posix_thread::func<(anonymous namespace)::threadpool_impl::add_thread()::{lambda()#1}>::run() ()
from /usr/local/lib/libcpprest.so.2.10
#19 0x00007ffff7669284 in boost_asio_detail_posix_thread_function () from /usr/local/lib/libcpprest.so.2.10
#20 0x00007ffff7bc16ba in start_thread (arg=0x7fffe8e6a700) at pthread_create.c:333
#21 0x00007ffff5dfe41d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:109
(gdb)

I can consistently reproduce the crash.

Any hints where I should look would be highly appreciated.

Thanks,

Yang

A SIGTRAP usually means that you encounter an exception inside a pplx::task<> but don't act on it. Anytime something returns a pplx::task() you need to make sure that you eventually collect the result of this task via pplx::task<>::get(). This .get() will block until the task finishes and then either return the task's result or throw the exception that was encountered while running the task.

If a task that contains an exception is destructed without anybody having called .get() on it, your program will receive SIGTRAP. If you look at your call stack you will find evidence that exactly this happened to you:

#0 0x00007ffff7bcb269 in raise (sig=5) at ../sysdeps/unix/sysv/linux/pt-raise.c:35
#1 0x00000000004d09b4 in pplx::details::_ExceptionHolder::~_ExceptionHolder (this=0x7a6c20, __in_chrg=) at /usr/local/include/pplx/pplxtasks.h:965
#2 0x00000000004f8a32 in __gnu_cxx::new_allocatorpplx::details::_ExceptionHolder::destroypplx::details::_ExceptionHolder (this=0x7a6c20, __p=0x7a6c20)
[...]

For example:

    // this task contains an exception!
    pplx::task<int> task =
        pplx::create_task([]() -> int { return 42; })
        .then([](int i) -> int {
            if (i == 42) {
                // this will (rather silently) throw an exception and 
                // store it as the task's result ...
                throw std::runtime_error("this answer is too generic");
            } else {
                return i + 1;
            }
        });

    try {
        // ... here the exception resurfaces and we can act on it
        std::cout << task.get() << std::endl;
    } catch (const std::exception &ex) {
        std::cout << "Whoops! " << ex.what() << std::endl;
    }

I hope that helps.

Navigation Menu

Repository navigation

core dumps when destructing ContinuatioTaskHandle #944

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

core dumps when destructing ContinuatioTaskHandle #944

Description

Activity

reneme commented on Nov 7, 2018

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions