[Converted from Gnats 1862] The gdb debugger cannot establish a connection to the remote gdbserver if the server has attached to a running process. Release: 6.3 Environment: Fedora Core Linux How-To-Repeat: Build the following C++ code with debug information as program named "log2": #include <iostream> #include <math.h> int main() { using std::cout; cout << "Please enter a positive numeric value: "; float fValue; std::cin >> fValue; float fResult = ::log(fValue ) / ::log(2.0f); cout << "The base 2 logarithm for that value is " << fResult << ".\n"; return 0; } From a terminal launch the log2 program in the background Run "gdbserver host:1234 --attach <PID>" where PID is the process identifier for the log2 background program From another terminal on the same machine execute "gdb log2" From within gdb execute "target remote 127.0.0.1:1234" Results: Connect is refused from the server Expected: The connection should be accepted. The connection would have been accept if the log2 program had been run directly from the gdbserver with the command such as "gdbserver host:1234 log2"
The description of the bug is a bit misleading. What is really happening, is that: >From a terminal launch the log2 program in the background ... this doesn't really leave the log2 program running. Since log2 is trying to read from stdin, when you try to put it in the background, it is immediately left stopped: >../log2 & Please enter a positive numeric value: [1] 3669 [1]+ Stopped ../log2 [pedro@orlando][~/gdb/baseline/build/gdb/gdbserver] >bg [1]+ ../log2 & [1]+ Stopped ../log2 >head /proc/3669/status Name: log2 State: T (stopped) gdbserver doesn't have support for attaching to stopped processes (yet), so the attaching never completes successfully, and the socket is never open. (Native GDB debugging just recently got support for attaching to stopped processes.) If you instead launched log2 in the foreground in another terminal, gdbserver would be able to attach successfully, and GDB would be able to connect to it.
I've checked in a patch.