unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: Nick Roberts <nickrob@gnu.org>
Cc: emacs-devel@gnu.org
Subject: Problems with gdb-ui.
Date: Tue, 22 Jun 2004 19:08:56 +0100	[thread overview]
Message-ID: <16600.30136.663196.164898@nick.uklinux.net> (raw)
In-Reply-To: <m38yeggg9p.fsf@kfs-l.imdomain.dk>

 > 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

  reply	other threads:[~2004-06-22 18:08 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-06-22  8:15 Problems with gdb-ui Kim F. Storm
2004-06-22 18:08 ` Nick Roberts [this message]
2004-06-23  7:51   ` Kim F. Storm

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=16600.30136.663196.164898@nick.uklinux.net \
    --to=nickrob@gnu.org \
    --cc=emacs-devel@gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).