Question

我在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-＆gt; connect调用，之后我放松了对执行的所有控制并且程序继续执行直到退出此行之后的所有断点都将被完全忽略。我在gdb日志中看不到有用的错误消息。

我使用的是Mingw，Boost和Eclipse的最新版本。我已经编译了我的代码并使用相同的编译器进行了增强，两者都启用了调试符号。

编辑：我也可以安全地通过升级代码进入调用，因此我确信当gdb进入更低级别的系统调用时会出现问题。

Answer 1

这个问题似乎暂时得到了解决。在Windows下的Eclipse中使用gdb调试其他可怜的灵魂的有用提示：

1）对（观看）表达非常小心。似乎gdb试图在每一步都解释这些。在这里提供错误的值，您将获得非常不稳定的调试体验。

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

3）尽量不要做太多踩踏。特别是在socket-＆gt;连接和异常调用上。

Answer 2

2）小心打印。就我而言，通过查看gdb 日志，我注意到gdb确实停在了所需的断点处，但Eclipse没有反应。问题是我的cout输出不知何故在gdb输出中打印，因为这是Eclipse检索的方式来自gdb的信息，它无法理解断点是什么实际上是打了，只是永远等在那里。

这也是我的问题 - 将set new-console on放入.gdbinit为我修复它。

在asio socket-＆gt; connect调用之后，GDB断点停止工作

2 个答案: