Problems with gdb-ui.

Problems with gdb-ui.

[Kim F. Storm]

At times, I have had BIG problems with emacs behaving very strangely
if gdb is running (or has been running).  

For example, I cannot easily C-g out of the minibuffer and bogus
stuff seems to be written to the minibuffer (but I'm not sure).

Also emacs once hung retrieving POP mail.

Enabling debugging gets this result in gdb-debug-log:

((recv . "\n\x1a\x1aframes-invalid\n")
 (recv . "\n\x1a\x1aframes-invalid\n")
 (recv . "\n\x1a\x1aframes-invalid\n\n\x1a\x1aframes-invalid\n")
 (recv . "\n\x1a\x1aframes-invalid\n")
 ...  continues forever ...

the partial output buffer contains:

        Undefined command: "interpreter".  Try "help".


My GDB is the one that came with redhat 9.0:

GNU gdb Red Hat Linux (5.3post-0.20021129.18rh)
Copyright 2003 Free Software Foundation, Inc.



Re. the minibuffer problems, I don't really know what's going on,
but could it be that some process filter does (set-buffer nil)
and thus throw an error, and then strange things happen with
quit or something...  [for an example where that could happen,
see code below, there's no check that buffer is non-nil here]

(defun gdb-assembler-custom ()
  (let ((buffer (gdb-get-buffer 'gdb-assembler-buffer))
	(pos 1) (address) (flag))
    (with-current-buffer buffer
      (if (not (equal gdb-current-address "main"))
	  (progn
	    (goto-char (point-min))
	    (if (re-search-forward gdb-current-address nil t)
		(progn
		  (setq pos (point))
		  (beginning-of-line)
		  (or gdb-overlay-arrow-position
		      (setq gdb-overlay-arrow-position (make-marker)))
		  (set-marker gdb-overlay-arrow-position
			      (point) (current-buffer))))))
      ;; remove all breakpoint-icons in assembler buffer before updating.
      (gdb-remove-breakpoint-icons (point-min) (point-max)))
    (with-current-buffer (gdb-get-buffer 'gdb-breakpoints-buffer)
      (goto-char (point-min))


When emacs "hung" in POP mail retrieval, the following backtrace
tells me something is bad in gdb:

(gdb) xbacktrace
"gdb-look-for-tagged-buffer"
"gdb-get-buffer"
"gdb-get-create-buffer"
"gdb-append-to-partial-output"
"gdb-concat-output"
"gud-gdba-marker-filter"
"apply"
"gud-marker-filter"
"gud-filter"
"accept-process-output"
"pop3-read-response"
"pop3-open-server"
"pop3-movemail"
"mail-source-fetch-pop"
"funcall"
"mail-source-fetch"
"nnmail-get-new-mail"
"nnml-request-scan"
"gnus-request-scan"
"gnus-read-active-file-1"
"gnus-read-active-file"
"gnus-group-get-new-news"
"call-interactively"



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

Problems with gdb-ui.

[Nick Roberts]

 > At times, I have had BIG problems with emacs behaving very strangely
 > if gdb is running (or has been running).  
 >
 > For example, I cannot easily C-g out of the minibuffer and bogus
 > stuff seems to be written to the minibuffer (but I'm not sure).
 > 
 > Also emacs once hung retrieving POP mail.

I've no great ideas but I can make suggestions.

 > Enabling debugging gets this result in gdb-debug-log:
 > 
 > ((recv . "\n\x1a\x1aframes-invalid\n")
 >  (recv . "\n\x1a\x1aframes-invalid\n")
 >  (recv . "\n\x1a\x1aframes-invalid\n\n\x1a\x1aframes-invalid\n")
 >  (recv . "\n\x1a\x1aframes-invalid\n")
 >  ...  continues forever ...

That's strange. I would have thought that GDB must be sending something
for that to happen, so that the list had elements like:

   (send . "foo\n")

 > the partial output buffer contains:
 > 
 >         Undefined command: "interpreter".  Try "help".

This is because emacs is trying to access GDB's machine interface (GDB/MI)
which only works in 6.0 onwards. I suspect that the speedbar is present 
(gdb-var-update executes) or you have either tried gud-watch. This output
might not relate to the error but you could try deleting the speedbar or
updating to GDB 6.0 (Fedora has it, I think) or 6.1. This has the benefit
of providing watch expressions if you want them.
 > 
 > My GDB is the one that came with redhat 9.0:
 > 
 > GNU gdb Red Hat Linux (5.3post-0.20021129.18rh)
 > Copyright 2003 Free Software Foundation, Inc.
 > 
 > 
 > 
 > Re. the minibuffer problems, I don't really know what's going on,
 > but could it be that some process filter does (set-buffer nil)
 > and thus throw an error, and then strange things happen with
 > quit or something...  [for an example where that could happen,
 > see code below, there's no check that buffer is non-nil here]
 > 
 > (defun gdb-assembler-custom ()
 >   (let ((buffer (gdb-get-buffer 'gdb-assembler-buffer))
 > 	(pos 1) (address) (flag))
 >     (with-current-buffer buffer
 >       (if (not (equal gdb-current-address "main"))
 > 	  (progn
 > 	    (goto-char (point-min))
 > 	    (if (re-search-forward gdb-current-address nil t)
 > 		(progn
 > 		  (setq pos (point))
 > 		  (beginning-of-line)
 > 		  (or gdb-overlay-arrow-position
 > 		      (setq gdb-overlay-arrow-position (make-marker)))
 > 		  (set-marker gdb-overlay-arrow-position
 > 			      (point) (current-buffer))))))
 >       ;; remove all breakpoint-icons in assembler buffer before updating.
 >       (gdb-remove-breakpoint-icons (point-min) (point-max)))
 >     (with-current-buffer (gdb-get-buffer 'gdb-breakpoints-buffer)
 >       (goto-char (point-min))

I think buffer should always be non-nil here, unless it has been deleted by the
user. You could try replacing gdb-get-buffer with gdb-get-create-buffer.
 
 > 
 > When emacs "hung" in POP mail retrieval, the following backtrace
 > tells me something is bad in gdb:
 > 
 > (gdb) xbacktrace
 > "gdb-look-for-tagged-buffer"
 > "gdb-get-buffer"
 > "gdb-get-create-buffer"
 > "gdb-append-to-partial-output"
 > "gdb-concat-output"
 > "gud-gdba-marker-filter"
 > "apply"
 > "gud-marker-filter"
 > "gud-filter"
 > "accept-process-output"
 > "pop3-read-response"
 > "pop3-open-server"
 > "pop3-movemail"
 > "mail-source-fetch-pop"
 > "funcall"
 > "mail-source-fetch"
 > "nnmail-get-new-mail"
 > "nnml-request-scan"
 > "gnus-request-scan"
 > "gnus-read-active-file-1"
 > "gnus-read-active-file"
 > "gnus-group-get-new-news"
 > "call-interactively"

It looks like the process filter for pop3 has been set to gud-filter. This
presumably could also be something is bad in pop3.

Nick

Re: Problems with gdb-ui.

[Kim F. Storm]

Nick Roberts <nickrob@gnu.org> writes:

>  >  (recv . "\n\x1a\x1aframes-invalid\n")
>  >  ...  continues forever ...
> 
> That's strange. I would have thought that GDB must be sending something
> for that to happen, so that the list had elements like:
> 
>    (send . "foo\n")

I will try to turn on debug before starting gdb -- then we might be able
to see what started this mess...

> 
>  > the partial output buffer contains:
>  > 
>  >         Undefined command: "interpreter".  Try "help".
> 
> This is because emacs is trying to access GDB's machine interface (GDB/MI)
> which only works in 6.0 onwards. I suspect that the speedbar is present 
> (gdb-var-update executes) or you have either tried gud-watch. 

Neither.

I just started M-x gdb on emacs, and did r -q.  I might have stopped it
once with C-c C-z and then continued it with c.


> updating to GDB 6.0 (Fedora has it, I think) or 6.1. This has the benefit
> of providing watch expressions if you want them.

I will try that.


>  > 
>  > My GDB is the one that came with redhat 9.0:
>  > 
>  > GNU gdb Red Hat Linux (5.3post-0.20021129.18rh)
>  > Copyright 2003 Free Software Foundation, Inc.
>  > 
>  > 
>  > 
>  > Re. the minibuffer problems, I don't really know what's going on,
>  > but could it be that some process filter does (set-buffer nil)
>  > and thus throw an error, and then strange things happen with
>  > quit or something...  [for an example where that could happen,
>  > see code below, there's no check that buffer is non-nil here]
>  > 
>  > (defun gdb-assembler-custom ()
>  >   (let ((buffer (gdb-get-buffer 'gdb-assembler-buffer))
>  > 	(pos 1) (address) (flag))
>  >     (with-current-buffer buffer
>  >       (if (not (equal gdb-current-address "main"))
>  > 	  (progn
>  > 	    (goto-char (point-min))
>  > 	    (if (re-search-forward gdb-current-address nil t)
>  > 		(progn
>  > 		  (setq pos (point))
>  > 		  (beginning-of-line)
>  > 		  (or gdb-overlay-arrow-position
>  > 		      (setq gdb-overlay-arrow-position (make-marker)))
>  > 		  (set-marker gdb-overlay-arrow-position
>  > 			      (point) (current-buffer))))))
>  >       ;; remove all breakpoint-icons in assembler buffer before updating.
>  >       (gdb-remove-breakpoint-icons (point-min) (point-max)))
>  >     (with-current-buffer (gdb-get-buffer 'gdb-breakpoints-buffer)
>  >       (goto-char (point-min))
> 
> I think buffer should always be non-nil here, unless it has been deleted by the
> user. You could try replacing gdb-get-buffer with gdb-get-create-buffer.

I didn't have an assembler buffer, so maybe it's not relevant -- I don't
know the details of the gdb-ui package, and would prefer not having to
mess too much with it.

Instead of the above, I just did this simple trick instead (added near
the top of gdb-ui.el):

I don't know yet if that solves the problem, but I'll let you know
if I see the strange behaviour again.

! 
! (defmacro with-current-buffer (buffer &rest body)
!   "Execute the forms in BODY with BUFFER as the current buffer.
! The value returned is the value of the last form in BODY.
! See also `with-temp-buffer'."
!   (declare (indent 1) (debug t))
!   `(let ((b ,buffer))
!      (if b
! 	 (save-current-buffer
! 	   (set-buffer b)
! 	   ,@body))))
! 
! 

>  
>  > 
>  > When emacs "hung" in POP mail retrieval, the following backtrace
>  > tells me something is bad in gdb:
>  > 
>  > (gdb) xbacktrace
>  > "gdb-look-for-tagged-buffer"
>  > "gdb-get-buffer"
>  > "gdb-get-create-buffer"
>  > "gdb-append-to-partial-output"
>  > "gdb-concat-output"
>  > "gud-gdba-marker-filter"
>  > "apply"
>  > "gud-marker-filter"
>  > "gud-filter"
>  > "accept-process-output"
>  > "pop3-read-response"
>  > "pop3-open-server"
>  > "pop3-movemail"
>  > "mail-source-fetch-pop"
>  > "funcall"
>  > "mail-source-fetch"
>  > "nnmail-get-new-mail"
>  > "nnml-request-scan"
>  > "gnus-request-scan"
>  > "gnus-read-active-file-1"
>  > "gnus-read-active-file"
>  > "gnus-group-get-new-news"
>  > "call-interactively"
> 
> It looks like the process filter for pop3 has been set to gud-filter. This
> presumably could also be something is bad in pop3.

I don't think that conclusion is correct.  pop3-read-response calls
accept-process-output which will accept any kind of process output,
including that of other processes such as gdb.

The problem is that the gud-filter 
a) never returns, or

b) is called repeatedly [because the frames-invalid notifications
   are received ad infinitum].

It might be b (meaning that emacs is not really hung).

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