GNU bug report logs -
#8789
23.3; debug backtrace buffer changes window on step-through
Previous Next
Reported by: Pete Beardmore <pete.beardmore <at> msn.com>
Date: Thu, 2 Jun 2011 17:28:02 UTC
Severity: normal
Found in version 23.3
Done: martin rudalics <rudalics <at> gmx.at>
Bug is archived. No further changes may be made.
Full log
View this message in rfc822 format
> It is as if trying to drag the frame edge is (sometimes) the
> equivalent of hitting `q' in the debugger.
>
> Very weird. I'm sorry that I cannot offer more info about
> this. But clearly something is very wrong.
What's more, in that same context, if I do not try to drag the frame but I
instead hit `d', I can step through the debugger once (a single `d'). The frame
is removed and re-created, and *Backtrace* shows the effect of stepping (one
step).
But at that point hitting `d' again or `c' or `q' has no effect. Buffer
*Backtrace* remains frozen with its same state. I need to select another frame
and hit `C-]' (abort-recursive-edit) to exit the debugger (which removes frame
*Backtrace*).
After hitting `d' once, I tried clicking mouse-1 inside *Backtrace*, thinking
that perhaps it did not have the focus. That either had no effect (clicking `d'
etc. still did nothing) or it make the frame disappear and the debugger exit,
i.e., just as it does when I try to resize it.
If, instead of hitting `d' immediately, if I try to click mouse-1 inside
*Backtrace*, either #1 or #2 happens:
1. (a) the click has no effect - I cannot, for example, select text there by
dragging the mouse, and (b) the frame becomes insensitive to keyboard input:
even the first `d' is unrecognized.
2. The frame disappears and the debugger exits.
This is very weird behavior. As I said before, none of this happens with the
Windows build of 2012-09-03. It happens with the build of 2012-09-17.
This bug report was last modified 12 years and 223 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.