gud/gdb

gud/gdb

[Daniel R. Grayson]

The problem is hard to explain how to reproduce, but occasionally gdb gets
really confused and, in addition to not displaying the buffer with the source
code where the program has stopped, it also issues numerous error messages from
the process filter.

Here is the fix I found that worked for me.  Someone who understands gud better
than I should check the fix for correctness.

In

	lisp/progmodes/gud.el

change

(defvar gud-gdb-marker-regexp
  ;; This used to use path-separator instead of ":";
  ;; however, we found that on both Windows 32 and MSDOS
  ;; a colon is correct here.
  (concat "\032\032\\(.:?[^" ":" "\n]*\\)" ":"
	  "\\([0-9]*\\)" ":" ".*\n"))

to

(defvar gud-gdb-marker-regexp
  ;; This used to use path-separator instead of ":";
  ;; however, we found that on both Windows 32 and MSDOS
  ;; a colon is correct here.
  (concat "\032\032source \\(.:?[^" ":" "\n]*\\)" ":"
	  "\\([0-9]*\\)" ":" ".*\n"))

=============================================================================

In GNU Emacs 22.1.1 (i486-pc-linux-gnu, X toolkit, Xaw3d scroll bars)
 of 2007-07-29 on vernadsky, modified by Ubuntu
Windowing system distributor `The X.Org Foundation', version 11.0.10300000
configured using `configure  '--build' 'i486-linux-gnu' '--host' 'i486-linux-gnu' '--prefix=/usr' '--sharedstatedir=/var/lib' '--libexecdir=/usr/lib' '--localstatedir=/var' '--infodir=/usr/share/info' '--mandir=/usr/share/man' '--with-pop=yes' '--enable-locallisppath=/etc/emacs22:/etc/emacs:/usr/local/share/emacs/22.1/site-lisp:/usr/local/share/emacs/site-lisp:/usr/share/emacs/22.1/site-lisp:/usr/share/emacs/site-lisp:/usr/share/emacs/22.1/leim' '--with-x=yes' '--with-x-toolkit=athena' '--with-toolkit-scroll-bars' 'build_alias=i486-linux-gnu' 'host_alias=i486-linux-gnu' 'CFLAGS=-DDEBIAN -DSITELOAD_PURESIZE_EXTRA=5000 -g -O2''

=============================================================================

$ gdb --version
GNU gdb 6.6-debian
Copyright (C) 2006 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "i486-linux-gnu".

=============================================================================


--
              Daniel R. Grayson, Professor (retired, Emeritus)
              Department of Mathematics
              University of Illinois at Urbana-Champaign
        www:  http://www.math.uiuc.edu/~dan/
      email:  dan@math.uiuc.edu
    us mail:  2409 S. Vine St., Urbana, IL 61801, USA
      phone:  217-367-6384 home   (88.20224W, 40.08541N)
	      217-333-6209 office (88.2280 W, 40.1092 N)

Re: gud/gdb

[Nick Roberts]

 > The problem is hard to explain how to reproduce, but occasionally gdb gets
 > really confused and, in addition to not displaying the buffer with the
 > source code where the program has stopped, it also issues numerous error
 > messages from the process filter.

Does it happen if you enter commands more slowly, e.g. when stepping, in the
GUD buffer so that the program being debugged has time to stop before the next
command?  Also if you step using the toolbar you shouldn't see this problem
(commands issued while the program is running get disregarded).

 > Here is the fix I found that worked for me.  Someone who understands gud
 > better than I should check the fix for correctness.

Before applying such a patch we would need a test to reproduce the problem and
a rationale for the fix but I doubt that this is indeed a fix and suspect that
simply the timing of the commands you entered differed.  I am aware of such
problems but can't see a simple solution.

 > 	lisp/progmodes/gud.el
 > 
 > change
 > 
 > (defvar gud-gdb-marker-regexp
 >   ;; This used to use path-separator instead of ":";
 >   ;; however, we found that on both Windows 32 and MSDOS
 >   ;; a colon is correct here.
 >   (concat "\032\032\\(.:?[^" ":" "\n]*\\)" ":"
 > 	  "\\([0-9]*\\)" ":" ".*\n"))
 > 
 > to
 > 
 > (defvar gud-gdb-marker-regexp
 >   ;; This used to use path-separator instead of ":";
 >   ;; however, we found that on both Windows 32 and MSDOS
 >   ;; a colon is correct here.
 >   (concat "\032\032source \\(.:?[^" ":" "\n]*\\)" ":"
 > 	  "\\([0-9]*\\)" ":" ".*\n"))




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

