gud.el bug + patch

gud.el bug + patch

[Karl Chen]

I'm using Emacs HEAD 2006-03-15 and gdb 6.4.

When I run M-x gdb, I get
     
    Debugger entered--Lisp error: (wrong-type-argument stringp nil)
      get-buffer-window(nil)
      gdb-display-source-buffer(#<buffer breaker.cpp>)
      gud-display-line("/home/quarl/proj/debfsv/analyzer/smbase/breaker.cpp" 16)
      gud-display-frame()

I believe this is a bug in `gud-gdb-marker-filter', where
`gud-last-frame' gets set to
    ("source /path/file.cc" . 19)
I think this should be
    ("/path/file.cc" . 42).

`gdb --annotate=3' gives output such as:

^Z^Zsource /path/file.cc:19:512:beg:0x80f0031


This patch to `gud-gdb-marker-regexp' fixes the problem.


--- gud.el	16 Mar 2006 14:56:18 -0800	1.100
+++ gud.el	22 Mar 2006 20:48:03 -0800	
@@ -558,7 +558,7 @@
   ;; 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]*\\)" ":"
+  (concat "\032\032\\(?:source \\)?\\(.:?[^" ":" "\n]*\\)" ":"
 	  "\\([0-9]*\\)" ":" ".*\n"))
 
 ;; There's no guarantee that Emacs will hand the filter the entire


-- 
Karl 2006-03-22 20:42

Re: gud.el bug + patch

[Nick Roberts]

 > I'm using Emacs HEAD 2006-03-15 and gdb 6.4.
 > 
 > When I run M-x gdb, I get
 >      
 >     Debugger entered--Lisp error: (wrong-type-argument stringp nil)
 >       get-buffer-window(nil)
 >       gdb-display-source-buffer(#<buffer breaker.cpp>)
 >       gud-display-line("/home/quarl/proj/debfsv/analyzer/smbase/breaker.cpp" 16)
 >       gud-display-frame()
 > 
 > I believe this is a bug in `gud-gdb-marker-filter', where

gud-gdb-marker-filter should pick up the prompt annotation first and then
change the value of gud-marker-filter to gud-gdba-marker-filter for further
output.

 > `gud-last-frame' gets set to
 >     ("source /path/file.cc" . 19)
 > I think this should be
 >     ("/path/file.cc" . 42).

Can you give a reproducible test case that gives the error above or
this value for gud-last-frame?

 > `gdb --annotate=3' gives output such as:
 > 
 > ^Z^Zsource /path/file.cc:19:512:beg:0x80f0031
 > 
 > 
 > This patch to `gud-gdb-marker-regexp' fixes the problem.
 > 
 > 
 > --- gud.el	16 Mar 2006 14:56:18 -0800	1.100
 > +++ gud.el	22 Mar 2006 20:48:03 -0800	
 > @@ -558,7 +558,7 @@
 >    ;; 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]*\\)" ":"
 > +  (concat "\032\032\\(?:source \\)?\\(.:?[^" ":" "\n]*\\)" ":"
 >  	  "\\([0-9]*\\)" ":" ".*\n"))
 >  
 >  ;; There's no guarantee that Emacs will hand the filter the entire

This is almost certainly the wrong patch.

If you can't give a test case, please set gdb-enable-debug to t, do:

M-x gdb <RET> 
Run gdb (like this): gdb --annotate=3 `your prog' <RET> 

and send the value of gdb-debug-ring to emacs-devel.


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

Re: gud.el bug + patch

[Karl Chen]

>>>>> On 2006-03-24 04:59 PST, Nick Roberts writes:

    >> `gud-last-frame' gets set to ("source /path/file.cc" . 19)
    >> I think this should be ("/path/file.cc" . 42).

    Nick> Can you give a reproducible test case that gives the
    Nick> error above or this value for gud-last-frame?

I found that having 'run' in .gdbinit triggers the problem; this
recipe should do it:

(progn
  (setq gdb-enable-debug t)
  (shell-command-to-string "echo 'int main() {\nreturn 42;\n}' > a.c")
  (shell-command-to-string "echo 'b main\nrun' > .gdbinit")
  (shell-command-to-string "gcc -g a.c -o a")
  (gdb "gdb --annotate=3 a")
  (gud-step 1))

    Nick> send the value of gdb-debug-ring

