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
>