Question

我有一个多线程应用程序，它通过 boost :: asio 中的集成使用 boost :: asio 和 boost :: coroutine 。每个线程都有自己的 io_service 对象。线程之间唯一的共享状态是连接池，当从连接池获取连接或从连接池返回连接时，连接池被互斥锁锁定。当池中没有足够的连接时，我在池的内部结构中推送无限的 asio :: steady_tiemer ，并异步地等待它，并且我从couroutine函数中屈服。当其他线程返回到池的连接时，它检查是否有等待计时器，它从内部结构获取等待计时器，它获取其 io_service 对象并发布一个lambda，它唤醒计时器以恢复暂停协程。我在应用程序中随机崩溃。我尝试用 valgrind 调查问题。它发现了一些问题，但我无法理解它们，因为它们发生在 boost :: coroutine 和 boost :: asio 内部。这是来自我的代码和 valgrind 输出的片段。有人能看到并解释这个问题吗？

这是调用代码：

template <class ContextsType>
void executeRequests(ContextsType& avlRequestContexts)
{
    AvlRequestDataList allRequests;
    for(auto& requestContext : avlRequestContexts)
    {
        if(!requestContext.pullProvider || !requestContext.toAskGDS())
            continue;

        auto& requests = requestContext.pullProvider->getRequestsData();
        copy(requests.begin(), requests.end(), back_inserter(allRequests));
    }

    if(allRequests.size() == 0)
        return;

    boost::asio::io_service ioService;
    curl::AsioMultiplexer multiplexer(ioService);

    for(auto& request : allRequests)
    {
        using namespace boost::asio;

        spawn(ioService, [&multiplexer, &request](yield_context yield)
        {
            request->prepare(multiplexer, yield);
        });
    }

    while(true)
    {
        try
        {
            VLOG_DEBUG(avlGeneralLogger, "executeRequests: Starting ASIO event loop.");
            ioService.run();
            VLOG_DEBUG(avlGeneralLogger, "executeRequests: ASIO event loop finished.");
            break;
        }
        catch(const std::exception& e)
        {
            VLOG_ERROR(avlGeneralLogger, "executeRequests: Error while executing GDS request: " << e.what());
        }
        catch(...)
        {
            VLOG_ERROR(avlGeneralLogger, "executeRequests: Unknown error while executing GDS request.");
        }
    }
}

这是prepare函数实现，它在生成的lambda中调用：

void AvlRequestData::prepareImpl(curl::AsioMultiplexer& multiplexer,
                                 boost::asio::yield_context yield)
{
    auto& ioService = multiplexer.getIoService();
    _connection = _pool.getConnection(ioService, yield);
    _connection->prepareRequest(xmlRequest, xmlResponse, requestTimeoutMS);

    multiplexer.addEasyHandle(_connection->getHandle(),
                              [this](const curl::EasyHandleResult& result)
    {
        if(0 == result.responseCode)
            returnQuota();
        VLOG_DEBUG(lastSeatLogger, "Response " << id << ": " << xmlResponse);
        _pool.addConnection(std::move(_connection));
    });
}


void AvlRequestData::prepare(curl::AsioMultiplexer& multiplexer,
                             boost::asio::yield_context yield)
{
    try
    {
        prepareImpl(multiplexer, yield);
    }
    catch(const std::exception& e)
    {
        VLOG_ERROR(lastSeatLogger, "Error wile preparing request: " << e.what());
        returnQuota();
    }
    catch(...)
    {
        VLOG_ERROR(lastSeatLogger, "Unknown error while preparing request.");
        returnQuota();
    }
}

returnQuota函数是AvlRequestData类的纯虚方法，我在所有测试中使用的TravelportRequestData类的实现如下：

void returnQuota() const override
{
    auto& avlQuotaManager = AvlQuotaManager::getInstance();
    avlQuotaManager.consumeQuotaTravelport(-1);
}

以下是连接池的推送和 pop 方法。

auto AvlConnectionPool::getConnection(
        TimerPtr timer,
        asio::yield_context yield) -> ConnectionPtr
{
    lock_guard<mutex> lock(_mutex);

    while(_connections.empty())
    {
        _timers.emplace_back(timer);
        timer->expires_from_now(
            asio::steady_timer::clock_type::duration::max());

        _mutex.unlock();
        coroutineAsyncWait(*timer, yield);
        _mutex.lock();
    }

    ConnectionPtr connection = std::move(_connections.front());
    _connections.pop_front();

    VLOG_TRACE(defaultLogger, str(format("Getted connection from pool: %s. Connections count %d.")
                                  % _connectionPoolName % _connections.size()));

    ++_connectionsGiven;

    return connection;
}

