Re: Problems with gdb-ui.

[storm@cua.dk (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