various gdba bugs and requests

various gdba bugs and requests

[Tom Tromey]

Please write in English if possible, because the Emacs maintainers
usually do not have translators to read other languages for them.

Your bug report will be posted to the emacs-pretest-bug@gnu.org mailing list.

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

I finally started using gdba with gdb-many-windows set to 't'.  Nice
stuff!  If I maximize the frame and enable the toolbar, it is as nice
as any GUI debugger I've used.

I have run across a few minor problems though.

I'm using x86 Fedora Core 6 plus the system gdb, which says:

    opsy. gdb --version
    GNU gdb Red Hat Linux (6.5-15.fc6rh)

1. I made a new frame for gdba and maximized it.  Then I moved it to
another virtual desktop.  gdb ran for a long time so I switched back
to my primary desktop and worked on other things.  When gdb finally
hit a breakpoint, the gud buffer appeared on one of my existing
frames.

In this situation I'd prefer that this not happen -- I want gud to
remain confined to the frame on the other desktop.  Perhaps there
could be a variable of some kind to control the pop-up behavior, plus
maybe a hook that is run when gdb changes state (I didn't look to see
if there is one yet, so I'm sorry if this already happens).


2. If I type too quickly I often see "Unexpected `starting' annotation".
This happens most often when I type "n" and then hit enter a number of
times to next through a function.


3. At one point I restarted the inferior process using "run".  gud
seemed to lose track of the inferior completely -- the stack window no
longer showed the stack; the breakpoints and locals windows did not
update.

Exiting gud and restarting the debug session fixed this.  But, that is
pretty drastic.


4. I'd like a way to arrange the windows differently.  The standard
setup isn't to my taste.


5. I found the green stop-sign icon somewhat confusing.


6. I often find that gdb acts strangely or sometimes crashes; one
thing that is nice about the Emacs approach to a gdb UI is that a lot
of state is kept in the gud buffer, so I can kill gdb, restart, search
backward and not lose too much.  Still, it would be nice if gud
offered a way to save the state of a debug session -- say, the cwd,
the command line, and the breakpoints (plus their conditions,
commands, etc).


7. Right now if I set a breakpoint (using C-x SPC), then edit text
earlier in that file, recompile, and re-run the inferior, the
breakpoint will be in the "wrong" location.  This happens because the
breakpoint is set by file/line.

It would be cool if gud put a marker on a breakpoint's location and
then used the marker location to move the breakpoint.  Perhaps this
could be done by moving it when gdb notices that the inferior
executable has changed.


8. I notice strange frame-raising behavior sometimes.  If I set a
command on a breakpoint that ends with "cont" and then the inferior
runs for a long time, the emacs frame showing the gud buffer will
constantly raise itself.  Also the gdb status on the mode line will
flicker rapidly between running and stopped.


Sorry for the length of this.  I've been debugging rather heavily this
week and batched all the oddities into one big note :-)



If Emacs crashed, and you have the Emacs process in the gdb debugger,
please include the output from the following gdb commands:
    `bt full' and `xbacktrace'.
If you would like to further debug the crash, please read the file
/usr/share/emacs/22.0.990/etc/DEBUG for instructions.


In GNU Emacs 22.0.990.1 (i386-koji-linux-gnu, GTK+ Version 2.10.11)
 of 2007-05-23 on xenbuilder3.fedora.phx.redhat.com
Windowing system distributor `The X.Org Foundation', version 11.0.70101000
configured using `configure  '--build=i386-koji-linux-gnu' '--host=i386-koji-linux-gnu' '--target=i386-redhat-linux-gnu' '--program-prefix=' '--prefix=/usr' '--exec-prefix=/usr' '--bindir=/usr/bin' '--sbindir=/usr/sbin' '--sysconfdir=/etc' '--datadir=/usr/share' '--includedir=/usr/include' '--libdir=/usr/lib' '--libexecdir=/usr/libexec' '--localstatedir=/var' '--sharedstatedir=/usr/com' '--mandir=/usr/share/man' '--infodir=/usr/share/info' '--with-pop' '--with-sound' '--with-gtk' 'build_alias=i386-koji-linux-gnu' 'host_alias=i386-koji-linux-gnu' 'target_alias=i386-redhat-linux-gnu' 'CFLAGS=-DMAIL_USE_LOCKF -DSYSTEM_PURESIZE_EXTRA=16777216 -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions --param=ssp-buffer-size=4 -m32 -march=i386 -mtune=generic -fasynchronous-unwind-tables''

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_US.UTF-8
  locale-coding-system: utf-8
  default-enable-multibyte-characters: t