void AvlConnectionPool::addConnection(ConnectionPtr connection,
                                      Side side /* = Back */)
{
    lock_guard<mutex> lock(_mutex);

    if(Front == side)
        _connections.emplace_front(std::move(connection));
    else
        _connections.emplace_back(std::move(connection));

    VLOG_TRACE(defaultLogger, str(format("Added connection to pool: %s. Connections count %d.")
                                  % _connectionPoolName % _connections.size()));

    if(_timers.empty())
        return;

    auto timer = _timers.back();
    _timers.pop_back();

    auto& ioService = timer->get_io_service();
    ioService.post([timer](){ timer->cancel(); });

    VLOG_TRACE(defaultLogger, str(format("Connection pool %s: Waiting thread resumed.")
                                  % _connectionPoolName));
}

这是 coroutineAsyncWait 的实现。

inline void coroutineAsyncWait(boost::asio::steady_timer& timer,
                               boost::asio::yield_context yield)
{
    boost::system::error_code ec;
    timer.async_wait(yield[ec]);
    if(ec && ec != boost::asio::error::operation_aborted)
        throw std::runtime_error(ec.message());
}

最后 valgrind 输出的第一部分：

== 8189 ==主题41：
  == 8189 ==读取大小为8的无效   == 8189 ==在0x995F84：void boost :: coroutines :: detail :: trampoline_push_void，void，boost :: asio :: detail :: coro_entry_point，void（anonymous namespace）:: executeRequests＆gt; ＆gt;（std :: vector＆lt;（匿名命名空间）:: AvlRequestContext，std :: allocator＆lt;（匿名命名空间）:: AvlRequestContext＆gt;＆gt;＆amp;）:: {lambda（boost :: asio :: basic_yield_context＆gt;）＃ 1}＆gt;＆amp;，boost :: coroutines :: basic_standard_stack_allocator＆gt; ＆gt;（长）（trampoline_push.hpp：65）
  == 8189 ==地址0x2e3b5528不是堆栈＆＃39; d，malloc＆d; dd或（最近）免费＆＃39; d

当我使用附带调试器的 valgrind 时，它会在 boost :: coroutine 库中的 trampoline_push.hpp 中的以下函数中停止。

53│ template< typename Coro >
54│ void trampoline_push_void( intptr_t vp)
55│ {
56│     typedef typename Coro::param_type   param_type;
57│
58│     BOOST_ASSERT( vp);
59│
60│     param_type * param(
61│         reinterpret_cast< param_type * >( vp) );
62│     BOOST_ASSERT( 0 != param);
63│
64│     Coro * coro(
65├>        reinterpret_cast< Coro * >( param->coro) );
66│     BOOST_ASSERT( 0 != coro);
67│
68│     coro->run();
69│ }

Answer 1

最终我发现当需要删除对象时，boost :: asio在没有正确使用shared_ptr和weak_ptr的情况下不会优雅地处理它。当崩溃发生时，它们很难调试，因为很难查看失败时io_service队列正在做什么。

在最近完成一个完整的异步客户端架构并遇到随机崩溃问题后，我提供了一些提示。不幸的是，我不知道这些是否会解决你的问题，但希望它能为你正确的方向提供良好的开端。

提升Asio Coroutine使用技巧

使用boost :: asio :: asio_handler_invoke而不是io_service.post（）：

自动＆安培; ioService = timer-＆gt; get_io_service（）;

ioService.post（timer {timer-＆gt; cancel（）;}）;

在协程中使用post / dispatch通常是个坏主意。从协程调用时，始终使用asio_handler_invoke。但是，在这种情况下，您可以安全地调用timer->cancel()，而无需将其发布到消息循环中。
您的计时器似乎没有使用shared_ptr对象。无论应用程序的其余部分发生了什么，都无法确定何时应该销毁这些对象。我强烈建议对所有计时器对象使用shared_ptr对象。此外，任何指向类方法的指针也应该使用shared_from_this()。如果this被破坏（在堆栈上）或超出shared_ptr中的其他位置，则使用普通this会非常危险。无论你做什么，都不要在对象的构造函数中使用shared_from_this()！

如果在执行io_service中的处理程序时遇到崩溃，但处理程序的一部分不再有效，则调试非常困难。泵入io_service的处理程序对象包括指向计时器的任何指针，或指向执行处理程序可能需要的对象的指针。

我强烈建议过度使用包含在任何asio类中的shared_ptr对象。如果问题消失，那么可能是破坏问题的顺序。
堆上的故障地址位置是某处还是指向堆栈？这将帮助您在错误的时间诊断其对象是否超出方法范围，或者是否为其他内容。例如，这向我证明，即使在单线程应用程序中，我的所有计时器也必须成为shared_ptr对象。

导致boost :: coroutine随机崩溃的原因是什么？

1 个答案:

提升Asio Coroutine使用技巧