Re: gdb refuses to connect to localhost

[Reinaldo Molina <me@molinamail.com>]

Thanks for the quick reply. 

Trying your suggestion: 

Terminal 1:

    gdbserver 127.0.01:8889 build/luajit --remote-debug

Terminal 2:

    > gdb build/luajit
    GNU gdb (GDB) 10.1
    Copyright (C) 2020 Free Software Foundation, Inc.
    License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
    This is free software: you are free to change and redistribute it.
    There is NO WARRANTY, to the extent permitted by law.
    Type "show copying" and "show warranty" for details.
    This GDB was configured as "x86_64-pc-linux-gnu".
    Type "show configuration" for configuration details.
    For bug reporting instructions, please see:
    <https://www.gnu.org/software/gdb/bugs/>.
    Find the GDB manual and other documentation resources online at:
        <http://www.gnu.org/software/gdb/documentation/>.

    For help, type "help".
    Type "apropos word" to search for commands related to "word"...
    Reading symbols from build/luajit...
    (gdb) set debug remote 1
    (gdb) target remote localhost:8889
    Remote debugging using localhost:8889
    Sending packet: $qSupported:multiprocess+;swbreak+;hwbreak+;qRelocInsn+;fork-events+;vfork-events+;exec-events+;vContSupported+;QThreadEvents+;no-resumed+;xmlRegisters=i386#6a...Sending packet: $qSupported:multiprocess+;swbreak+;hwbreak+;qRelocInsn+;fork-events+;vfork-events+;exec-events+;vContSupported+;QThreadEvents+;no-resumed+;xmlRegisters=i386#6a...Sending packet: $qSupported:multiprocess+;swbreak+;hwbreak+;qRelocInsn+;fork-events+;vfork-events+;exec-events+;vContSupported+;QThreadEvents+;no-resumed+;xmlRegisters=i386#6a...Sending packet: $qSupported:multiprocess+;swbreak+;hwbreak+;qRelocInsn+;fork-events+;vfork-events+;exec-events+;vContSupported+;QThreadEvents+;no-resumed+;xmlRegisters=i386#6a...Timed out.
    Timed out.
    Timed out.
    Ignoring packet error, continuing...
    Packet qSupported (supported-packets) is supported
    warning: unrecognized item "timeout" in "qSupported" response
    Sending packet: $vMustReplyEmpty#3a...Sending packet: $vMustReplyEmpty#3a...Sending packet: $vMustReplyEmpty#3a...Sending packet: $vMustReplyEmpty#3a...Timed out.
    Timed out.
    Timed out.
    Ignoring packet error, continuing...
    Remote replied unexpectedly to 'vMustReplyEmpty': timeout
    (gdb) target remote 0.0.0.0:8889
    Remote debugging using 0.0.0.0:8889
    Sending packet: $qSupported:multiprocess+;swbreak+;hwbreak+;qRelocInsn+;fork-events+;vfork-events+;exec-events+;vContSupported+;QThreadEvents+;no-resumed+;xmlRegisters=i386#6a...Sending packet: $qSupported:multiprocess+;swbreak+;hwbreak+;qRelocInsn+;fork-events+;vfork-events+;exec-events+;vContSupported+;QThreadEvents+;no-resumed+;xmlRegisters=i386#6a...Sending packet: $qSupported:multiprocess+;swbreak+;hwbreak+;qRelocInsn+;fork-events+;vfork-events+;exec-events+;vContSupported+;QThreadEvents+;no-resumed+;xmlRegisters=i386#6a...Sending packet: $qSupported:multiprocess+;swbreak+;hwbreak+;qRelocInsn+;fork-events+;vfork-events+;exec-events+;vContSupported+;QThreadEvents+;no-resumed+;xmlRegisters=i386#6a...Timed out.
    Timed out.
    Timed out.
    Ignoring packet error, continuing...
    Packet qSupported (supported-packets) is supported
    warning: unrecognized item "timeout" in "qSupported" response
    Sending packet: $vMustReplyEmpty#3a...Sending packet: $vMustReplyEmpty#3a...Sending packet: $vMustReplyEmpty#3a...Sending packet: $vMustReplyEmpty#3a...Timed out.
    Timed out.
    Timed out.
    Ignoring packet error, continuing...
    Remote replied unexpectedly to 'vMustReplyEmpty': timeout
    (gdb) target remote 127.0.0.1:8889
    127.0.0.1:8889: Connection timed out.


