bug#30044: Emacs: Gud-mode: Debugging with gud: Window switching problem

bug#30044: Emacs: Gud-mode: Debugging with gud: Window switching problem

[Claus Fischer]

[-- Attachment #1: Type: text/plain, Size: 1043 bytes --]

Package: emacs
Version: all recent

Dear Emacs maintainers!

A few years ago, I filed a bug about debugging unter Emacs with
gud and gdb.

The problem is that often times when a halt at a breakpoint requires
a source file to load, the source file replaces the *gud-something*
buffer, which is extremely disruptive to the work flow. One expects
to continue typing in gud but finds oneself instead typing into some
source file buffer.

After more careful observation, I think that this problem occurs
especially when there's another * buffer, particularly the
*compilation* buffer, present.

This often occurs in my work setting: I fix a bug by editing the file,
I let emacs recompile (run make), I load the new binary into the
debugger and run it again.

Please forward this information to the gud-mode maintainers,
it might be helpful, and it might help many people who find this
behaviour quite disturbing.

Best regards

Claus

-- 
Claus Fischer <claus.fischer@clausfischer.com>
http://www.clausfischer.com/

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

bug#30044: Emacs: Gud-mode: Debugging with gud: Window switching problem

[Eli Zaretskii]

> Date: Tue, 9 Jan 2018 13:33:11 +0100
> From: Claus Fischer <claus.fischer@clausfischer.com>
> 
> A few years ago, I filed a bug about debugging unter Emacs with
> gud and gdb.
> 
> The problem is that often times when a halt at a breakpoint requires
> a source file to load, the source file replaces the *gud-something*
> buffer, which is extremely disruptive to the work flow. One expects
> to continue typing in gud but finds oneself instead typing into some
> source file buffer.

How do you invoke GDB?  Is it "M-x gdb RET" or "M-x gud-gdb RET"?  I
suggest to try the former, and if you already do that, try the command
"M-x gdb-many-windows RET" after the debugging session starts.  I also
suggest to start the debugger in a separate frame, and switch to the
original frame when you want to work on your windows you had before
starting the debugging session.

bug#30044: Emacs: Gud-mode: Debugging with gud: Window switching problem

[Claus Fischer]

[-- Attachment #1: Type: text/plain, Size: 2006 bytes --]

On Tue, Jan 09, 2018 at 08:44:01PM +0200, Eli Zaretskii wrote:
> > Date: Tue, 9 Jan 2018 13:33:11 +0100
> > From: Claus Fischer <claus.fischer@clausfischer.com>
> > 
> > A few years ago, I filed a bug about debugging unter Emacs with
> > gud and gdb.
> > 
> > The problem is that often times when a halt at a breakpoint requires
> > a source file to load, the source file replaces the *gud-something*
> > buffer, which is extremely disruptive to the work flow. One expects
> > to continue typing in gud but finds oneself instead typing into some
> > source file buffer.
> 
> How do you invoke GDB?  Is it "M-x gdb RET" or "M-x gud-gdb RET"?  I
> suggest to try the former, and if you already do that, try the command
> "M-x gdb-many-windows RET" after the debugging session starts.  I also
> suggest to start the debugger in a separate frame, and switch to the
> original frame when you want to work on your windows you had before
> starting the debugging session.

I do
  M-x gud-gdb RET
since I found the other not to work as I like; a few years ago, I
started it as M-x gdb but then something changed - I don't remember
what - and I changed to gud-gdb. What's the difference? I just tried
it, I think it's the separate i/o window, isn't it?
If so, I'll stick with gud-gdb. I want my debugging session in a
single frame, and stdio is not relevant for my programs.

I usually have many frames open, but gdb is started in just one, and
when it encounters a breakpoint, it splits the frame, and that suits
me just fine - except for it sometimes burying the gud window itself.
I don't think the behavious depends on there being multiple frames.
Is that what you are suggesting?

It's hard to reproduce, but it's annoying nevertheless. I do a lot of
work in the setting emacs - autoconf - gcc - gdb, and it's generally
very productive for work on server code.

Best regards,

Claus

-- 
Claus Fischer <claus.fischer@clausfischer.com>
http://www.clausfischer.com/

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

bug#30044: Emacs: Gud-mode: Debugging with gud: Window switching problem

[Eli Zaretskii]

> Date: Tue, 9 Jan 2018 21:58:47 +0100
> From: Claus Fischer <claus.fischer@clausfischer.com>
> Cc: 30044@debbugs.gnu.org
> 
> > How do you invoke GDB?  Is it "M-x gdb RET" or "M-x gud-gdb RET"?  I
> > suggest to try the former, and if you already do that, try the command
> > "M-x gdb-many-windows RET" after the debugging session starts.  I also
> > suggest to start the debugger in a separate frame, and switch to the
> > original frame when you want to work on your windows you had before
> > starting the debugging session.
> 
> I do
>   M-x gud-gdb RET
> since I found the other not to work as I like; a few years ago, I
> started it as M-x gdb but then something changed - I don't remember
> what - and I changed to gud-gdb. What's the difference? I just tried
> it, I think it's the separate i/o window, isn't it?
> If so, I'll stick with gud-gdb. I want my debugging session in a
> single frame, and stdio is not relevant for my programs.

"M-x gdb-many-windows" opens several windows, including the one for
I/O, but there are others (local variables, breakpoints, stack frames,
etc.).  More importantly, those windows are kept in their
configuration better than "M-x gud-gdb" does.  I do suggest to at
least try this.

> I usually have many frames open, but gdb is started in just one, and
> when it encounters a breakpoint, it splits the frame, and that suits
> me just fine - except for it sometimes burying the gud window itself.
> I don't think the behavious depends on there being multiple frames.
> Is that what you are suggesting?

I'm saying that if you have the source and the GUD windows in a
separate frame, then these windows don't interfere with your other
windows and don't mix with them.  So your annoyances will be much
smaller, ideally zero.

bug#30044: Emacs: Gud-mode: Debugging with gud: Window switching problem

[Noam Postavsky]

On Tue, Jan 9, 2018 at 7:33 AM, Claus Fischer
<claus.fischer@clausfischer.com> wrote:

> A few years ago, I filed a bug about debugging unter Emacs with
> gud and gdb.

Using a different email perhaps? I can't seem to find that bug.

Bug#2556 and Bug#22374 seem related, though I'm not sure if they are
the same so I won't merge.

> Please forward this information to the gud-mode maintainers,

There aren't any such people, as far as I know, apart from general
Emacs maintainers.

bug#30044: Emacs: Gud-mode: Debugging with gud: Window switching problem

[Claus Fischer]

[-- Attachment #1: Type: text/plain, Size: 3455 bytes --]

On Tue, Jan 09, 2018 at 10:39:25PM -0500, Noam Postavsky wrote:
> On Tue, Jan 9, 2018 at 7:33 AM, Claus Fischer
> <claus.fischer@clausfischer.com> wrote:
> 
> > A few years ago, I filed a bug about debugging unter Emacs with
> > gud and gdb.
> 
> Using a different email perhaps? I can't seem to find that bug.

My apologies - that was way back in 2009, and I forgot about the
details. In fact, I filed it as a bug report on Debian,
Bug No. 520647.

It's hard to follow up on those things when you're in the middle
of debugging something big, because the focus is on getting the
code running.

> Bug#2556 and Bug#22374 seem related, though I'm not sure if they are
> the same so I won't merge.
> 
> > Please forward this information to the gud-mode maintainers,
> 
> There aren't any such people, as far as I know, apart from general
> Emacs maintainers.

Well thanks a lot for your answer, I looked at both bugs, and they
seem both to be related.

Bug 2556 gives me an idea about a misunderstanding that might be at
the heart of the case. Up to now I thought that gud would select
the debugging buffer by looking at the buffer text, which is *gud...*
and select the window according to that text.

However (I hadn't looked at the lisp code and I'm not good at Lisp),
bug 2556 gives me the impression that gud mode stores a window id of
a window that is created in Emacs. That is, for me, a wholly new
line of thinking. That might explain the behaviour:

  * I run the program in xterm and it gives an error message

  * I have the file where I'm looking for the error in my Emacs;
    since that's the one I'm just working on
    (I have a single frame of Emacs at that time)

  * I run M-x gud-gdb and give the program name

  * I re-run the program once under gud to see if the error is
    reproducible, which it usually is
    (I have a record-replay facility in my program so if valgrind
    doesn't complain before, the program is fully deterministic.)

  * I switch to the buffer with the source code in order to set the
    break point - at this point, I usually switch buffer in the
    original frame - gud buffer is no longer visible

  * I type C-x a b to set the breakpoint

  * I split the frame (or not) and run the program within gud/gdb

  * It stops at the breakpoint

That's the simple scenario. Given the information that gud-mode stores
the gud window by its Emacs window id (is that so? perhaps you can
confirm), it's entirely conceivable that sometimes there are other
factors in the equation that assign other buffers to that window.

For instance: I recompile (M-x recompile, which I have on a function
key), run program again in the terminal, get to the next programming
error, re-load the program into gdb (file ...), and restart the
debugger. Very likely the gud buffer is then in a different window.

If that is so, the solution for me would be simple: let gud not
remember the window, but let it search for the window with buffer
name *gud...* and switch to that one. I have only one such buffer.

Just speculating here about Emacs internals. Perhaps you can comment
on whether this might make sense.

From the two bug reports, it seems that problem is biting a few users
sporadically. Perhaps we can manage to find a different strategy.

Regards,

Claus

-- 
Claus Fischer <claus.fischer@clausfischer.com>
http://www.clausfischer.com/

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

bug#30044: Emacs: Gud-mode: Debugging with gud: Window switching problem

[Noam Postavsky]

Claus Fischer <claus.fischer@clausfischer.com> writes:

> If that is so, the solution for me would be simple: let gud not
> remember the window, but let it search for the window with buffer
> name *gud...* and switch to that one. I have only one such buffer.

That is basically what we have already, relevant code excerpts below.
When gdb prints that a breakpoint is hit, Emacs runs the process filter
which gud-mode sets up, `gud-filter'.  It uses `get-buffer-window' to
find the corresponding window and switches to it while calling
`gud-display-frame'.  And then `gud-display-line' shows the source
buffer in any window but the current one (i.e., the one showing the gdb
interaction).

So to fix this, we would need to follow along this code path and see
where things go wrong.  This will be pretty much impossible without a
reliable way of triggering the problem, as suggested in
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=520647#10

    (defun gud-filter (proc string)
      ...
                (with-current-buffer (process-buffer proc)
                    (setq process-window
                          (and gud-last-frame
                               (>= (point) (process-mark proc))
                               (get-buffer-window (current-buffer)))))
      ...
                ;; Put the arrow on the source line.
                ;; This must be outside of the save-excursion
                ;; in case the source file is our current buffer.
                (if process-window
                    (with-selected-window process-window
                      (gud-display-frame))

    (defun gud-display-frame ()
      ...
        (gud-display-line (car gud-last-frame) (cdr gud-last-frame))

    ;; Make sure the file named TRUE-FILE is in a buffer that appears on the screen
    ;; and that its line LINE is visible.
    ;; Put the overlay-arrow on the line LINE in that buffer.
    ;; Most of the trickiness in here comes from wanting to preserve the current
    ;; region-restriction if that's possible.  We use an explicit display-buffer
    ;; to get around the fact that this is called inside a save-excursion.

    (defun gud-display-line (true-file line)
      (let* ((last-nonmenu-event t)  ; Prevent use of dialog box for questions.
             (buffer
              (with-current-buffer gud-comint-buffer
                (gud-find-file true-file)))
             (window (and buffer
                          (or (get-buffer-window buffer)
                              (display-buffer buffer '(nil (inhibit-same-window . t))))))
      ...

bug#30044: Emacs: Gud-mode: Debugging with gud: Window switching problem

[Claus Fischer]

[-- Attachment #1: Type: text/plain, Size: 1864 bytes --]

On Wed, Jan 10, 2018 at 08:58:51PM -0500, Noam Postavsky wrote:
> Claus Fischer <claus.fischer@clausfischer.com> writes:
> 
> > If that is so, the solution for me would be simple: let gud not
> > remember the window, but let it search for the window with buffer
> > name *gud...* and switch to that one. I have only one such buffer.
> 
> That is basically what we have already, relevant code excerpts below.
> When gdb prints that a breakpoint is hit, Emacs runs the process filter
> which gud-mode sets up, `gud-filter'.  It uses `get-buffer-window' to
> find the corresponding window and switches to it while calling
> `gud-display-frame'.  And then `gud-display-line' shows the source
> buffer in any window but the current one (i.e., the one showing the gdb
> interaction).
> 
> So to fix this, we would need to follow along this code path and see
> where things go wrong.  This will be pretty much impossible without a
> reliable way of triggering the problem, as suggested in
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=520647#10

I see. I'm sure you know the term 'Heisenbug'. :)
The only thing I remember for sure is that the problem also occurred
sometimes when stepping, either with 'n' or with 's', in gdb.
But I assume that is handled just like breakpoints are.

Is it possible to take a gud.el, sprinkle it liberally with some debug
output, e.g. into Emacs' message buffer or on the terminal, and let me
load it and wait for the problem to re-occur?

Or can you give me some diagnostic procedure what to examine after it
has occurred, e.g. which buffers are there, which were in which
frame (to the best of my knowledge) etc.?

Does Emacs have some debugging or recording mode for such situations?

Best regards,

Claus

-- 
Claus Fischer <claus.fischer@clausfischer.com>
http://www.clausfischer.com/

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

bug#30044: Emacs: Gud-mode: Debugging with gud: Window switching problem

[Noam Postavsky]

Claus Fischer <claus.fischer@clausfischer.com> writes:

> Is it possible to take a gud.el, sprinkle it liberally with some debug
> output, e.g. into Emacs' message buffer or on the terminal, and let me
> load it and wait for the problem to re-occur?

> Does Emacs have some debugging or recording mode for such situations?

This should do it, hopefully it catches all the relevant info.  It will
be printed into a buffer named *trace-output*.

(dolist (fun '(gud-filter gud-display-frame gud-display-line display-buffer))
  (trace-function-background fun))

(defun bug-30044-trace-window-list (&rest _)
  (when (> trace-level 0)
    (trace-values (window-list)
                  (mapcar #'window-prev-buffers (window-list))
                  (mapcar #'window-next-buffers (window-list)))))
(advice-add 'gud-filter :before #'bug-30044-trace-window-list)

(defun bug-30044-trace-current-window (&rest _)
  (when (> trace-level 0)
    (trace-values (selected-window))))
(advice-add 'gud-display-line :before #'bug-30044-trace-current-window)

bug#30044: Emacs: Gud-mode: Debugging with gud: Window switching problem

[Noam Postavsky]

tags 30044 - moreinfo pending
found 30044 24.5
close 30044 25.1
quit

On 20 May 2018 at 18:37, Claus Fischer <claus.fischer@clausfischer.com> wrote:
> 
> On Sun, May 20, 2018 at 06:10:01PM -0400, Noam Postavsky wrote:
>> On 20 May 2018 at 16:03, Claus Fischer <claus.fischer@clausfischer.com> wrote:
>> 
>> > I attach the full content of the trace-output buffer; I'm not sure
>> > it's appropriate for the bug-tracker since it contains some specific
>> > information of my source code.
>> 
>> Do you mean that it might contain information you prefer not to post publicly?
> 
> I don't think there's anything secret in it, just that it would
> clog the bugtracker with too much information.
> 
>> Looking at the end of your trace:
>> 
>> 1 -> (trace-values (#<window 10 on *gud-hubserverd*> #<window 3 on memdb.c>) ...
>> | 2 -> (gud-display-frame)
>> | | 3 -> (gud-display-line ".../database.c" 231)
>> | | 3 -> (trace-values #<window 10 on *gud-hubserverd*>)
>> | | | 4 -> (display-buffer #<buffer database.c>)
>> | | | 4 <- display-buffer: #<window 10 on database.c>
>> 
>> I think you are running Emacs 24.5, correct? I ask because in Emacs
>> 25.1 and above, that display-buffer call would have an additional (nil
>> (inhibit-same-window . t)) argument. In which case, you might be
>> hitting Bug#20034/19901/17675.
> 
> Yes, indeed.
> 
> $ emacs --version
> GNU Emacs 24.5.1
> Copyright (C) 2015 Free Software Foundation, Inc.
> GNU Emacs comes with ABSOLUTELY NO WARRANTY.
> You may redistribute copies of Emacs
> under the terms of the GNU General Public License.
> For more information about these matters, see the file named COPYING.
> 
> ***
> 
> About bug 19901: I noticed that after the bug, Emacs had kind of
> "switched" its idea in which half of the frame the correct window
> was. I have a single frame with upper and lower half windows
> (C-x 2), and I usually debug in the lower and view the source
> in the upper one.
> 
> However, after the bug hit, even if I switched the lower half
> to *gud-gdb* again, it would for the next breakpoint again
> cover the gud-gdb window. But if I switched the upper half
> to *gud-gdb*, I could continue debugging "normally", and
> the source would then show up in the lower window.
> 
> ***
> 
> I looked up the descriptions of the other bugs, and it seems
> it's the same as mine. So I'll expect that the next Emacs
> (whenever I upgrade my Debian) will probably fix it.

If you are using Stretch (current stable) or later you can get a newer
Emacs by installing the emacs25 package.

https://packages.debian.org/stretch/emacs25
 
> I won't report it again for Emacs 24.5.
> 
> If you want to close the bug on that account, please
> go ahead!

Okay, closing.

> Thanks very much for your help!