From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from box.molinamail.com (box.molinamail.com [157.245.10.181]) by sourceware.org (Postfix) with ESMTPS id 69FE2385800D for ; Fri, 25 Dec 2020 23:45:38 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 69FE2385800D Received: from authenticated-user (box.molinamail.com [157.245.10.181]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) (No client certificate requested) by box.molinamail.com (Postfix) with ESMTPSA id B989A7F3A9; Fri, 25 Dec 2020 18:45:37 -0500 (EST) Date: Fri, 25 Dec 2020 18:45:36 -0500 From: Reinaldo Molina To: Simon Marchi Cc: gdb Subject: Re: gdb refuses to connect to localhost Message-ID: <20201225234536.fm6nyuulhw54lhwi@molinamail.com> References: <20201225223622.a7xovhjzndth5a2x@molinamail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, KAM_SHORT, SPF_HELO_PASS, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on server2.sourceware.org X-BeenThere: gdb@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gdb mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Dec 2020 23:45:40 -0000 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 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: . Find the GDB manual and other documentation resources online at: . 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: 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