gud breakage: ^done,changelist=[]

gud breakage: ^done,changelist=[]

[Jan Nieuwenhuizen]

Hi,

Anyone using gud from CVS?  It has been broken for me for quite some
time now, but it used to break `only' after about 100 prompts or so;
usually enough to nail the bug.

With current CVS (emacs -q), it breaks after less than 20 prompts when
debugging lilypond

    M-x gdb
    gdb --annotate=2 lily/out/lilypond

(btw, why does M-x gdb guess the name of the executable?  I find that
 annoying, as it is often something like config.status)

    Current directory is /home/janneke/lily/lily/out/
    GNU gdb 6.1-debian
    Copyright 2004 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 "i386-linux"...Using host libthread_db library "/lib/libthread_db.so.1".

    (gdb) b main
    Breakpoint 1 at 0x81742a0: file main.cc, line 463.
    (gdb) r
    Starting program: /var/fred/cvs/savannah/lilypond/lilypond/lily/out/lilypond 
    [Thread debugging using libthread_db enabled]
    [New Thread 16384 (LWP 1314)]
    [Switching to Thread 16384 (LWP 1314)]

    Breakpoint 1, main (argc=1, argv=0xbfffeb04) at main.cc:463
    (gdb) n

17 times RET gives

    (gdb) 
    ^done,changelist=[]
    (gdb) 
    (gdb) list
    ^done,changelist=[]
    (gdb) 
    (gdb) up 
    ^done,changelist=[]
    (gdb) 
    (gdb) up 100
    ^done,changelist=[]
    (gdb) 
    (gdb) p argc
    ^done,changelist=[]
    (gdb) 
    (gdb) info break
    ^done,changelist=[]

*Messages* says:

    error in process filter: gdb-starting: Unexpected `starting' annotation
    error in process filter: Unexpected `starting' annotation
    error in process filter: gdb-stopped: Unexpected stopped annotation
    error in process filter: Unexpected stopped annotation


Jan.

-- 
Jan Nieuwenhuizen <janneke@gnu.org> | GNU LilyPond - The music typesetter
http://www.xs4all.nl/~jantien       | http://www.lilypond.org

gud breakage: ^done,changelist=[]

[Nick Roberts]

 > Anyone using gud from CVS?  It has been broken for me for quite some
 > time now, but it used to break `only' after about 100 prompts or so;
 > usually enough to nail the bug.

It can only help us if you report the bug when you first find it.

 > With current CVS (emacs -q), it breaks after less than 20 prompts when
 > debugging lilypond

There haven't been any significant changes in this code for the last three
months or so. Perhaps its breaking earlier because liypond has changed.
 
 >     M-x gdb
 >     gdb --annotate=2 lily/out/lilypond

That's odd because gud has used "--annotate=3" for over a year. However, it
shouldn't make any difference at the moment.

 ...
 >     (gdb) b main
 >     Breakpoint 1 at 0x81742a0: file main.cc, line 463.
 >     (gdb) r
 >     Starting program: /var/fred/cvs/savannah/lilypond/lilypond/lily/out/lilypond 
 >     [Thread debugging using libthread_db enabled]
 >     [New Thread 16384 (LWP 1314)]
 >     [Switching to Thread 16384 (LWP 1314)]

C++ and multithreaded, that might be pushing it a bit. If you don't use any
features of the new mode you can get the old behaviour using "gdb -fullname"
(read the debugger section in the Emacs manual).

 >     Breakpoint 1, main (argc=1, argv=0xbfffeb04) at main.cc:463
 >     (gdb) n
 > 
 > 17 times RET gives
 > 
 >     (gdb) 
 >     ^done,changelist=[]
 >     (gdb) 
 >     (gdb) list
 >     ^done,changelist=[]
 ...

It appears to have lost an annotation somewhere and can't recover. It is
probably the mode but it could also be that GDB fails to emit the right
annotation under this particular circumstance.

Please set the variable gdb-enable-debug-log (which records the transactions
between gdb and emacs) to t, trigger the bug and post the value of
gdb-debug-log to emacs-pretest-bugs.

Nick

Re: gud breakage: ^done,changelist=[]

[Jan Nieuwenhuizen]