((recv . "
^Z^Zpost-prompt

^Z^Zstarting

^Z^Zsource /tmp/a.c:3:24:beg:0x8048375

^Z^Zstopped
") (send-item "server interpreter mi -stack-info-frame
" gdb-get-version))



-- 
Karl 2006-03-24 06:09

Re: gud.el bug + patch

[Nick Roberts]

 >     >> `gud-last-frame' gets set to ("source /path/file.cc" . 19)
 >     >> I think this should be ("/path/file.cc" . 42).
 > 
 >     Nick> Can you give a reproducible test case that gives the
 >     Nick> error above or this value for gud-last-frame?
 > 
 > I found that having 'run' in .gdbinit triggers the problem; this
 > recipe should do it:

The mode works for you otherwise?

I can reproduce this bug.  The problem arises because the order of the initial
annotations is not what Emacs currently expects.  I should be able at least to
get M-x gdba to work under these conditions.  M-x gdb has the added
complication that it is used for both options "--fullname" and "--annotate=3"
and Emacs has to work out which has been invoked from the output.  Maybe at
some stage we can move the old behaviour (--fullname) out to another command
gud-gdb, say.


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

Re: gud.el bug + patch

[Karl Chen]

>>>>> On 2006-03-24 14:05 PST, Nick Roberts writes:

    >> I found that having 'run' in .gdbinit triggers the problem;
    >> this recipe should do it:

    Nick> The mode works for you otherwise?

Yes, it works very well otherwise.  I believe Emacs from 2006-01
worked even with the 'run' command in .gdbinit.

    Nick> I can reproduce this bug.  The problem arises because
    Nick> the order of the initial annotations is not what Emacs
    Nick> currently expects.  I should be able at least to get M-x
    Nick> gdba to work under these conditions.  M-x gdb has the
    Nick> added complication that it is used for both options
    Nick> "--fullname" and "--annotate=3" and Emacs has to work
    Nick> out which has been invoked from the output.  Maybe at
    Nick> some stage we can move the old behaviour (--fullname)
    Nick> out to another command gud-gdb, say.

I guess it's more complicated than I thought; I got excited before
thinking I had solved the problem.  Maybe you could use 'gdb -n'
to inhibit .gdbinit and then load .gdbinit after the necessary
Emacs gud-mode initialization.


-- 
Karl 2006-03-24 14:52

Re: gud.el bug + patch

[Nick Roberts]

 >     >> I found that having 'run' in .gdbinit triggers the problem;
 >     >> this recipe should do it:
 > 
 >     Nick> The mode works for you otherwise?
 > 
 > Yes, it works very well otherwise.  I believe Emacs from 2006-01
 > worked even with the 'run' command in .gdbinit.

I've reverted a change from 2006-03-10 which means that "M-x gdba" should
work for this case now.

But are you saying that "M-x gdb" worked from 2006-01?

If you are I'll investigate further, but if not I'd rather not hack it any
further to try to get it to work.  I would prefer to move the "--fullname"
operation out to another command after the release, assuming the new mode is
well received.

 > I guess it's more complicated than I thought; I got excited before
 > thinking I had solved the problem.  Maybe you could use 'gdb -n'
 > to inhibit .gdbinit and then load .gdbinit after the necessary
 > Emacs gud-mode initialization.

That might be a bit too hairy, the user might specify no init file (-nx),
an init file by a different name (-x)...

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

Re: gud.el bug + patch

[Karl Chen]

>>>>> On 2006-03-24 16:15 PST, Nick Roberts writes:

    Nick> I've reverted a change from 2006-03-10 which means that
    Nick> "M-x gdba" should work for this case now.

Thanks.

    Nick> But are you saying that "M-x gdb" worked from 2006-01?

I tried to figure out why it used to work but couldn't: Emacs from
dates back to 2006-01 has the same behavior.  The '.gdbinit' file
has had 'run' since 2005.  The only think I know is it used to
work until two weeks ago, which was also when I upgraded to
20060315 'emacs-snapshot-*' packages from Debian/unstable.

-- 
Karl 2006-03-27 15:19

Re: gud.el bug + patch

[Nick Roberts]

 >     Nick> But are you saying that "M-x gdb" worked from 2006-01?
 > 
 > I tried to figure out why it used to work but couldn't: Emacs from
 > dates back to 2006-01 has the same behavior.  The '.gdbinit' file
 > has had 'run' since 2005.  The only think I know is it used to
 > work until two weeks ago, which was also when I upgraded to
 > 20060315 'emacs-snapshot-*' packages from Debian/unstable.

Did you upgrade from emacs-21 from Debian/unstable, which would explain why
it used to work, or an earlier emacs-snapshot?

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

Re: gud.el bug + patch

[Karl Chen]

>>>>> On 2006-03-27 17:05 PST, Nick Roberts writes:

    Nick> Did you upgrade from emacs-21 from Debian/unstable,
    Nick> which would explain why it used to work, or an earlier
    Nick> emacs-snapshot?

I had upgraded from the 2006-01-14 snapshot to the 2006-03-15
snapshot.

2006-03-21 20:24:50 upgrade emacs-snapshot-gtk 1:20060114-1 1:20060315-1

-- 
Karl 2006-03-27 17:09