[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Problems with gdb-ui.
From: |
Nick Roberts |
Subject: |
Problems with gdb-ui. |
Date: |
Tue, 22 Jun 2004 19:08:56 +0100 |
> 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 . "\nframes-invalid\n")
> (recv . "\nframes-invalid\n")
> (recv . "\nframes-invalid\n\nframes-invalid\n")
> (recv . "\nframes-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