Major mode: Group

Minor modes in effect:
  gnus-agent-mode: t
  compilation-in-progress: (gid gid gid grep gid gid grep gid grep gid grep gid grep grep grep grep gid gid gid gid gid grep gid gid gid gid gid compilation compilation compilation grep grep grep grep gid grep compilation compilation compilation compilation compilation compilation compilation compilation gid grep grep grep grep grep grep gid gid grep compilation grep compilation compilation grep compilation grep gid grep gid gid grep grep gid)
  erc-menu-mode: t
  erc-autojoin-mode: t
  erc-ring-mode: t
  erc-pcomplete-mode: t
  erc-track-mode: t
  erc-track-minor-mode: t
  erc-match-mode: t
  erc-button-mode: t
  erc-fill-mode: t
  erc-stamp-mode: t
  erc-netsplit-mode: t
  erc-spelling-mode: t
  erc-truncate-mode: t
  gnus-undo-mode: t
  erc-status-mode: t
  erc-services-mode: t
  erc-irccontrols-mode: t
  erc-noncommands-mode: t
  erc-readonly-mode: t
  tooltip-mode: t
  mouse-wheel-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  unify-8859-on-encoding-mode: t
  utf-translate-cjk-mode: t
  auto-compression-mode: t
  line-number-mode: t
  transient-mark-mode: t

Recent input:
e e " SPC s t r u c t u r e e <backspace> ; SPC i n 
SPC t a h t c <backspace> <M-backspace> t h a t SPC 
c a e , SPC n o C-u C-b C-b s C-e p e , SPC t h a t 
' s SPC w h a t SPC w e ' v e SPC g o t . M-q C-f C-f 
C-n C-f M-v C-l C-n M-e M-k M-q SPC SPC F o r SPC C 
+ + SPC t h e SPC s i a t u <M-backspace> s i t u a 
t i o n n SPC i s SPC C-u C-b C-b C-d C-e g o n <backspace> 
i n g SPC t o SPC b e SPC e v e n SPC m o r e SPC c 
o p m l l i c a C-u C-g <M-backspace> c m o p l i c 
<backspace> <M-backspace> c o m p l i c a t e d . C-x 
b <return> <backspace> C-x 4 b <return> C-x 1 C-a M-q 
M-} M-} M-v C-c C-c q SPC q p M-g p SPC M-> C-p C-p 
SPC SPC SPC n q C-l M-g M-g p p SPC C-u C-n n n n n 
n = M-v c SPC p n C-p C-u = 1 <backspace> 3 0 0 <return> 
C-s n i c k C-s C-a q C-p C-u = 1 0 0 0 <return> M-< 
C-s n i c k C-a SPC = C-s C-s C-s C-s C-s C-a q l SPC 
d SPC SPC q l s SPC SPC M-> C-p C-p d d q s M-x r e 
p o r t - e m <tab> b <tab> <return>

Recent messages:
Generating summary...done
Mark set
No more unread articles
No more articles
(No changes need to be saved)
Saving /home/tromey/.newsrc.eld...
Saving file /home/tromey/.newsrc.eld...
Wrote /home/tromey/.newsrc.eld
Saving /home/tromey/.newsrc.eld...done
Loading emacsbug...done

Tom

Re: various gdba bugs and requests

