GDB breakpoints stop working after asio socket->connect call

I am using Eclipse + Mingw + Boost on Windows.

The problem I have appears when the debugger gets to this code fragment in 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;
}

When I start debugging, gdb correctly stops inside the main, I can safely single step my code all the way until the socket->connect invocation, after this I loose all control over the execution and the program just continues to execute until it exits. All breakpoints after this line are ignored completely. I see no useful error messages in the gdb logs.

I am using the latest version of Mingw, Boost and Eclipse. I have compiled my code and boost using the same compiler, both with debug symbols enabled.

Edit: I can also step into the call all the way through boost code safely, therefore I am quite convinced that the problem occurs when gdb gets to the more low level system calls.

Answers


The issue seems to be resolved for the time being. Useful tips for other poor souls debugging with gdb in Eclipse under Windows:

1) Be VERY careful about (Watch) Expressions. It seems that gdb tries to interpret these on every step. Provide wrong values here and you'll have a very unstable debugging experience.

2) Be careful with your printing. In my case, by looking at the gdb logs, I noticed that gdb does in fact stop at the required breakpoint, but Eclipse does not react. The issue was that my cout output somehow got printed in the gdb output, as this is how Eclipse retrieves information from gdb, it could not understand that the breakpoint was actually hit, and just waited there forever.

3) Try not to do too much stepping. Especially over socket->connect and exception calls.


2) Be careful with your printing. In my case, by looking at the gdb logs, I noticed that gdb does in fact stop at the required breakpoint, but Eclipse does not react. The issue was that my cout output somehow got printed in the gdb output, as this is how Eclipse retrieves information from gdb, it could not understand that the breakpoint was actually hit, and just waited there forever.

This was also the issue for me - putting set new-console on into .gdbinit fixed it for me.


Need Your Help

Where does this deadlock hide?

c multithreading pthreads deadlock

I'm actually writing an MPI program. This is a basic client / server pattern. The server have a set of work to compute. The clients get subsets of this big set. Each client use several threads to c...

What are the generic ways to make Reporting Services faster

c# optimization reporting-services

While I understand this question is fairly vague since I'm not giving you all as much detail as I'd like to, I'm hoping for some general improvements that can be made to my generation code or the r...

About UNIX Resources Network

Original, collect and organize Developers related documents, information and materials, contains jQuery, Html, CSS, MySQL, .NET, ASP.NET, SQL, objective-c, iPhone, Ruby on Rails, C, SQL Server, Ruby, Arrays, Regex, ASP.NET MVC, WPF, XML, Ajax, DataBase, and so on.