Re: gud/gdb

[Daniel R. Grayson]

> From: Nick Roberts <nickrob@snap.net.nz>
> Date: Thu, 27 Sep 2007 17:21:50 +1200
> To: "Daniel R. Grayson" <dan@math.uiuc.edu>
> Cc: bug-gnu-emacs@gnu.org
> Subject: Re: gud/gdb
> 
>  > The problem is hard to explain how to reproduce, but occasionally gdb gets
>  > really confused and, in addition to not displaying the buffer with the
>  > source code where the program has stopped, it also issues numerous error
>  > messages from the process filter.
> 
> Does it happen if you enter commands more slowly, e.g. when stepping, in the
> GUD buffer so that the program being debugged has time to stop before the next
> command?  Also if you step using the toolbar you shouldn't see this problem
> (commands issued while the program is running get disregarded).

Thank you for your reply.

It's totally reproducible for me.  I start emacs with -q, debug our (very
large) program with M-x gdb, run the program, give certain input to our program
that causes it to crash, and then gdb fails to show the source.  If I say "up"
to gdb, then it gets confused, as described before.

> 
>  > Here is the fix I found that worked for me.  Someone who understands gud
>  > better than I should check the fix for correctness.
> 
> Before applying such a patch we would need a test to reproduce the problem and
> a rationale for the fix but I doubt that this is indeed a fix and suspect that
> simply the timing of the commands you entered differed.  I am aware of such
> problems but can't see a simple solution.

How about instead if someone reading this message who knows gdb were to verify
that gdb doesn't put filenames directly after "\032\032" any longer (in recent
versions?), but always only after "\032\032source "?  This method of
communication between gdb and emacs must be documented somewhere.