[Nick Roberts]

 > I finally started using gdba with gdb-many-windows set to 't'.  Nice
 > stuff!  If I maximize the frame and enable the toolbar, it is as nice
 > as any GUI debugger I've used.
 > 
 > I have run across a few minor problems though.

Thanks for a comprehensive review.  I am aware of most of these problems - I'm
just not sure what to do about them so my replies mght be a bit disappointing.

 > I'm using x86 Fedora Core 6 plus the system gdb, which says:
 > 
 >     opsy. gdb --version
 >     GNU gdb Red Hat Linux (6.5-15.fc6rh)
 > 
 > 1. I made a new frame for gdba and maximized it.  Then I moved it to
 > another virtual desktop.  gdb ran for a long time so I switched back
 > to my primary desktop and worked on other things.  When gdb finally
 > hit a breakpoint, the gud buffer appeared on one of my existing
 > frames.

I'm not sure if is a virtual desktop or a frame problem.  I don't know
why the gud buffer appeared.  GUD should just pop up a source buffer,
generally in the window where the source was previously or the frame of
the GUD buffer.

 > In this situation I'd prefer that this not happen -- I want gud to
 > remain confined to the frame on the other desktop.  Perhaps there
 > could be a variable of some kind to control the pop-up behavior, plus
 > maybe a hook that is run when gdb changes state (I didn't look to see
 > if there is one yet, so I'm sorry if this already happens).

To really understand what is happening you need to send a way to reproduce it.

 > 2. If I type too quickly I often see "Unexpected `starting' annotation".
 > This happens most often when I type "n" and then hit enter a number of
 > times to next through a function.

This is because GDB is still running and Emacs doesn't know if the input is for
GDB (in which case it should be queued) or for the program being debugged (in
which case it should be sent straight away). If your program doesn't use IO you
can apply the patch below.  Note that Emacs should still recover after this
error.

 > 3. At one point I restarted the inferior process using "run".  gud
 > seemed to lose track of the inferior completely -- the stack window no
 > longer showed the stack; the breakpoints and locals windows did not
 > update.
 > 
 > Exiting gud and restarting the debug session fixed this.  But, that is
 > pretty drastic.

This shouldn't happen.  Please send a testcase.

 > 4. I'd like a way to arrange the windows differently.  The standard
 > setup isn't to my taste.

Eclipse is superior in this respect.  I sometimes use gdb-many-windows but
generally I just pop up extra buffers in their own frames as I need them, from
the menu-bar.

 > 5. I found the green stop-sign icon somewhat confusing.

There are two buttons that share one location on the tool bar: a red one with
the word "STOP" that is visible when the inferior is running and stops
execution (usually sends a SIGINT) ; and a green one with the word "GO" that is
visible when execution has stopped and invokes "run" if the program has not
started or has exited, or "continue" if execution has stopped in the inferior.
This means if you want to restart execution in the middle of a session then you
need to enter "run" in the GUD buffer.  This is slightly inconvenient but I
don't think it's as bad as having three separate buttons for "run", "continue"
and interrupt (Ctrl-C on the command line).  To see what this is like try
"gdb --fullname" from the minibuffer.

 > 6. I often find that gdb acts strangely or sometimes crashes; one
 > thing that is nice about the Emacs approach to a gdb UI is that a lot
 > of state is kept in the gud buffer, so I can kill gdb, restart, search
 > backward and not lose too much.  Still, it would be nice if gud
 > offered a way to save the state of a debug session -- say, the cwd,
 > the command line, and the breakpoints (plus their conditions,
 > commands, etc).

If GDB crashes then that's a bug which should be reported to the GDB mailing
list.  Emacs could keep session information but how would this be more
convenient than using the GDB command "set logging on"?

 > 7. Right now if I set a breakpoint (using C-x SPC), then edit text
 > earlier in that file, recompile, and re-run the inferior, the
 > breakpoint will be in the "wrong" location.  This happens because the
 > breakpoint is set by file/line.
 >
 > It would be cool if gud put a marker on a breakpoint's location and
 > then used the marker location to move the breakpoint.  Perhaps this
 > could be done by moving it when gdb notices that the inferior
 > executable has changed.

Yes, I think Visual Studio DTRT but presumably it is just one program.  It's
difficult for Emacs to communicate such a change to GDB.

 > 8. I notice strange frame-raising behavior sometimes.  If I set a
 > command on a breakpoint that ends with "cont" and then the inferior
 > runs for a long time, the emacs frame showing the gud buffer will
 > constantly raise itself.  Also the gdb status on the mode line will
 > flicker rapidly between running and stopped.

Emacs processes all output from GDB and the flicker is present because
execution is repeatedly stopping and starting.  Maybe I could stop the
gud buffer constantly raising itself but I don't see that.  Do you see
it if you start with "emacs -Q"?

 > In GNU Emacs 22.0.990.1 (i386-koji-linux-gnu, GTK+ Version 2.10.11)

I believe Fedora 7 has a backport for Emacs 22.1.

-- 
Nick                                           http://www.inet.net.nz/~nickrob


*** gdb-ui.el	13 Sep 2007 18:01:14 +1200	1.206.2.5
--- gdb-ui.el	15 Sep 2007 20:09:26 +1200	
*************** The key should be one of the cars in `gd
*** 1132,1151 ****
    "A comint send filter for gdb.
  This filter may simply queue input for a later time."
    (when gdb-ready
!       (with-current-buffer gud-comint-buffer
! 	(let ((inhibit-read-only t))
! 	  (remove-text-properties (point-min) (point-max) '(face))))
!       (if gud-running
! 	  (progn
! 	    (let ((item (concat string "\n")))
! 	      (if gdb-enable-debug (push (cons 'send item) gdb-debug-log))
! 	      (process-send-string proc item)))
! 	(if (string-match "\\\\\\'" string)
! 	    (setq gdb-continuation (concat gdb-continuation string "\n"))
! 	  (let ((item (concat gdb-continuation string
! 			      (if (not comint-input-sender-no-newline) "\n"))))
! 	    (gdb-enqueue-input item)
! 	    (setq gdb-continuation nil))))))
  
  ;; Note: Stuff enqueued here will be sent to the next prompt, even if it
  ;; is a query, or other non-top-level prompt.
--- 1132,1146 ----
    "A comint send filter for gdb.
  This filter may simply queue input for a later time."
    (when gdb-ready
!     (with-current-buffer gud-comint-buffer
!       (let ((inhibit-read-only t))
! 	(remove-text-properties (point-min) (point-max) '(face))))
!     (if (string-match "\\\\\\'" string)
! 	(setq gdb-continuation (concat gdb-continuation string "\n"))
!       (let ((item (concat gdb-continuation string
! 			  (if (not comint-input-sender-no-newline) "\n"))))
! 	(gdb-enqueue-input item)
! 	(setq gdb-continuation nil)))))
  
  ;; Note: Stuff enqueued here will be sent to the next prompt, even if it
  ;; is a query, or other non-top-level prompt.

Re: various gdba bugs and requests

[Tom Tromey]

>>>>> "Nick" == Nick Roberts <nickrob@snap.net.nz> writes:

Nick> Thanks for a comprehensive review.  I am aware of most of these
Nick> problems - I'm just not sure what to do about them so my replies
Nick> mght be a bit disappointing.

No problem.

FWIW I'm not replying to everything right now...

>> 1. I made a new frame for gdba and maximized it.  Then I moved it to
>> another virtual desktop.  gdb ran for a long time so I switched back
>> to my primary desktop and worked on other things.  When gdb finally
>> hit a breakpoint, the gud buffer appeared on one of my existing
>> frames.

Nick> I'm not sure if is a virtual desktop or a frame problem.  I don't know
Nick> why the gud buffer appeared.  GUD should just pop up a source buffer,
Nick> generally in the window where the source was previously or the frame of
Nick> the GUD buffer.

Oops, I wrote "gud buffer" but I meant "source buffer".  Sorry about
that.

I think what I want here is a mode where gdba understands that there
is a "gdb frame", and won't try to show the source buffer anywhere
except the designated source window in that frame.

Nick> [ ways to reproduce are needed ]

I'll try to get this.  It may take a while.

>> 4. I'd like a way to arrange the windows differently.  The standard
>> setup isn't to my taste.

Nick> Eclipse is superior in this respect.  I sometimes use
Nick> gdb-many-windows but generally I just pop up extra buffers in
Nick> their own frames as I need them, from the menu-bar.

I've got an initial draft of some window-rearrangement code... I'll
send it when it works a bit better.  Basically the idea is that the
user can rearrange the windows and then M-x gdb-save-windows.

>> 6. I often find that gdb acts strangely or sometimes crashes; one
>> thing that is nice about the Emacs approach to a gdb UI is that a lot
>> of state is kept in the gud buffer, so I can kill gdb, restart, search
>> backward and not lose too much.  Still, it would be nice if gud
>> offered a way to save the state of a debug session -- say, the cwd,
>> the command line, and the breakpoints (plus their conditions,
>> commands, etc).

Nick> If GDB crashes then that's a bug which should be reported to the
Nick> GDB mailing list.

Yeah, I agree.  But as a practical matter, gdb has crashed or wedged
or otherwise gotten confused on a semi-regular basis ever since I
first started using it.  Working around this is a survival strategy.

Nick> Emacs could keep session information but how would this be more
Nick> convenient than using the GDB command "set logging on"?

I think logging is not really what I want.  It saves the output of gdb
commands.  But, I already have that in the gud buffer.

Instead what I want is to save some state: cwd, breakpoint info,
command line arguments, etc.  I often want to be able to re-create a
gdb session; I think it would be nice if Emacs provided a way to do
that.

>> In GNU Emacs 22.0.990.1 (i386-koji-linux-gnu, GTK+ Version 2.10.11)

Nick> I believe Fedora 7 has a backport for Emacs 22.1.

Yeah, I'm running a rawhide version, I'll fix that eventually.

Tom

Re: various gdba bugs and requests

[Nick Roberts]

 > Oops, I wrote "gud buffer" but I meant "source buffer".  Sorry about
 > that.

OK, choice of the window for the source buffer uses serendipity and there
must be cases I've not considered.  In particular, I've not moved away from
a debug session while it's running.

 > I think what I want here is a mode where gdba understands that there
 > is a "gdb frame", and won't try to show the source buffer anywhere
 > except the designated source window in that frame.

Gdba can use more than one frame, but it should be possible to confine the
source to one frame.

 > ...
 > I've got an initial draft of some window-rearrangement code... I'll
 > send it when it works a bit better.  Basically the idea is that the
 > user can rearrange the windows and then M-x gdb-save-windows.

Any contributed code is always appreciated.

 > ...
 > Nick> If GDB crashes then that's a bug which should be reported to the
 > Nick> GDB mailing list.
 > 
 > Yeah, I agree.  But as a practical matter, gdb has crashed or wedged
 > or otherwise gotten confused on a semi-regular basis ever since I
 > first started using it.  Working around this is a survival strategy.

If your platform is standard, I'me a bit surprised it crashes that often.
I woould have thought gdba is more likely to get confused.

 > Nick> Emacs could keep session information but how would this be more
 > Nick> convenient than using the GDB command "set logging on"?
 > 
 > I think logging is not really what I want.  It saves the output of gdb
 > commands.  But, I already have that in the gud buffer.

I was thinking about saving a session for later.

 > Instead what I want is to save some state: cwd, breakpoint info,
 > command line arguments, etc.  I often want to be able to re-create a
 > gdb session; I think it would be nice if Emacs provided a way to do
 > that.

I know Eclipse and Insight save session information, perhaps Emacs could use
one of those formats.  In general, I'm not keen on project folders because it
makes it hard to transport projects from one system to another.

-- 
Nick                                           http://www.inet.net.nz/~nickrob