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

From: Claus Fischer <[email-masked]>
Date: Thu, 11 Jan 2018 14:24:02 +0100

On Wed, Jan 10, 2018 at 08:58:51PM -0500, Noam Postavsky wrote:
> Claus Fischer <[email-masked]> 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 <[email-masked]>
http://www.clausfischer.com/