Here is `netstat` again:

    (Not all processes could be identified, non-owned process info
    will not be shown, you would have to be root to see it all.)
    tcp        2      0 0.0.0.0:8889            0.0.0.0:*               LISTEN      356666/gdbserver
    tcp      722      0 127.0.0.1:8889          127.0.0.1:35344         CLOSE_WAIT  -
    tcp      722      0 127.0.0.1:8889          127.0.0.1:35402         CLOSE_WAIT  -
    tcp        0      0 127.0.0.1:35402         127.0.0.1:8889          FIN_WAIT2   -


Thanks,
Reinaldo Molina


On 12-25-20 17:55:19, Simon Marchi wrote:
> 
> 
> On 2020-12-25 5:36 p.m., Reinaldo Molina via Gdb wrote:
> > Hey guys!
> > 
> > Looking for some assistants here. I am trying to debug an application using `gdbserver`, but it seems my `lo` network device is messed up. `gdb` refuses to connect to `localhost` every time. Here is my flow:
> > 
> > Terminal 1: `gdbserver localhost:8888 build/luajit`
> >   - Variants I've tried: `127.0.0.1:8888`
> > 
> > Terminal 2: `gdb build/luajit -ex 'target remote localhost:8888'`
> > 
> > Output from `gdb` on Terminal 2:
> > 
> >     (gdb) target remote :8888
> >     Remote debugging using :8888
> >     Ignoring packet error, continuing...
> >     warning: unrecognized item "timeout" in "qSupported" response
> >     Ignoring packet error, continuing...
> >     Remote replied unexpectedly to 'vMustReplyEmpty': timeout
> 
> That sounds like you are really connecting to something else than gdbserver.
> 
> > 
> > Output from `ip addr show lo`:
> > 
> >     1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
> >         link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
> >         inet 127.0.0.1/8 scope host lo
> >           valid_lft forever preferred_lft forever
> >         inet6 ::1/128 scope host
> >           valid_lft forever preferred_lft forever
> > 
> > Content from `/etc/hosts`
> > 
> >     # Static table lookup for hostnames.
> >     # See hosts(5) for details.
> >     127.0.0.1	localhost
> >     ::1		localhost
> >     127.0.1.1	myhostname.localdomain	myhostname
> > 
> > I'm using the command to monitor the ports: `netstat -tulanp`. Here is the output right after running just `gdbserver`:
> > 
> >     (Not all processes could be identified, non-owned process info
> >     will not be shown, you would have to be root to see it all.)
> >     tcp        0      0 0.0.0.0:8888            0.0.0.0:*               LISTEN      193337/gdbserver
> > 
> > Output just after telling `gdb` to connect:
> > 
> >     (Not all processes could be identified, non-owned process info
> >     will not be shown, you would have to be root to see it all.)
> >     tcp        1      0 0.0.0.0:8888            0.0.0.0:*               LISTEN      193337/gdbserver
> >     tcp        0      0 127.0.0.1:50720         127.0.0.1:8888          ESTABLISHED 195502/gdb
> >     tcp      478      0 127.0.0.1:8888          127.0.0.1:50720         ESTABLISHED -
> > 
> > Looks promising but then:
> > 
> >     (Not all processes could be identified, non-owned process info
> >     will not be shown, you would have to be root to see it all.)
> >     tcp        1      0 0.0.0.0:8888            0.0.0.0:*               LISTEN      193337/gdbserver
> >     tcp        0      0 127.0.0.1:50720         127.0.0.1:8888          FIN_WAIT2   -
> >     tcp      722      0 127.0.0.1:8888          127.0.0.1:50720         CLOSE_WAIT  -
> 
> I have no clue.  Try "set debug remote 1" in GDB before connecting,
> see what data GDB receives.
> 
> You can also start GDBserver with --remote-debug to see if there
> is some chit chat when GDB connects to it.  If you don't see anything
> here, it's probably because GDB ended up connecting to some other
> program.
> 
> Simon