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

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]

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

[Nick Roberts]

 > 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!

Reading through I follow your logic better this time but I would still
suggest that you provide the fix that you wish to see.  FWIW I'm not sure
that I've encountered this problem but I do often find that the overlay
arrow pops up in another frame when other source files are already in
buffers of their own.

-- 
Nick                                           http://www.inet.net.nz/~nickrob

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

[Miles Bader]

On Sun, Mar 8, 2009 at 11:06 AM, Nick Roberts <nickrob@snap.net.nz> wrote:
> Reading through I follow your logic better this time but I would still
> suggest that you provide the fix that you wish to see.  FWIW I'm not sure
> that I've encountered this problem but I do often find that the overlay
> arrow pops up in another frame when other source files are already in
> buffers of their own.

Right, I'm going to give it a try, just gotta wrap my head around the
various functions again (it's been a while).

-Miles

-- 
Do not taunt Happy Fun Ball.

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

[Alexandre BACQUART]

I'm bothered by this issue since years. I finally decided to take a
look. My usage of gdb in emacs is a bit different from the OP, but the
issue is almost the same.

In fact, I have gdb-many-windows set to t. I like debugging that way so
when gdb starts, I get the 6 windows layout and I keep it that way most
of the time. My issue (which in this regard is the same as the OP) is
that when I select a line in the stack frames window, the matching
source file is opened in the gdb buffer's window (the one showing gdb
command prompt at top-left on the initial layout). Any other command
leading gdb UI to show a source file does that too. This made me crazy
for years, but not anymore. Here's what I did, but first, my reasoning:

What I found is that the gdb buffer's window is not dedicated when I
launch the gdb command. If I select it and do :

  M-: (window-dedicated-p (selected-window))

The output was nil. All other GUD windows (stack, register,
breakpoint...) output t.

The fact that the gdb buffer's window is not dedicated is the reason of
this issue. So I searched for hours to make it dedicated ON LAUNCH.
Doing this after launching gdb is easy, but it has to be done each time
gdb is launched and this is very annoying.

I tried many things (gdb-mode-hook, advising functions...) without
success. As a last resort, I did something I never usually do because
it's ugly. But hey... I guess years of annoyance is enough. So yes, I
modified gdb-mi.el. Nothing big really, just a single line in the
gdb-setup-windows function, this one:

  (set-window-dedicated-p (selected-window) nil)

I replaced nil with t. And it works.

Why ? Well, I suppose that is old code assuming the selected window
holds a source buffer. But in fact it is not, at least on launch,
because you see, this function is called only in 2 places:

- in gdb-restore-windows
- in gdb-get-source-file


On launch, since my gdb-many-windows is t, gdb-restore-windows is
called. And before this function calls gdb-setup-windows, it does that
(copy-paste of the line):

  (switch-to-buffer gud-comint-buffer) ;Select the right window and
frame.

gud-comint-buffer being the gdb buffer. So when gdb-setup-windows is
called, it used (set-window-dedicated-p (selected-window) nil) on the
gdb buffer's window, not on a source file.

Now my issue is gone. BUT (and that is the reason I prefer to explain
what I did instead of providing a clean patch) I'm not sure my change
don't have bad side effects. After all, gdb-get-source-file also calls
gdb-setup-windows...

Well, that's it. In the hope that at least I clarified a bit the source
of the issue in the first place and that someone better than me in lisp
(not hard really!) will provide a clean patch, some day... ;)

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

[Noam Postavsky]

Alexandre BACQUART <tek512@gmail.com> writes:

> I'm bothered by this issue since years. I finally decided to take a
> look. My usage of gdb in emacs is a bit different from the OP, but the
> issue is almost the same.

Your description looks like Bug#22374 which I can reproduce in current
Emacs versions (26.1 and 27.0.50).

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

[Noam Postavsky]

tags 2556 + unreproducible
quit

Miles Bader <miles.bader@necel.com> writes:

> 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... :-(

I'm not able to reproduce this in more recent Emacs versions (I've
tested back to 24.3).

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

[Lars Ingebrigtsen]

Noam Postavsky <npostavs@gmail.com> writes:

> I'm not able to reproduce this in more recent Emacs versions (I've
> tested back to 24.3).

I'm therefore closing this bug report.  If this is still an issue in
recent Emacs versions, please respond to the debbugs address and we'll
reopen.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no