From unknown Thu Aug 14 18:32:45 2025 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Mailer: MIME-tools 5.509 (Entity 5.509) Content-Type: text/plain; charset=utf-8 From: bug#557 <557@debbugs.gnu.org> To: bug#557 <557@debbugs.gnu.org> Subject: Status: gud/gdb not interacting properly with remote source file Reply-To: bug#557 <557@debbugs.gnu.org> Date: Fri, 15 Aug 2025 01:32:45 +0000 retitle 557 gud/gdb not interacting properly with remote source file reassign 557 emacs submitter 557 vapnik spaknik severity 557 normal thanks From vapniks@yahoo.com Sun Jul 13 19:57:37 2008 X-Spam-Checker-Version: SpamAssassin 3.2.3-bugs.debian.org_2005_01_02 (2007-08-08) on rzlab.ucr.edu X-Spam-Level: X-Spam-Status: No, score=-3.4 required=4.0 tests=BAYES_00,FOURLA,HTML_MESSAGE, RCVD_IN_DNSWL_LOW autolearn=no version=3.2.3-bugs.debian.org_2005_01_02 Received: (at submit) by emacsbugs.donarmstrong.com; 14 Jul 2008 02:57:37 +0000 Received: from lists.gnu.org (lists.gnu.org [199.232.76.165]) by rzlab.ucr.edu (8.13.8/8.13.8/Debian-3) with ESMTP id m6E2vW4w018525 for ; Sun, 13 Jul 2008 19:57:34 -0700 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1KIEFo-0008Nb-Kk for bug-gnu-emacs@gnu.org; Sun, 13 Jul 2008 22:57:32 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1KIEFm-0008Kx-Ut for bug-gnu-emacs@gnu.org; Sun, 13 Jul 2008 22:57:31 -0400 Received: from [199.232.76.173] (port=38048 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1KIEFm-0008KX-N9 for bug-gnu-emacs@gnu.org; Sun, 13 Jul 2008 22:57:30 -0400 Received: from n66.bullet.mail.sp1.yahoo.com ([98.136.44.50]:30338) by monty-python.gnu.org with smtp (Exim 4.60) (envelope-from ) id 1KIEFm-000244-6L for bug-gnu-emacs@gnu.org; Sun, 13 Jul 2008 22:57:30 -0400 Received: from [216.252.122.219] by n66.bullet.mail.sp1.yahoo.com with NNFMP; 14 Jul 2008 02:57:29 -0000 Received: from [69.147.65.172] by t4.bullet.sp1.yahoo.com with NNFMP; 14 Jul 2008 02:57:29 -0000 Received: from [127.0.0.1] by omp507.mail.sp1.yahoo.com with NNFMP; 14 Jul 2008 02:57:29 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 45824.69592.bm@omp507.mail.sp1.yahoo.com Received: (qmail 74005 invoked by uid 60001); 14 Jul 2008 02:57:28 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Received:X-Mailer:Date:From:Subject:To:MIME-Version:Content-Type:Message-ID; b=w3WmuyBQQ2U3SfUjonHVtTpb49HaC5kcG7LDPpD3APtlSYANGIIFbtNfASPN1mMParlx3a5EoYlaylVdh6cTVM8/7W6/TzMTKZE7KJUaO8YAjpL/HX94WxGnF7fGK4x7x0P6758yKUAAFzb82w7NOJP4xcll/6WDEoVV6czxNEc=; Received: from [87.194.222.63] by web44910.mail.sp1.yahoo.com via HTTP; Sun, 13 Jul 2008 19:57:28 PDT X-Mailer: YahooMailRC/975.45 YahooMailWebService/0.7.199 Date: Sun, 13 Jul 2008 19:57:28 -0700 (PDT) From: vapnik spaknik Subject: gud/gdb not interacting properly with remote source file To: bug-gnu-emacs@gnu.org MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-1724398418-1216004248=:73907" Message-ID: <920211.73907.qm@web44910.mail.sp1.yahoo.com> X-detected-kernel: by monty-python.gnu.org: FreeBSD 6.x (1) --0-1724398418-1216004248=:73907 Content-Type: text/plain; charset=us-ascii --text follows this line-- This bug report will be sent to the Free Software Foundation, not to your local site managers! Please write in English, because the Emacs maintainers do not have translators to read other languages for them. Your bug report will be posted to the bug-gnu-emacs@gnu.org mailing list, and to the gnu.emacs.bug news group. In GNU Emacs 21.4.1 (i486-pc-linux-gnu, X toolkit, Xaw3d scroll bars) of 2007-06-19 on ninsei, modified by Debian configured using `configure '--build=i486-linux-gnu' '--host=i486-linux-gnu' '--prefix=/usr' '--sharedstatedir=/var/lib' '--libexecdir=/usr/lib' '--localstatedir=/var/lib' '--infodir=/usr/share/info' '--mandir=/usr/share/man' '--with-pop=yes' '--with-x=yes' '--with-x-toolkit=athena' 'build_alias=i486-linux-gnu' 'host_alias=i486-linux-gnu' 'CFLAGS=-DDEBIAN -g -O2'' Important settings: value of $LC_ALL: nil value of $LC_COLLATE: nil value of $LC_CTYPE: nil value of $LC_MESSAGES: nil value of $LC_MONETARY: nil value of $LC_NUMERIC: nil value of $LC_TIME: nil value of $LANG: en_GB.UTF-8 locale-coding-system: utf-8 default-enable-multibyte-characters: t Please describe exactly what actions triggered the bug and the precise symptoms of the bug: I open a remote c file using tramp. >From within that buffer I do: M-x gdb and invoke gdb on the executable associated with the c file (the executable contains appropriate debugging symbols) The gud buffer opens correctly and typing "list" and "info source" indicates that gdb has the correct source file loaded. I go to the source buffer in emacs and set a breakpoint using C-x in the gud buffer I see that the breakpoint has been set correctly. But then when I try stepping through the code using "next", a new empty buffer is created whose file path (according to the buffer list) is similar to the path of the remote source, except that it is local, i.e. instead of "me@remote:/home/me/file.c" it is "/home/me/file.c" Any further stepping through the code in the gud buffer brings up the new empty buffer which contains a small white arrow in the left margin as it would do normally, except this time it is pointing to an empty line. The buffer containing the remote source file does not indicate the point of execution, but still allows me to set breakpoints with C-x . If I try debugging with a local file it works fine. Recent input: n M-x e m a c s - r e p o r e p o r t Recent messages: Loading view...done Loading eieio-opt (compiled; note, source file is newer)...done call-interactively: Quit Type M-x switch-to-buffer-other-window RET to restore the other window. C-M-v to scroll the help. Commands: d, s, x, u; f, o, 1, 2, m, v; ~, %; q to quit; ? for help. [3 times] Mark set Mark saved where search started [2 times] gud-query-cmdline: Quit Command: next 1 [3 times] Loading emacsbug...done --0-1724398418-1216004248=:73907 Content-Type: text/html; charset=us-ascii
--text follows this line--
This bug report will be sent to the Free Software Foundation,
not to your local site managers!
Please write in English, because the Emacs maintainers do not have
translators to read other languages for them.

