asio socket-> connect callの後でGDBブレークポイントが機能しなくなる

Question

私はWindowsでEclipse + Mingw + Boostを使用しています。

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正しく私ができる安全に単一のステップに私のコードのすべての方法まで、メインの内側に停止します。デバッガはEclipseで、このコードフラグメントになったとき

私が持っている問題が表示されますsocket-> connectの呼び出しの後、私は実行の制御をすべて失い、プログラムは終了するまで実行を続けます。この行の後のすべてのブレークポイントは完全に無視されます。私はgdbログに有用なエラーメッセージが表示されません。

私はMingw、Boost、Eclipseの最新バージョンを使用しています。私は自分のコードをコンパイルし、デバッグシンボルを有効にして、同じコンパイラを使ってブーストしました。

編集：私はブーストコードを通して安全に通話することもできます。したがって、gdbがより低レベルのシステムコールを取得するときに問題が発生すると確信しています。

Answer 1

問題は当面解決されたようです。 WindowsのEclipseでgdbを使ってデバッグする他の貧しい人々の役に立つヒント：

1）（Watch）式には注意が必要です。 gdbはすべてのステップでこれらを解釈しようとしているようです。ここで間違った値を指定すると、非常に不安定なデバッグ経験ができます。

2）印刷には注意してください。私の場合、gdbログを見ると、実際にはgdbが必要なブレークポイントで停止することに気付きましたが、Eclipseは反応しません。この問題は、gdbから出力された情報が、gdbの出力に何らかの形で出力されていることが原因です。これは、Eclipseがgdbから情報を取得する方法で、ブレークポイントが実際にヒットしたことを理解できず、

3）あまり足を踏み入れないでください。特にsocket-> connectとexceptionの呼び出しより。

Answer 2

2）印刷には注意してください。私の場合、gdb のログを見ると、gdbは実際には必要なブレークポイント、つまり で停止しますが、Eclipseは反応しないことに気付きました。問題は私のcoutの出力がどうにかしてがgdbの出力に表示されてしまったことです。これはEclipseがgdbから の情報を取得する方法であり、実際にヒットしたことを理解できませんでした。

これは私にとっては問題でした。set new-console onを.gdbinitに入れて固定しました。