From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Miles Bader Newsgroups: gmane.emacs.bugs,gmane.emacs.pretest.bugs Subject: bug#2556: 23.0.91; gdb-ui sometimes messes up window handling Date: Tue, 03 Mar 2009 19:52:37 +0900 Message-ID: Reply-To: Miles Bader , 2556@emacsbugs.donarmstrong.com NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1236078432 9115 80.91.229.12 (3 Mar 2009 11:07:12 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 3 Mar 2009 11:07:12 +0000 (UTC) To: emacs-pretest-bug@gnu.org Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Tue Mar 03 12:08:29 2009 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.50) id 1LeSU7-0004Np-9d for geb-bug-gnu-emacs@m.gmane.org; Tue, 03 Mar 2009 12:08:28 +0100 Original-Received: from localhost ([127.0.0.1]:55813 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1LeSSm-0002B2-30 for geb-bug-gnu-emacs@m.gmane.org; Tue, 03 Mar 2009 06:07:04 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1LeSPc-000070-Dt for bug-gnu-emacs@gnu.org; Tue, 03 Mar 2009 06:03:48 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1LeSPa-00005c-Qz for bug-gnu-emacs@gnu.org; Tue, 03 Mar 2009 06:03:47 -0500 Original-Received: from [199.232.76.173] (port=56167 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1LeSPa-00005O-IS for bug-gnu-emacs@gnu.org; Tue, 03 Mar 2009 06:03:46 -0500 Original-Received: from rzlab.ucr.edu ([138.23.92.77]:60673) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1LeSPZ-0007HM-CP for bug-gnu-emacs@gnu.org; Tue, 03 Mar 2009 06:03:45 -0500 Original-Received: from rzlab.ucr.edu (rzlab.ucr.edu [127.0.0.1]) by rzlab.ucr.edu (8.13.8/8.13.8/Debian-3) with ESMTP id n23B3d4F007084; Tue, 3 Mar 2009 03:03:39 -0800 Original-Received: (from debbugs@localhost) by rzlab.ucr.edu (8.13.8/8.13.8/Submit) id n23B020U005830; Tue, 3 Mar 2009 03:00:02 -0800 X-Loop: owner@emacsbugs.donarmstrong.com Resent-From: Miles Bader Original-Sender: miles.bader@necel.com Resent-To: bug-submit-list@donarmstrong.com Resent-CC: Emacs Bugs Resent-Date: Tue, 03 Mar 2009 11:00:02 +0000 Resent-Message-ID: Resent-Sender: owner@emacsbugs.donarmstrong.com X-Emacs-PR-Message: report 2556 X-Emacs-PR-Package: emacs X-Emacs-PR-Keywords: Original-Received: via spool by submit@emacsbugs.donarmstrong.com id=B.12360775704316 (code B ref -1); Tue, 03 Mar 2009 11:00:02 +0000 Original-Received: (at submit) by emacsbugs.donarmstrong.com; 3 Mar 2009 10:52:50 +0000 X-Spam-Bayes: score:0.5 Bayes not run. spammytokens:Tokens not available. hammytokens:Tokens not available. Original-Received: from fencepost.gnu.org (fencepost.gnu.org [140.186.70.10]) by rzlab.ucr.edu (8.13.8/8.13.8/Debian-3) with ESMTP id n23AqjUt004307 for ; Tue, 3 Mar 2009 02:52:47 -0800 Original-Received: from mx10.gnu.org ([199.232.76.166]:40812) by fencepost.gnu.org with esmtp (Exim 4.67) (envelope-from ) id 1LeSCb-0000xz-Fz for emacs-pretest-bug@gnu.org; Tue, 03 Mar 2009 05:50:21 -0500 Original-Received: from Debian-exim by monty-python.gnu.org with spam-scanned (Exim 4.60) (envelope-from ) id 1LeSEs-0005Fq-1I for emacs-pretest-bug@gnu.org; Tue, 03 Mar 2009 05:52:44 -0500 Original-Received: from tyo201.gate.nec.co.jp ([202.32.8.193]:42511) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1LeSEr-0005FQ-3L; Tue, 03 Mar 2009 05:52:41 -0500 Original-Received: from relay21.aps.necel.com ([10.29.19.50]) by tyo201.gate.nec.co.jp (8.13.8/8.13.4) with ESMTP id n23AqbCK022957; Tue, 3 Mar 2009 19:52:37 +0900 (JST) Original-Received: from relay11.aps.necel.com ([10.29.19.20] [10.29.19.20]) by relay21.aps.necel.com with ESMTP; Tue, 3 Mar 2009 19:52:37 +0900 Original-Received: from dhlpc061 ([10.114.112.240] [10.114.112.240]) by relay11.aps.necel.com with ESMTP; Tue, 3 Mar 2009 19:52:37 +0900 Original-Received: by dhlpc061 (Postfix, from userid 31295) id 4197A52E259; Tue, 3 Mar 2009 19:52:37 +0900 (JST) System-Type: x86_64-unknown-linux-gnu Blat: Foop Original-Lines: 223 X-detected-operating-system: by monty-python.gnu.org: Solaris 8 (1) X-detected-operating-system: by monty-python.gnu.org: GNU/Linux 2.6 (newer, 3) Resent-Date: Tue, 03 Mar 2009 06:03:47 -0500 X-BeenThere: bug-gnu-emacs@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.bugs:25936 gmane.emacs.pretest.bugs:24051 Archived-At: Please describe exactly what actions triggered the bug and the precise symptoms of the bug: This is an old bug with gdb-ui that seems to have been forgotten (but is still present though; it bites me regularly); the basic symptom is that sometimes when you type a command to a gud debugger prompt, and gud pops up an associated source code buffer, the source code buffer will be displayed in the same window where your gud session buffer was displayed, resulting in the gud buffer being hidden! Here's the test case I gave (starting with emacs -Q): (1) start a gdb session in emacs, and hit a breakpoint or something so that gdb pops up the source in another window (splitting the frame) (2) Switch to the source window with "C-x o" (3) Delete the other [*gud...*] window with "C-x 1" (4) Switch back to the *gud...* buffer using "C-x b *gud...* RET" (5) Try to pop up the source buffer again using a gdb command, e.g., just "frame RET". *bang*, *gdb...* buffer disappears, source buffer is only ting displayed... :-( That text is from an old emacs-devel thread (Message-Id is ). Here is the text of some of the subsequent messages in that thread: > From: Nick Roberts OK. When you do (4) you put the GUD buffer in the window that gdb-source-window points to. So when you do 'f' gdb-ui thinks the source should go there. I'm not sure what I can do as commands like switch-to-buffer are built-in. Maybe some kind of hook in window-size-change-functions to keep gdb-ui up-to-date. Or perhaps having window groups would make it impossible to switch the source buffer for the GUD buffer if they were assigned to different groups. > From: Miles Bader gud/gdb-ui shouldn't be storing window references like that and assuming the associated buffer hasn't been changed by the user, because that's an assumption that doesn't hold in emacs. Perhaps that code is left over from the "old" gdb-ui which used dedicated windows? A possible fix would be to store the buffer gdb puts in that window, and when deciding whether to re-use that window or, also verify that the same buffer is there (and don't re-use the window if not). > From: Nick Roberts gdb-ui _does_ store the (source) buffer it puts in the window. That's why when you replace it with the GUD buffer using switch-to-buffer (not part of gdb-ui) it gets confused. It could verify that the same buffer is there but the contents of the source window change every time the program being debugged stops in a frame that is in a different file and gdb-ui must allow for this. If the current window shows the previous frame and execution is continued (from the tool bar, say) so that it stops in another frame in a different file, then it's probably appropriate to replace the entire window with one displaying the new file. I'm not saying it that can't be done but it's probably more productive to discuss these ideas with actual code. > From: Miles Bader > It could verify that the same buffer is there but the contents of > the source window change every time the program being debugged > stops in a frame that is in a different file and gdb-ui must allow > for this. Why is this a problem? In such cases, the source buffer should get changed via gdb-display-source-buffer, which will update the associated source-file, right? In other words, it seems that as long as gud is the one doing the updating of the source window, everything will remain consistent, and it will keep using that window. It would only be if some external agent changes what's displayed in that window that the state would become inconsistent -- and in that case, it's probably the right thing to do to pop up a new window (which will become the new source window). Anyway, I can make the obvious change and see if it feels funny. > From: Nick Roberts > Why is this a problem? In such cases, the source buffer should > get changed via gdb-display-source-buffer, which will update the > associated source-file, right? It needs to distinguish between cases when it is appropriate to replace the entire window with one displaying the new file, as described previously and when it isn't, as in your example. > Anyway, I can make the obvious change and see if it feels funny. Sure. If there are problems it can easily be reverted. It might be a good idea to start by not making the windows dedicated then perhaps David Hansen can say if that cures his use case. > From: Miles Bader > Sure. If there are problems it can easily be reverted. It might > be a good idea to start by not making the windows dedicated then > perhaps David Hansen can say if that cures his use case. At least in my case, the windows _aren't_ dedicated. I'm not using the 57-window gdb-ui variant, I'm just using M-x gdb RET. [That's may be part of what's going on actually -- the current mechanism feels like it was written expecting the windows to be dedicated.] If Emacs crashed, and you have the Emacs process in the gdb debugger, please include the output from the following gdb commands: `bt full' and `xbacktrace'. If you would like to further debug the crash, please read the file /usr/local/share/emacs/23.0.91/etc/DEBUG for instructions. In GNU Emacs 23.0.91.7 (x86_64-unknown-linux-gnu, GTK+ Version 2.14.7) of 2009-03-03 on dhlpc061 Windowing system distributor `The X.Org Foundation', version 11.0.10503000 Important settings: value of $LC_ALL: nil value of $LC_COLLATE: nil value of $LC_CTYPE: nil value of $LC_MESSAGES: nil value of $LC_MONETARY: nil value of $LC_NUMERIC: nil value of $LC_TIME: nil value of $LANG: ja_JP.UTF-8 value of $XMODIFIERS: @im=SCIM locale-coding-system: utf-8-unix default-enable-multibyte-characters: t Major mode: Article Minor modes in effect: shell-dirtrack-mode: t buffer-face-mode: t show-paren-mode: t recentf-mode: t rcirc-track-minor-mode: t minibuffer-electric-default-mode: t display-time-mode: t desktop-save-mode: t tooltip-mode: t mouse-wheel-mode: t file-name-shadow-mode: t global-font-lock-mode: t font-lock-mode: t global-auto-composition-mode: t auto-composition-mode: t auto-encryption-mode: t auto-compression-mode: t temp-buffer-resize-mode: t line-number-mode: t transient-mark-mode: t Recent input: C-p C-p C-p C-p C-p C-p C-p C-p C-p C-p C-p C-p C-p C-p C-p C-n C-n C-n C-n C-n C-n C-u C-p C-u C-p C-p C-p C-u C-p C-u C-p C-p C-u C-p C-u C-p C-u C-p C-u C-p C-u C-p C-u C-p C-n C-n SPC n n SPC n n n q C-p c y c y C-u C-p C-u C-p C-v C-n C-n C-n C-n C-n C-n C-n C-x b * g u SPC C-x b C-p C-r e m a c s C-a C-p C-p C-p 5 0 0 0 = C-s g d b C-r C-r C-r C-r C-r C-r C-r C-r C-a C-a C-a C-a C-a C-u C-g > C-a C-r g u d C-r C-a q C-p C-u C-p C-p 1 0 0 0 0 = C-s g d b C-s C-s C-s C-s C-a C-n C-n C-n C-n C-p SPC C-s C-s C-a C-x 1 C-v C-n C-n C-n C-n SPC N N N N N N P P P i P i C-x 5 2 C-h f g d b - s o SPC - w SPC h h s e t SPC - w SPC C-x n C-x 1 C-x n C-x n P N N N N P P P P P C-x p C-n C-n C-n C-SPC C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n w x C-x n C-u C-SPC C-u C-SPC C-v C-v < / w C-a C-u C-SPC C-u C-SPC C-a C-s g d b C-a C-v C-v C-v C-s C-s C-s C-s C-a C-v C-v C-s C-s C-a C-v C-x p x r e p o r t SPC Recent messages: Mark set Auto-saving...done Saved text from "Ah, actually I can reproduce it with "em" Follow the link. Generating summary...done Mark popped Mark set Generating summary...done Mark popped Mark saved where search started [3 times] -- "Suppose He doesn't give a shit? Suppose there is a God but He just doesn't give a shit?" [George Carlin]