If that were verified, then this bit of emacs code from gud.el

    (while (string-match gud-gdb-marker-regexp gud-marker-acc)
      (setq

       ;; Extract the frame position from the marker.
       gud-last-frame (cons (match-string 1 gud-marker-acc)
       		      	        (string-to-number (match-string 2
				gud-marker-acc)))

shows that emacs is picking up the file name with "source " prepended to it and
trying to use that as the file name.  Eventually it asks for the window of the
buffer containing the phony file name, and unexpectedly gets nil.

If no one understands the protocol (admittedly obsolete), then I can do more
work and get you the proof you need, but I was hoping someone understood that
all better than I so I could save some time.  Let me know!

Umm, wait a minute.  Take a look at this bit of code from gdb's annotate.c:

    void
    annotate_source (char *filename, int line, int character, int mid, CORE_ADDR pc)
    {
      if (annotation_level > 1)
	printf_filtered (("\n\032\032source "));
      else
	printf_filtered (("\032\032"));

      printf_filtered (("%s:%d:%d:%s:0x"), filename,
			 line, character,
				  mid ? "middle" : "beg");
      deprecated_print_address_numeric (pc, 0, gdb_stdout);
      printf_filtered (("\n"));
    }

This problem is correlated with the gdb command line that gud uses having the
option --annotate=3, as in this bit from emacs' gud.el:

    (defcustom gud-gdb-command-name "gdb --annotate=3"
      "Default command to execute an executable under the GDB debugger."
       :type 'string
       :group 'gud)

That's pretty convincing.  At least to me.  Setting the annotation level higher
than used to be done changes the syntax for sending source filenames, and not
all the code in emacs got upgraded when that change was made.

> 
>  > 	lisp/progmodes/gud.el
>  > 
>  > change
>  > 
>  > (defvar gud-gdb-marker-regexp
>  >   ;; This used to use path-separator instead of ":";
>  >   ;; however, we found that on both Windows 32 and MSDOS
>  >   ;; a colon is correct here.
>  >   (concat "\032\032\\(.:?[^" ":" "\n]*\\)" ":"
>  > 	  "\\([0-9]*\\)" ":" ".*\n"))
>  > 
>  > to
>  > 
>  > (defvar gud-gdb-marker-regexp
>  >   ;; This used to use path-separator instead of ":";
>  >   ;; however, we found that on both Windows 32 and MSDOS
>  >   ;; a colon is correct here.
>  >   (concat "\032\032source \\(.:?[^" ":" "\n]*\\)" ":"
>  > 	  "\\([0-9]*\\)" ":" ".*\n"))
> 
> 
> 
> 
> -- 
> Nick                                           http://www.inet.net.nz/~nickrob
> 

Re: gud/gdb

[Nick Roberts]

 > It's totally reproducible for me.  I start emacs with -q, debug our (very
 > large) program with M-x gdb, run the program, give certain input to our
 > program that causes it to crash, and then gdb fails to show the source.  If
 > I say "up" to gdb, then it gets confused, as described before.

Does it work if you start with M-x gdba?

If yes then then please note that the current (in CVS) Emacs docs say:

  ...you can use `M-x gdba' to invoke GDB in graphical mode.  Moreover, this
  command succeeds where `M-x gdb' fails, such as when your `.gdbinit'
  file contains executable GDB commands.

If it still fails can you please do the following:

1) M-x gdb
2) Run gdb (like this): gdb --annotate=3 yourprog <RET>
3) Set the variable `gdb-enable-debug' to t using "M-x set-variable"
4) Run your program etc until Emacs gets confused.
5) Post the value of gdb-debug-log to bug-gnu-emacs (or privately to me if
   it's large (> 100K compressed).

 > How about instead if someone reading this message who knows gdb were to
 > verify that gdb doesn't put filenames directly after "\032\032" any longer
 > (in recent versions?), but always only after "\032\032source "?  This method
 > of communication between gdb and emacs must be documented somewhere.

Assuming that gdb is running with --annotate=3 and not --fullname, Emacs
switches to gdb-ui.el after gdb ouputs the first "prompt" annotation.

 > If that were verified, then this bit of emacs code from gud.el
 > 
 >     (while (string-match gud-gdb-marker-regexp gud-marker-acc)
 >       (setq
 > 
 >        ;; Extract the frame position from the marker.
 >        gud-last-frame (cons (match-string 1 gud-marker-acc)
 >        		      	        (string-to-number (match-string 2
 > 				gud-marker-acc)))
 > 
 > shows that emacs is picking up the file name with "source " prepended to it
 > and trying to use that as the file name.  Eventually it asks for the window
 > of the buffer containing the phony file name, and unexpectedly gets nil.

At this point Emacs should be using gud-gdba-marker-filter.

 > If no one understands the protocol (admittedly obsolete), then I can do more
 > work and get you the proof you need, but I was hoping someone understood that
 > all better than I so I could save some time.  Let me know!
 > 
 > Umm, wait a minute.  Take a look at this bit of code from gdb's annotate.c:

The file gdb-ui.el has been written with this code in mind.  See the
Annotations node of the GDB info manual.

 >...
 > This problem is correlated with the gdb command line that gud uses having the
 > option --annotate=3, as in this bit from emacs' gud.el:
 > 
 >     (defcustom gud-gdb-command-name "gdb --annotate=3"
 >       "Default command to execute an executable under the GDB debugger."
 >        :type 'string
 >        :group 'gud)
 > 
 > That's pretty convincing.  At least to me.  Setting the annotation level
 > higher than used to be done changes the syntax for sending source filenames,
 > and not all the code in emacs got upgraded when that change was made.

I'm sure there are bugs but the change is probably more deliberate than you
imagine.  Have you read the the node "GDB Graphical Interface" of the Emacs
manual?

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

Re: gud/gdb

[Daniel R. Grayson]

Sorry, we've already fixed the bug in our program that caused it to crash at
that spot.  I should have mentioned that we have commands in .gdbinit, so
apparently the work-around (using M-x gdba instead) that you suggest below
would have worked, and you've encountered the bug/issue before (seeminly, emacs
switches to gdb-ui.el too late, after the first source location marker has
arrived).  This explains other behavior I noticed, which is that we can work
around the problem by breaking the program in a different spot first, and then
when it gets to the troublesome part (of our program to be debugged), it works.

Is there a reason that M-x gdba hasn't simply replaced M-x gdb?

Thank you for all your efforts in connection with gdb.

Dan

> From: Nick Roberts <nickrob@snap.net.nz>
> Date: Fri, 28 Sep 2007 18:04:46 +1200
> To: dan@math.uiuc.edu
> Cc: bug-gnu-emacs@gnu.org, mike@math.cornell.edu
> Subject: Re: gud/gdb
> 
>  > It's totally reproducible for me.  I start emacs with -q, debug our (very
>  > large) program with M-x gdb, run the program, give certain input to our
>  > program that causes it to crash, and then gdb fails to show the source.  If
>  > I say "up" to gdb, then it gets confused, as described before.
> 
> Does it work if you start with M-x gdba?
> 
> If yes then then please note that the current (in CVS) Emacs docs say:
> 
>   ...you can use `M-x gdba' to invoke GDB in graphical mode.  Moreover, this
>   command succeeds where `M-x gdb' fails, such as when your `.gdbinit'
>   file contains executable GDB commands.
> 
> If it still fails can you please do the following:
> 
> 1) M-x gdb
> 2) Run gdb (like this): gdb --annotate=3 yourprog <RET>
> 3) Set the variable `gdb-enable-debug' to t using "M-x set-variable"
> 4) Run your program etc until Emacs gets confused.
> 5) Post the value of gdb-debug-log to bug-gnu-emacs (or privately to me if
>    it's large (> 100K compressed).
> 
>  > How about instead if someone reading this message who knows gdb were to
>  > verify that gdb doesn't put filenames directly after "\032\032" any longer
>  > (in recent versions?), but always only after "\032\032source "?  This method
>  > of communication between gdb and emacs must be documented somewhere.
> 
> Assuming that gdb is running with --annotate=3 and not --fullname, Emacs
> switches to gdb-ui.el after gdb ouputs the first "prompt" annotation.
> 
>  > If that were verified, then this bit of emacs code from gud.el
>  > 
>  >     (while (string-match gud-gdb-marker-regexp gud-marker-acc)
>  >       (setq
>  > 
>  >        ;; Extract the frame position from the marker.
>  >        gud-last-frame (cons (match-string 1 gud-marker-acc)
>  >        		      	        (string-to-number (match-string 2
>  > 				gud-marker-acc)))
>  > 
>  > shows that emacs is picking up the file name with "source " prepended to it
>  > and trying to use that as the file name.  Eventually it asks for the window
>  > of the buffer containing the phony file name, and unexpectedly gets nil.
> 
> At this point Emacs should be using gud-gdba-marker-filter.
> 
>  > If no one understands the protocol (admittedly obsolete), then I can do more
>  > work and get you the proof you need, but I was hoping someone understood that
>  > all better than I so I could save some time.  Let me know!
>  > 
>  > Umm, wait a minute.  Take a look at this bit of code from gdb's annotate.c:
> 
> The file gdb-ui.el has been written with this code in mind.  See the
> Annotations node of the GDB info manual.
> 
>  >...
>  > This problem is correlated with the gdb command line that gud uses having the
>  > option --annotate=3, as in this bit from emacs' gud.el:
>  > 
>  >     (defcustom gud-gdb-command-name "gdb --annotate=3"
>  >       "Default command to execute an executable under the GDB debugger."
>  >        :type 'string
>  >        :group 'gud)
>  > 
>  > That's pretty convincing.  At least to me.  Setting the annotation level
>  > higher than used to be done changes the syntax for sending source filenames,
>  > and not all the code in emacs got upgraded when that change was made.
> 
> I'm sure there are bugs but the change is probably more deliberate than you
> imagine.  Have you read the the node "GDB Graphical Interface" of the Emacs
> manual?
> 
> -- 
> Nick                                           http://www.inet.net.nz/~nickrob
> 

Re: gud/gdb

[Nick Roberts]

 > Sorry, we've already fixed the bug in our program that caused it to crash at
 > that spot.  I should have mentioned that we have commands in .gdbinit, so
 > apparently the work-around (using M-x gdba instead) that you suggest below
 > would have worked, and you've encountered the bug/issue before (seeminly,
 > emacs switches to gdb-ui.el too late, after the first source location marker
 > has arrived).  This explains other behavior I noticed, which is that we can
 > work around the problem by breaking the program in a different spot first,
 > and then when it gets to the troublesome part (of our program to be
 > debugged), it works.
 > 
 > Is there a reason that M-x gdba hasn't simply replaced M-x gdb?

There is a thread where I suggested this, starting at:

http://lists.gnu.org/archive/html/emacs-pretest-bug/2007-07/msg00070.html

It lost it's way a bit but as you're the third person to report these problems,
I think we should revisit it and make gdb-ui the default in some way, at least.

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