1

我有一个多线程应用程序，它通过在 boost::asio 中的集成使用boost :: asio和boost::coroutine。每个线程都有自己的io_service对象。线程之间唯一共享的状态是连接池，当连接从/返回到连接池时被互斥锁锁定。当池中没有足够的连接时，我将无限asio::steady_tiemer推送到池的内部结构中并异步等待它，然后我从 couroutine 函数中让步。当其他线程返回连接池时，它会检查是否有等待定时器，它从内部结构中获取等待定时器，它获取它的io_service对象并发布一个 lambda，该 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);
}

这里是连接池的push和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 (匿名命名空间)::executeRequests > >(std::vector<(匿名命名空间)::AvlRequestContext, std::allocator<(匿名命名空间)::AvlRequestContext> >&)::{lambda(boost::asio ::basic_yield_context >)#1}>&, boost::coroutines::basic_standard_stack_allocator > >(long) (trampoline_push.hpp:65)
==8189== 地址 0x2e3b5528 不是 stack'd, malloc'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├&gt;        reinterpret_cast< Coro * >( param->coro) );
66│     BOOST_ASSERT( 0 != coro);
67│
68│     coro->run();
69│ }
4

1 回答 1

2

最终我发现当需要删除对象时，如果没有正确使用 shared_ptr 和weak_ptr，boost::asio 并不能优雅地处理它。当确实发生崩溃时，它们很难调试，因为很难查看 io_service 队列在发生故障时正在做什么。

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

Boost Asio Coroutine 使用技巧

  1. 使用 boost::asio::asio_handler_invoke 而不是 io_service.post()：

    auto& ioService = timer->get_io_service();

    ioService.post(timer{ timer->cancel(); });

    在协程中使用 post/dispatch 通常是个坏主意。当您从协程调用时，请始终使用 asio_handler_invoke。但是，在这种情况下，您可能可以安全地调用timer->cancel()而无需将其发布到消息循环中。

  2. 您的计时器似乎没有使用 shared_ptr 对象。无论您的应用程序的其余部分发生了什么，都无法确定何时应该销毁这些对象。我强烈建议对所有计时器对象使用 shared_ptr 对象。此外，任何指向类方法的指针也应该使用shared_from_this()。如果被破坏（在堆栈上）或超出 shared_ptr 中其他地方的范围，则使用纯文本this可能非常危险。this无论你做什么，都不要shared_from_this()在对象的构造函数中使用！

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

    我强烈建议在任何 asio 类周围使用 shared_ptr 对象。如果问题消失，则可能是破坏顺序问题。

  3. 堆上的故障地址位置是在某个地方还是指向堆栈？这将帮助您诊断其对象是否在错误的时间超出了方法的范围，或者是否是其他对象。例如，这向我证明，即使在单线程应用程序中，我的所有计时器都必须成为 shared_ptr 对象。
于 2015-08-13T18:46:39.503 回答