Your bug report will be posted to the bug-gnu-emacs@gnu.org mailing list,
and to the gnu.emacs.bug news group.

In GNU Emacs 21.4.1 (i486-pc-linux-gnu, X toolkit, Xaw3d scroll bars)
 of 2007-06-19 on ninsei, modified by Debian
configured using `configure  '--build=i486-linux-gnu' '--host=i486-linux-gnu' '--prefix=/usr' '--sharedstatedir=/var/lib' '--libexecdir=/usr/lib' '--localstatedir=/var/lib' '--infodir=/usr/share/info' '--mandir=/usr/share/man' '--with-pop=yes' '--with-x=yes' '--with-x-toolkit=athena' 'build_alias=i486-linux-gnu' 'host_alias=i486-linux-gnu' 'CFLAGS=-DDEBIAN -g -O2''
Important settings:
  value of $LC_ALL: nil
  value of $LC_COLLATE: nil
  value of $LC_CTYPE: nil
  value of $LC_MESSAGES: nil
  value of $LC_MONETARY: nil
  value of $LC_NUMERIC: nil
  value of $LC_TIME: nil
  value of $LANG: en_GB.UTF-8
  locale-coding-system: utf-8
  default-enable-multibyte-characters: t

Please describe exactly what actions triggered the bug
and the precise symptoms of the bug:

I open a remote c file using tramp.
From within that buffer I do: M-x gdb
and invoke gdb on the executable associated with the c file
(the executable contains appropriate debugging symbols)
The gud buffer opens correctly and typing "list" and "info source"
indicates that gdb has the correct source file loaded.
I go to the source buffer in emacs and set a breakpoint using C-x <SPC>
in the gud buffer I see that the breakpoint has been set correctly.
But then when I try stepping through the code using "next",
a new empty buffer is created whose file path (according to the buffer list)
is similar to the path of the remote source, except that it is local,
i.e. instead of "me@remote:/home/me/file.c" it is "/home/me/file.c"
Any further stepping through the code in the gud buffer brings up the new empty
buffer which contains a small white arrow in the left margin as it would
do normally, except this time it is pointing to an empty line.
The buffer containing the remote source file does not indicate the point of execution,
but still allows me to set breakpoints with C-x <SPC>.

If I try debugging with a local file it works fine.





Recent input:
<mouse-movement> <mouse-movement> <mouse-movement>
<mouse-movement> <mouse-movement> <mouse-movement>
<mouse-movement> <mouse-movement> <mouse-movement>
<mouse-movement> <mouse-movement> <mouse-movement>
<mouse-movement> <mouse-movement> <mouse-movement>
<mouse-movement> n <mouse-movement> <mouse-movement>
<mouse-movement> <return> <mouse-movement> <mouse-movement>
<mouse-movement> <mouse-movement> <mouse-movement>
<mouse-movement> <mouse-movement> <mouse-movement>
<mouse-movement> <mouse-movement> <mouse-movement>
<mouse-movement> <mouse-movement> <mouse-movement>
<mouse-movement> <mouse-movement> <mouse-movement>
<mouse-movement> <mouse-movement> <mouse-movement>
<mouse-movement> <mouse-movement> <mouse-movement>
<mouse-movement> <mouse-movement> <mouse-movement>
<mouse-movement> <mouse-movement> <mouse-movement>
<mouse-movement> <mouse-movement> <mouse-movement>
<mouse-movement> <mouse-movement> <mouse-movement>
<mouse-movement> <help-echo> <mouse-movement> <mouse-movement>
<mouse-movement> <mouse-movement> <mouse-movement>
<mouse-movement> <mouse-movement> <mouse-movement>
<mouse-movement> <mouse-movement> <mouse-movement>
<mouse-movement> <mouse-movement> <mouse-movement>
<mouse-movement> <mouse-movement> <mouse-movement>
<mouse-movement> <mouse-movement> M-x e m a c s - r
e p <tab> o <tab> <M-backspace> <M-backspace> r e p
o r t <tab> <return>

Recent messages:
Loading view...done
Loading eieio-opt (compiled; note, source file is newer)...done
call-interactively: Quit
Type M-x switch-to-buffer-other-window RET to restore the other window.  C-M-v to scroll the help.
Commands: d, s, x, u; f, o, 1, 2, m, v; ~, %; q to quit; ? for help. [3 times]
Mark set
Mark saved where search started [2 times]
gud-query-cmdline: Quit
Command: next 1 [3 times]
Loading emacsbug...done

--0-1724398418-1216004248=:73907-- From nickrob@snap.net.nz Tue Jul 15 14:35:16 2008 X-Spam-Checker-Version: SpamAssassin 3.2.3-bugs.debian.org_2005_01_02 (2007-08-08) on rzlab.ucr.edu X-Spam-Level: X-Spam-Status: No, score=-7.8 required=4.0 tests=AWL,BAYES_00,HAS_BUG_NUMBER autolearn=ham version=3.2.3-bugs.debian.org_2005_01_02 Received: (at 557) by emacsbugs.donarmstrong.com; 15 Jul 2008 21:35:16 +0000 Received: from viper.snap.net.nz (viper.snap.net.nz [202.37.101.25]) by rzlab.ucr.edu (8.13.8/8.13.8/Debian-3) with ESMTP id m6FLZB7B002205 for <557@emacsbugs.donarmstrong.com>; Tue, 15 Jul 2008 14:35:13 -0700 Received: from kahikatea.snap.net.nz (124.31.255.123.static.snap.net.nz [123.255.31.124]) by viper.snap.net.nz (Postfix) with ESMTP id B558A3DAEAD; Wed, 16 Jul 2008 09:35:05 +1200 (NZST) Received: by kahikatea.snap.net.nz (Postfix, from userid 1000) id 189A68FC6D; Wed, 16 Jul 2008 09:35:03 +1200 (NZST) From: Nick Roberts MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <18557.6150.742821.13783@kahikatea.snap.net.nz> Date: Wed, 16 Jul 2008 09:35:02 +1200 To: vapnik spaknik , 557@debbugs.gnu.org Cc: bug-gnu-emacs@gnu.org Subject: Re: bug#557: gud/gdb not interacting properly with remote source file In-Reply-To: <920211.73907.qm@web44910.mail.sp1.yahoo.com> References: <920211.73907.qm@web44910.mail.sp1.yahoo.com> X-Mailer: VM 7.19 under Emacs 22.2.50.3 > In GNU Emacs 21.4.1 (i486-pc-linux-gnu, X toolkit, Xaw3d scroll bars) ... > Please describe exactly what actions triggered the bug > and the precise symptoms of the bug: > > I open a remote c file using tramp. > >From within that buffer I do: M-x gdb > and invoke gdb on the executable associated with the c file > (the executable contains appropriate debugging symbols) > The gud buffer opens correctly and typing "list" and "info source" > indicates that gdb has the correct source file loaded. > I go to the source buffer in emacs and set a breakpoint using C-x > in the gud buffer I see that the breakpoint has been set correctly. > But then when I try stepping through the code using "next", > a new empty buffer is created whose file path (according to the buffer list) > is similar to the path of the remote source, except that it is local, > i.e. instead of "me@remote:/home/me/file.c" it is "/home/me/file.c" > Any further stepping through the code in the gud buffer brings up the new empty > buffer which contains a small white arrow in the left margin as it would > do normally, except this time it is pointing to an empty line. > The buffer containing the remote source file does not indicate the point of execution, > but still allows me to set breakpoints with C-x . > > If I try debugging with a local file it works fine. This looks like Joe Bloggs (bogus e-mail address) earlier report. It doesn't work with Emacs 21.4 and it is necessary to upgrade to 22.2 and ensure that Emacs picks up the version of Tramp that comes with that version of Emacs. Can someone please close this bug and/or tell me if/how I can close it? -- Nick http://www.inet.net.nz/~nickrob From rgm@gnu.org Tue Jul 15 14:53:05 2008 X-Spam-Checker-Version: SpamAssassin 3.2.3-bugs.debian.org_2005_01_02 (2007-08-08) on rzlab.ucr.edu X-Spam-Level: X-Spam-Status: No, score=-11.2 required=4.0 tests=AWL,BAYES_00,HAS_BUG_NUMBER, RCVD_IN_DNSWL_MED,X_DEBBUGS_NO_ACK autolearn=ham version=3.2.3-bugs.debian.org_2005_01_02 Received: (at 557-done) by emacsbugs.donarmstrong.com; 15 Jul 2008 21:53:05 +0000 Received: from fencepost.gnu.org (fencepost.gnu.org [140.186.70.10]) by rzlab.ucr.edu (8.13.8/8.13.8/Debian-3) with ESMTP id m6FLr2rL006206 for <557-done@emacsbugs.donarmstrong.com>; Tue, 15 Jul 2008 14:53:03 -0700 Received: from rgm by fencepost.gnu.org with local (Exim 4.67) (envelope-from ) id 1KIsRe-0005TQ-CG; Tue, 15 Jul 2008 17:52:26 -0400 From: Glenn Morris To: Nick Roberts Cc: 557-done@debbugs.gnu.org Subject: Re: bug#557: gud/gdb not interacting properly with remote source file References: <920211.73907.qm@web44910.mail.sp1.yahoo.com> <18557.6150.742821.13783@kahikatea.snap.net.nz> X-Spook: M-14 UMTS SSL ANZUS doctrine threat S Key quarter X-Ran: 62(]v+%C})WyUBhYup^Ro!lVimp<5h={.2$ X-Hue: green X-Debbugs-No-Ack: yes X-Attribution: GM Date: Tue, 15 Jul 2008 17:52:26 -0400 In-Reply-To: <18557.6150.742821.13783@kahikatea.snap.net.nz> (Nick Roberts's message of "Wed, 16 Jul 2008 09:35:02 +1200") Message-ID: <0xej5un7c5.fsf@fencepost.gnu.org> User-Agent: Gnus (www.gnus.org), GNU Emacs (www.gnu.org/software/emacs/) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Nick Roberts wrote: > Can someone please close this bug and/or tell me if/how I can close it? You change the "To: 577@emacsbugs" to "To: 577-done@emacsbugs". (I did this in this message). See admin/notes/bugtracker. From unknown Thu Aug 14 18:32:45 2025 Received: (at fakecontrol) by fakecontrolmessage; To: internal_control@debbugs.gnu.org From: $requester Subject: Internal Control Message-Id: bug archived. Date: Wed, 13 Aug 2008 14:24:03 +0000 User-Agent: Fakemail v42.6.9 # A New Hope # A log time ago, in a galaxy far, far away # something happened. # # Magically this resulted in the following # action being taken, but this fake control # message doesn't tell you why it happened # # The action: # bug archived. thanks # This fakemail brought to you by your local debbugs # administrator