在 asio socket->connect 调用后 GDB 断点停止工作答案

【问题标题】：GDB breakpoints stop working after asio socket->connect call在 asio socket->connect 调用后 GDB 断点停止工作
【发布时间】：2010-12-30 12:12:48
【问题描述】：

我在 Windows 上使用 Eclipse + Mingw + Boost。

当调试器在 Eclipse 中访问此代码片段时出现我遇到的问题：

int YarpInterface::connect_to_port(std::string ip, std::string port, tcp::socket* socket)
{    
    boost::asio::io_service io_service;
    tcp::resolver resolver(io_service);
    tcp::resolver::query query(boost::asio::ip::tcp::v4(), ip, port);
    tcp::resolver::iterator endpoint_iterator = resolver.resolve(query);
    tcp::resolver::iterator end;
    boost::system::error_code error = boost::asio::error::host_not_found;

    while (error && endpoint_iterator != end)
    {
       socket->close();
       socket->connect(*endpoint_iterator++, error);
    }
    if (error)
    {
       throw boost::system::system_error(error);
    }
    return true;
}

当我开始调试时，gdb 在 main 中正确停止，我可以安全地单步执行我的代码，直到 socket->connect 调用，之后我失去了对执行的所有控制，程序继续执行直到它退出。此行之后的所有断点都将被完全忽略。我在 gdb 日志中看不到有用的错误消息。

我正在使用最新版本的 Mingw、Boost 和 Eclipse。我已经使用同一个编译器编译了我的代码和 boost，都启用了调试符号。

编辑：我也可以安全地通过 boost 代码一路进入调用，因此我非常确信当 gdb 进入更底层的系统调用时会出现问题。

【问题讨论】：

你在构建 boost 时给了 bjam 什么论据？
这些：--address-model=32 variant=debug --debug-symbols=on --toolset=gcc
需要考虑的一些事情：您是否使用异步connect？如果没有，调用connect 的线程可能被阻塞了。当时是否有其他线程处于活动状态（未阻塞）？
我这里是故意使用同步连接的，我觉得这样更简单。只有一个活动线程确实被阻塞了，但是当它被释放时，执行继续，但断点不起作用。

标签： c++ gdb mingw eclipse-cdt boost-asio

【解决方案1】：

问题似乎暂时解决了。 Windows 下 Eclipse 中使用 gdb 调试其他可怜人的有用提示：

1) 非常小心 (Watch) 表达式。似乎 gdb 试图在每一步都解释这些。在此处提供错误的值，您将获得非常不稳定的调试体验。

2) 小心打印。在我的例子中，通过查看 gdb 日志，我注意到 gdb 实际上确实在所需的断点处停止，但 Eclipse 没有反应。问题是我的 cout 输出以某种方式打印在 gdb 输出中，因为这是 Eclipse 从 gdb 检索信息的方式，它无法理解断点实际上已被命中，并且永远在那里等待。

3) 尽量不要做太多的踩踏。特别是通过 socket->connect 和异常调用。

【讨论】：

【解决方案2】：

2) 小心打印。就我而言，通过查看 gdb 日志，我注意到 gdb 实际上确实在所需的断点处停止，但 Eclipse 没有反应。问题是我的 cout 以某种方式输出打印在 gdb 输出中，因为这是 Eclipse 检索的方式来自 gdb 的信息，它无法理解断点是真的命中了，然后就一直等在那里。

这也是我的问题 - 将 set new-console on 放入 .gdbinit 为我解决了这个问题。

【讨论】：