* bug#557: gud/gdb not interacting properly with remote source file @ 2008-07-14 2:57 ` vapnik spaknik 2008-07-15 21:35 ` Nick Roberts 2008-07-15 22:00 ` bug#557: marked as done (gud/gdb not interacting properly with remote source file) Emacs bug Tracking System 0 siblings, 2 replies; 3+ messages in thread From: vapnik spaknik @ 2008-07-14 2:57 UTC (permalink / raw) To: bug-gnu-emacs [-- Attachment #1: Type: text/plain, Size: 4227 bytes --] --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 [-- Attachment #2: Type: text/html, Size: 5271 bytes --] ^ permalink raw reply [flat|nested] 3+ messages in thread
* bug#557: gud/gdb not interacting properly with remote source file 2008-07-14 2:57 ` bug#557: gud/gdb not interacting properly with remote source file vapnik spaknik @ 2008-07-15 21:35 ` Nick Roberts 2008-07-15 22:00 ` bug#557: marked as done (gud/gdb not interacting properly with remote source file) Emacs bug Tracking System 1 sibling, 0 replies; 3+ messages in thread From: Nick Roberts @ 2008-07-15 21:35 UTC (permalink / raw) To: vapnik spaknik, 557; +Cc: bug-gnu-emacs > 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 <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. 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 ^ permalink raw reply [flat|nested] 3+ messages in thread
* bug#557: marked as done (gud/gdb not interacting properly with remote source file) 2008-07-14 2:57 ` bug#557: gud/gdb not interacting properly with remote source file vapnik spaknik 2008-07-15 21:35 ` Nick Roberts @ 2008-07-15 22:00 ` Emacs bug Tracking System 1 sibling, 0 replies; 3+ messages in thread From: Emacs bug Tracking System @ 2008-07-15 22:00 UTC (permalink / raw) To: Glenn Morris [-- Attachment #1: Type: text/plain, Size: 886 bytes --] Your message dated Tue, 15 Jul 2008 17:52:26 -0400 with message-id <0xej5un7c5.fsf@fencepost.gnu.org> and subject line Re: bug#557: gud/gdb not interacting properly with remote source file has caused the Emacs bug report #557, regarding gud/gdb not interacting properly with remote source file to be marked as done. This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what this message is talking about, this may indicate a serious mail system misconfiguration somewhere. Please contact don@donarmstrong.com immediately.) -- 557: http://emacsbugs.donarmstrong.com/cgi-bin/bugreport.cgi?bug=557 Emacs Bug Tracking System Contact don@donarmstrong.com with problems [-- Attachment #2: Type: message/rfc822, Size: 12320 bytes --] [-- Attachment #2.1.1: Type: text/plain, Size: 4227 bytes --] --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 [-- Attachment #2.1.2: Type: text/html, Size: 5271 bytes --] [-- Attachment #3: Type: message/rfc822, Size: 1785 bytes --] From: Glenn Morris <rgm@gnu.org> To: Nick Roberts <nickrob@snap.net.nz> Cc: 557-done@emacsbugs.donarmstrong.com Subject: Re: bug#557: gud/gdb not interacting properly with remote source file Date: Tue, 15 Jul 2008 17:52:26 -0400 Message-ID: <0xej5un7c5.fsf@fencepost.gnu.org> 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. ^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2008-07-15 22:00 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
[not found] <0xej5un7c5.fsf@fencepost.gnu.org>
2008-07-14 2:57 ` bug#557: gud/gdb not interacting properly with remote source file vapnik spaknik
2008-07-15 21:35 ` Nick Roberts
2008-07-15 22:00 ` bug#557: marked as done (gud/gdb not interacting properly with remote source file) Emacs bug Tracking System
Code repositories for project(s) associated with this public inbox https://git.savannah.gnu.org/cgit/emacs.git This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).