bug#2556: 23.0.91; gdb-ui sometimes messes up window handling

[Miles Bader]

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
<buoy74c7sjh.fsf@dhapc248.dev.necel.com>).

Here is the text of some of the subsequent messages in that thread:


  > From: Nick Roberts <nickrob@snap.net.nz>

    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 <miles@gnu.org>

    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 <nickrob@snap.net.nz>

    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 <miles@gnu.org>

    > 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 <nickrob@snap.net.nz>

    > 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 <miles@gnu.org>

    > 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 <return> C-x b <return> 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 
<escape> > 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 <switch-frame> C-h 
f g d b - s o SPC - w SPC <escape> h <escape> h s e 
t SPC - w SPC <return> C-x n <tab> <return> C-x 1 <switch-frame> 
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 <escape> w <tab> x C-x n C-u C-SPC 
C-u C-SPC C-v C-v <escape> < / 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 <escape> x r e p 
o r t SPC <return>

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]