From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: storm@cua.dk (Kim F. Storm) Newsgroups: gmane.emacs.devel Subject: Re: Problems with gdb-ui. Date: 23 Jun 2004 09:51:25 +0200 Sender: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Message-ID: References: <16600.30136.663196.164898@nick.uklinux.net> NNTP-Posting-Host: deer.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit X-Trace: sea.gmane.org 1087977508 17127 80.91.224.253 (23 Jun 2004 07:58:28 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Wed, 23 Jun 2004 07:58:28 +0000 (UTC) Cc: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Wed Jun 23 09:58:17 2004 Return-path: Original-Received: from quimby.gnus.org ([80.91.224.244]) by deer.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 1Bd2e9-0007vz-00 for ; Wed, 23 Jun 2004 09:58:17 +0200 Original-Received: from lists.gnu.org ([199.232.76.165]) by quimby.gnus.org with esmtp (Exim 3.35 #1 (Debian)) id 1Bd2e9-0006LB-00 for ; Wed, 23 Jun 2004 09:58:17 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.33) id 1Bd2fU-0006wh-V8 for emacs-devel@quimby.gnus.org; Wed, 23 Jun 2004 03:59:41 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.33) id 1Bd2fS-0006wc-Hw for emacs-devel@gnu.org; Wed, 23 Jun 2004 03:59:38 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.33) id 1Bd2fP-0006wO-Ra for emacs-devel@gnu.org; Wed, 23 Jun 2004 03:59:38 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.33) id 1Bd2fP-0006wL-M7 for emacs-devel@gnu.org; Wed, 23 Jun 2004 03:59:35 -0400 Original-Received: from [212.88.64.25] (helo=mail-relay.sonofon.dk) by monty-python.gnu.org with smtp (Exim 4.34) id 1Bd2df-0001Xk-Mk for emacs-devel@gnu.org; Wed, 23 Jun 2004 03:57:48 -0400 Original-Received: (qmail 9654 invoked from network); 23 Jun 2004 07:51:04 -0000 Original-Received: from unknown (HELO kfs-l.imdomain.dk.cua.dk) (213.83.150.2) by 0 with SMTP; 23 Jun 2004 07:51:04 -0000 Original-To: Nick Roberts In-Reply-To: <16600.30136.663196.164898@nick.uklinux.net> Original-Lines: 142 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.3.50 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.4 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Xref: main.gmane.org gmane.emacs.devel:25205 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:25205 Nick Roberts writes: > > (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") 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 http://www.cua.dk