[-- Attachment #1: Type: text/plain, Size: 1083 bytes --]

Nick Roberts writes:

> It can only help us if you report the bug when you first find it.

Of course, I am sorry.  I usually do, except with emacs+gdb I assumed
that everyone and his dog would suffer from it (duh).

> That's odd because gud has used "--annotate=3" for over a year. However, it
> shouldn't make any difference at the moment.

--annotate=3 has the same problem.  I seem to remember that bringing
up a third window, so I mindlessly switch that off.

> C++ and multithreaded, that might be pushing it a bit. If you don't use any
> features of the new mode you can get the old behaviour using "gdb -fullname"

Thanks, that works!  LilyPond is not multithreaded.  It might be
because of linking to guile, which supports threads?

> Please set the variable gdb-enable-debug-log (which records the transactions
> between gdb and emacs) to t, trigger the bug and post the value of
> gdb-debug-log to emacs-pretest-bugs.

Done.

Jan.

-- 
Jan Nieuwenhuizen <janneke@gnu.org> | GNU LilyPond - The music typesetter
http://www.xs4all.nl/~jantien       | http://www.lilypond.org


[-- Attachment #2: session --]
[-- Type: application/octet-stream, Size: 1086 bytes --]

using lilypond, emacs CVS

emacs -q
M-x gdb
gdb --annotate=3 lily/out/lilypond

Current directory is /home/janneke/lily/lily/out/
GNU gdb 6.1-debian
Copyright 2004 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 "i386-linux"...Using host libthread_db library "/lib/libthread_db.so.1".

(gdb) b main
Breakpoint 1 at 0x81742a0: file main.cc, line 463.
(gdb) r
Starting program: /var/fred/cvs/savannah/lilypond/lilypond/lily/out/lilypond 
[Thread debugging using libthread_db enabled]
[New Thread 16384 (LWP 3986)]
[Switching to Thread 16384 (LWP 3986)]

Breakpoint 1, main (argc=1, argv=0xbfffeb04) at main.cc:463
(gdb) n
(gdb) 
(gdb) 
(gdb) 

(gdb) 
^done,changelist=[]
(gdb) 
(gdb) p argc
^done,changelist=[]
(gdb) 
(gdb) up
^done,changelist=[]
(gdb) 
(gdb) info break
^done,changelist=[]
(gdb) 
(gdb) 

[-- Attachment #3: gdb-debug-log.gz --]
[-- Type: application/octet-stream, Size: 3750 bytes --]

[-- Attachment #4: Type: text/plain, Size: 142 bytes --]

_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-devel

Re: gud breakage: ^done,changelist=[]

[Kim F. Storm]

Jan Nieuwenhuizen <janneke@gnu.org> writes:

> Nick Roberts writes:
>
>> It can only help us if you report the bug when you first find it.
>
I also see the flood of frames-invalid from time to time when
debugging emacs -- I reported that a long time ago.

Seems to be a problem with gdb according to Nick.


\x1a\x1apre-prompt
(gdb) 
\x1a\x1aprompt
") (recv . "
\x1a\x1aframes-invalid

\x1a\x1aframes-invalid

\x1a\x1aframes-invalid

\x1a\x1aframes-invalid

\x1a\x1aframes-invalid

\x1a\x1aframes-invalid

\x1a\x1aframes-invalid

\x1a\x1aframes-invalid

\x1a\x1aframes-invalid

\x1a\x1aframes-invalid

\x1a\x1aframes-invalid

\x1a\x1aframes-invalid

\x1a\x1aframes-invalid

\x1a\x1aframes-invalid

\x1a\x1aframes-invalid

\x1a\x1aframes-invalid

\x1a\x1aframes-invalid

\x1a\x1aframes-invalid

\x1a\x1abreakpoints-invalid



-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk

Re: gud breakage: ^done,changelist=[]

[Jan Nieuwenhuizen]

Kim F. Storm writes:

> I also see the flood of frames-invalid from time to time when
> debugging emacs -- I reported that a long time ago.
>
> Seems to be a problem with gdb according to Nick.

Ok, but gdb -fullname is fine.  If gdb is not going to be fixed soon,
maybe this should be documented with Emacs?

Jan.

-- 
Jan Nieuwenhuizen <janneke@gnu.org> | GNU LilyPond - The music typesetter
http://www.xs4all.nl/~jantien       | http://www.lilypond.org

Re: gud breakage: ^done,changelist=[]

[Nick Roberts]

 
> > I also see the flood of frames-invalid from time to time when
 > > debugging emacs -- I reported that a long time ago.
 > >
 > > Seems to be a problem with gdb according to Nick.
 > 
 > Ok, but gdb -fullname is fine.  If gdb is not going to be fixed soon,
 > maybe this should be documented with Emacs?

I'm not sure where the problem is. Hopefully, the full output log of this case
will resolve the matter.

Nick

Re: gud breakage: ^done,changelist=[]

[Richard Stallman]

    With current CVS (emacs -q), it breaks after less than 20 prompts when
    debugging lilypond

This is good progress.  The sooner the bug strikes, the more chance of
debugging it ;-).

Re: gud breakage: ^done,changelist=[]

[Nick Roberts]

 > I also see the flood of frames-invalid from time to time when
 > debugging emacs -- I reported that a long time ago.
 > 

Having looked at Jan's log, I think I know what is happening now.  I think the
problem occurs when the user enters the next gdb command before the previous
one has finished. This real-time aspect to the problem would explain why the
bug might be hard to reproduce. 

Jan, can you tell me if the bug is still there, even if you step through
lilypond slowly.

So, in the short term, with care (albeit tedious), this problem should be
avoidable. In the longer term, I'll try to sort it.

Nick



FWIW, the offending code is:

(defun gdb-send (proc string)
  "A comint send filter for gdb.
This filter may simply queue output for a later time."
  (if gud-running
      (process-send-string proc (concat string "\n")
    (gdb-enqueue-input (concat string "\n")))

If gud-running is non-nil, the input jumps the code. This was meant to
allow input to the inferior, but will also occur if the user has fast
fingers e.g presses <RET> before the previous step has finished.

Re: gud breakage: ^done,changelist=[]

[Kim F. Storm]

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

>  > I also see the flood of frames-invalid from time to time when
>  > debugging emacs -- I reported that a long time ago.
>  > 
>
> Having looked at Jan's log, I think I know what is happening now.  I think the
> problem occurs when the user enters the next gdb command before the previous
> one has finished.

I think that can explain something I now recall I've seen:

If the program is running, and I do C-x C-a C-t to set a breakpoint
things go ...

> So, in the short term, with care (albeit tedious), this problem should be
> avoidable.

The above "mistake" is easy to make.


-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk

Re: gud breakage: ^done,changelist=[]

[Jan Nieuwenhuizen]

Nick Roberts writes:

> Jan, can you tell me if the bug is still there, even if you step through
> lilypond slowly.

I cannot reproduce it if I step slowly.

Jan.

-- 
Jan Nieuwenhuizen <janneke@gnu.org> | GNU LilyPond - The music typesetter
http://www.xs4all.nl/~jantien       | http://www.lilypond.org

Re: gud breakage: ^done,changelist=[]

[Nick Roberts]

 > > So, in the short term, with care (albeit tedious), this problem should be
 > > avoidable.
 > 
 > The above "mistake" is easy to make.

When debugging programs which don't read from standard input, such as Emacs
(and Lilypond?) the conditional clause in gdb-send can be removed:

(defun gdb-send (proc string)
  "A comint send filter for gdb.
This filter may simply queue output for a later time."
    (gdb-enqueue-input (concat string "\n")))

This should eliminate the problem for such programs but will eventually hang
for those expecting input.

The general problem seems intractable because Emacs has no way of knowing if
input is going to gdb or the inferior. The original code (gdba.el) got round
the problem by always using a separate buffer for program input. Perhaps I
should do what Stefan suggested a while ago and create a lisp command,
gdb-resync, so that the user can recover control during a debug session and
all is not lost.

Nick

Re: gud breakage: ^done,changelist=[]

[Jan Nieuwenhuizen]

Nick Roberts writes:

> When debugging programs which don't read from standard input, such as Emacs
> (and Lilypond?) the conditional clause in gdb-send can be removed:

Yes, without the conditional I also cannot reproduce it.  (LilyPond
can act as a pseudo filter, but there's never the need to debug that
way.)

Jan.

-- 
Jan Nieuwenhuizen <janneke@gnu.org> | GNU LilyPond - The music typesetter
http://www.xs4all.nl/~jantien       | http://www.lilypond.org

Re: gud breakage: ^done,changelist=[]

[Stefan]

> The general problem seems intractable because Emacs has no way of knowing if
> input is going to gdb or the inferior.

Yes, gdb-ui would probably need to be more complex to try and resolve the
ambiguity: basically, send the text immediately (in case it's to be sent to
the debugged process) but don't rule out the possibility that it was maybe
sent to gdb: any code that would need to be run if the text was sent to gdb
should be added to a queue of maybe-pending-code, and then carefully analyze
the annotations you receive from gdb to try and infer what was sent to gdb
and what was sent to the debugged process.

In general it's still ambiguous anyway.

> The original code (gdba.el) got round the problem by always using
> a separate buffer for program input.

Yes, it's a much more reliable and straightforward solution.  I think
the only problem with it is how to avoid popping up an input/output buffer
if it's not going to be used.

Maybe what we should do is to always have a separate I/O buffer but only
pop-it up if the process sends output or if the user requests it via
gdb-view-inferior-io.

> Perhaps I should do what Stefan suggested a while ago and create a lisp
> command, gdb-resync, so that the user can recover control during a debug
> session and all is not lost.

Yes, I think this is still necessary to work around bugs/limitations in the
gdb-ui code.  But it's no match to actually fixing the problems ;-)


        Stefan