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