bug#8789: 23.3; debug backtrace buffer changes window on step-through

bug#8789: 23.3; debug backtrace buffer changes window on step-through

[Pete Beardmore]

Hi,

A couple of my frame window layouts cause the emacs debugger's  
backtrace buffer to cycle between several windows when stepping  
through code, making it very difficult to focus.

Please follow the minimal steps below to re-produce this undesirable  
behaviour, also confirmed as present by another user (#emacs  
'off-by-1') in a 'relatively recent git version'..

emacs -q
C-x 3
C-x 2
M-x debug-on-entry RET
apropos RET
M-x apropos RET
x RET
d RET
d RET

..you should see the buffer alternate windows on each step through the code.

Thanks,

Pete.


In GNU Emacs 23.3.1 (i486-slackware-linux-gnu, GTK+ Version 2.24.1)
  of 2011-03-12 on midas
Windowing system distributor `The X.Org Foundation', version 11.0.10899906
configured using `configure  '--prefix=/usr' '--sysconfdir=/etc'  
'--localstatedir=/var' '--program-prefix=' '--program-suffix='  
'--mandir=/usr/man' '--infodir=/usr/info' '--enable-static=no'  
'--enable-shared=yes' '--with-x' '--with-x-toolkit=gtk'  
'--build=i486-slackware-linux' 'build_alias=i486-slackware-linux'  
'CFLAGS=-O2 -march=i486 -mtune=i686''

Important settings:
   value of $LC_ALL: nil
   value of $LC_COLLATE: C
   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: en_GB.utf8
   value of $XMODIFIERS: nil
   locale-coding-system: utf-8-unix
   default enable-multibyte-characters: t

Major mode: Fundamental

Minor modes in effect:
   tooltip-mode: t
   mouse-wheel-mode: t
   tool-bar-mode: t
   menu-bar-mode: t
   file-name-shadow-mode: t
   global-font-lock-mode: t
   blink-cursor-mode: t
   auto-encryption-mode: t
   auto-compression-mode: t
   line-number-mode: t
   transient-mark-mode: t

Recent input:
<help-echo> <down-mouse-1> <mouse-movement> <mouse-1>
C-x 3 C-x 2 M-x d e b u g - o n - e n t r y <return>
a p r o p o s <return> M-x a p r o p o <tab> <return> x
<return> d d M-x C-g
C-] M-x r e p o r t <tab> <return>

Recent messages:
For information about GNU Emacs and the GNU system, type C-h C-a.
Loading apropos...done
Entering debugger...
Proceeding, will debug on next eval or call.
Entering debugger...
Proceeding, will debug on next eval or call.
Entering debugger...
Quit
Quit

Load-path shadows:
./cedet/cedet-ediff hides ./cedet-1.1bzr8044/cedet-ediff
./cedet/cedet-update-version hides ./cedet-1.1bzr8044/cedet-update-version
./cedet/cedet-build hides ./cedet-1.1bzr8044/cedet-build
./cedet/cedet-update-changelog hides ./cedet-1.1bzr8044/cedet-update-changelog
/usr/share/emacs/site-lisp/t-mouse hides /usr/share/emacs/23.3/lisp/t-mouse

Features:
(shadow sort mail-extr message idna sendmail regexp-opt ecomplete rfc822
mml mml-sec password-cache mm-decode mm-bodies mm-encode mailcap
mail-parse rfc2231 rfc2047 rfc2045 qp ietf-drums mailabbrev nnheader
gnus-util netrc time-date mm-util mail-prsvr gmm-utils wid-edit
mailheader canlock sha1 hex-util hashcash mail-utils emacsbug help-mode
easymenu view apropos debug tooltip ediff-hook vc-hooks lisp-float-type
mwheel x-win x-dnd font-setting tool-bar dnd fontset image fringe
lisp-mode register page menu-bar rfn-eshadow timer select scroll-bar
mldrag mouse jit-lock font-lock syntax facemenu font-core frame cham
georgian utf-8-lang misc-lang vietnamese tibetan thai tai-viet lao
korean japanese hebrew greek romanian slovak czech european ethiopic
indian cyrillic chinese case-table epa-hook jka-cmpr-hook help simple
abbrev loaddefs button minibuffer faces cus-face files text-properties
overlay md5 base64 format env code-pages mule custom widget
hashtable-print-readable backquote make-network-process dbusbind
font-render-setting gtk x-toolkit x multi-tty emacs)

bug#8789: 23.3; debug backtrace buffer changes window on step-through

[Drew Adams]

> A couple of my frame window layouts cause the emacs debugger's  
> backtrace buffer to cycle between several windows when stepping  
> through code, making it very difficult to focus.
> 
> Please follow the minimal steps below to re-produce this undesirable  
> behaviour, also confirmed as present by another user (#emacs  
> 'off-by-1') in a 'relatively recent git version'..
> 
> emacs -q
> C-x 3
> C-x 2
> M-x debug-on-entry RET
> apropos RET
> M-x apropos RET
> x RET
> d RET
> d RET
> 
> ..you should see the buffer alternate windows on each step 
> through the code.

FWIW, I reported this problem long, long ago. I don't recall the bug # (it might
have been before we had bug #s), and I can't seem to locate the bug report now.
This problem is at least as old as Emacs 20.  It can be very distracting.

BTW, I notice this happening especially when debugging a command invoked (via a
key) from the minibuffer.  But your recipe is a good one at top level.

bug#8789: 23.3; debug backtrace buffer changes window on step-through

[martin rudalics]

 > A couple of my frame window layouts cause the emacs debugger's backtrace
 > buffer to cycle between several windows when stepping through code,
 > making it very difficult to focus.
 >
 > Please follow the minimal steps below to re-produce this undesirable
 > behaviour, also confirmed as present by another user (#emacs 'off-by-1')
 > in a 'relatively recent git version'..

I never use debug and don't have Emacs 23 installed, so I'm probably not
of very much help here.

 > emacs -q
 > C-x 3
 > C-x 2
 > M-x debug-on-entry RET
 > apropos RET
 > M-x apropos RET
 > x RET

IIUC this shows *backtrace* in the window on the right?

 > d RET
 > d RET

These steps happen without the RETs I presume?

 > ..you should see the buffer alternate windows on each step through the
 > code.

On my trunk the *backtrace* buffer is alternately shown in the left
lower and the right window, is that what you see?  That is, the left
upper window is never used?

I suppose it happens because `debug' contains this pretty fragile code

	      (save-window-excursion
	        ...
                 (pop-to-buffer debugger-buffer)

which I don't understand so I can only speculate.  Your three-window
setup apparently prevents the creation of a new window so Emacs is
forced to reuse an existing one.  Now repeating "d" does apparently

(1) remove *backtrace* from the window configuration, restoring the
     previous configuration, and

(2) pop to *backtrace* in any but the selected window (which is the left
     upper one).  Now, when it reuses a window, `display-buffer' first
     tries to use the least-recently-used one, which, in your scenario,
     is alternatingly one of the two lower windows.

You can verify (2) for yourself by replacing the line

		  (or (get-lru-window frame-to-use)

in `display-buffer' with the form

		  (or (let ((window (get-lru-window frame-to-use)))
			(when window
			  (message "%s" window)
			  (sit-for 3)
			  window))

and go through your scenario.

I don't have the slightest idea how to fix this though because I don't
understand why apparently the *backtrace* buffer is removed from display
in (1), and what the subsequent fragment

	  ;; Kill or at least neuter the backtrace buffer, so that users
	  ;; don't try to execute debugger commands in an invalid context.
	  (if (get-buffer-window debugger-buffer 0)
	      ;; Still visible despite the save-window-excursion?  Maybe it
	      ;; it's in a pop-up frame.  It would be annoying to delete and
	      ;; recreate it every time the debugger stops, so instead we'll
	      ;; erase it (and maybe hide it) but keep it alive.
	      (with-current-buffer debugger-buffer
		(erase-buffer)
		(fundamental-mode)
		(with-selected-window (get-buffer-window debugger-buffer 0)
                   (when (and (window-dedicated-p (selected-window))
                              (not debugger-will-be-back))
                     ;; If the window is not dedicated, burying the buffer
                     ;; will mean that the frame created for it is left
                     ;; around showing some random buffer, and next time we
                     ;; pop to the debugger buffer we'll create yet
                     ;; another frame.
                     ;; If debugger-will-be-back is non-nil, the frame
                     ;; would need to be de-iconified anyway immediately
                     ;; after when we re-enter the debugger, so iconifying it
                     ;; here would cause flashing.
                     ;; Drew Adams is not happy with this: he wants to frame
                     ;; to be left at the top-level, still working on how
                     ;; best to do that.
                     (bury-buffer))))
	    (kill-buffer debugger-buffer))

is needed for (despite its detailed comment).  So we need help from
someone familiar with the debug code :-(

martin

bug#8789: 23.3; debug backtrace buffer changes window on step-through

[Stefan Monnier]

> I don't have the slightest idea how to fix this though because I don't
> understand why apparently the *backtrace* buffer is removed from display
> in (1), and what the subsequent fragment

> 	  ;; Kill or at least neuter the backtrace buffer, so that users
> 	  ;; don't try to execute debugger commands in an invalid context.
> 	  (if (get-buffer-window debugger-buffer 0)
> 	      ;; Still visible despite the save-window-excursion?  Maybe it
> 	      ;; it's in a pop-up frame.  It would be annoying to delete and
> 	      ;; recreate it every time the debugger stops, so instead we'll
> 	      ;; erase it (and maybe hide it) but keep it alive.
> 	      (with-current-buffer debugger-buffer
> 		(erase-buffer)
> 		(fundamental-mode)
> 		(with-selected-window (get-buffer-window debugger-buffer 0)
>                   (when (and (window-dedicated-p (selected-window))
>                              (not debugger-will-be-back))
>                     ;; If the window is not dedicated, burying the buffer
>                     ;; will mean that the frame created for it is left
>                     ;; around showing some random buffer, and next time we
>                     ;; pop to the debugger buffer we'll create yet
>                     ;; another frame.
>                     ;; If debugger-will-be-back is non-nil, the frame
>                     ;; would need to be de-iconified anyway immediately
>                     ;; after when we re-enter the debugger, so iconifying it
>                     ;; here would cause flashing.
>                     ;; Drew Adams is not happy with this: he wants to frame
>                     ;; to be left at the top-level, still working on how
>                     ;; best to do that.
>                     (bury-buffer))))
> 	    (kill-buffer debugger-buffer))

> is needed for (despite its detailed comment).  So we need help from
> someone familiar with the debug code :-(

I don't use `d' but I can explain the reason for the above code: when we
exit the debugger, I don't want to leave around an empty
fundamental-mode *Debugger* window (which in my case is a dedicated
window in a separate frame), so I bury it.

BTW, I recently changed the above code in `trunk' so that the
kill-buffer is not called if the buffer was pre-existing.


        Stefan

bug#8789: 23.3; debug backtrace buffer changes window on step-through

[Michael Heerdegen]

Hello,

I don't know why this problem doesn't get fixed.  It is an annoying
problem, and a fix need not to be complicated - on the contrary.
It should IMHO be sufficient to add to the

  (pop-to-buffer debugger-buffer)

call in `debug' an action argument that ensures that always the same
window is chosen, by an deterministic algorithm.  For example:

  (pop-to-buffer debugger-buffer
     '((lambda (buffer _)
         (let ((first-win (frame-first-window)))
           (select-window first-win)
           (switch-to-buffer buffer)
           first-win))))

would always choose the first window for *Backtrace*.


Michael.

bug#8789: 23.3; debug backtrace buffer changes window on step-through

[Stefan Monnier]

> I don't know why this problem doesn't get fixed.  It is an annoying
> problem, and a fix need not to be complicated - on the contrary.
> It should IMHO be sufficient to add to the

>   (pop-to-buffer debugger-buffer)

> call in `debug' an action argument that ensures that always the same
> window is chosen, by an deterministic algorithm.  For example:

>   (pop-to-buffer debugger-buffer
>      '((lambda (buffer _)
>          (let ((first-win (frame-first-window)))
>            (select-window first-win)
>            (switch-to-buffer buffer)
>            first-win))))

> would always choose the first window for *Backtrace*.

The general approach sounds good, but we should probably try to refine
it so as to minimize changes in behavior, and so it works right in the
multi-frame and even multi-terminal case.

We could try to store the last-used-window in a variable
`debugger-last-used-window' and use that window after checking that it's
still live and is visible in the selected terminal.


        Stefan

bug#8789: 23.3; debug backtrace buffer changes window on step-through

[Michael Heerdegen]

Stefan Monnier <monnier@IRO.UMontreal.CA> writes:

> The general approach sounds good, but we should probably try to refine
> it so as to minimize changes in behavior, and so it works right in the
> multi-frame and even multi-terminal case.
>
> We could try to store the last-used-window in a variable
> `debugger-last-used-window' and use that window after checking that it's
> still live and is visible in the selected terminal.

Sounds really good to me, and not hard to implement.


Michael.

bug#8789: 23.3; debug backtrace buffer changes window on step-through

[martin rudalics]

 > The general approach sounds good, but we should probably try to refine
 > it so as to minimize changes in behavior, and so it works right in the
 > multi-frame and even multi-terminal case.
 >
 > We could try to store the last-used-window in a variable
 > `debugger-last-used-window' and use that window after checking that it's
 > still live and is visible in the selected terminal.

We could also try `window-prev-buffers' and `window-next-buffers' as in
the rather untested patch below.

martin


=== modified file 'lisp/window.el'
--- lisp/window.el	2012-02-12 05:10:30 +0000
+++ lisp/window.el	2012-02-15 16:54:41 +0000
@@ -4846,6 +4846,39 @@
        (and pop-up-windows
  	   (display-buffer-pop-up-window buffer alist))))

+(defun window-previously-showing (buffer &optional all-frames dedicated)
+  "Return a window that previously showed BUFFER.
+A minibuffer window is never a candidate.  A dedicated window is
+never a candidate unless DEDICATED is non-nil, so if all windows
+are dedicated, the value is nil.  Avoid returning the selected
+window if possible.
+
+The following non-nil values of the optional argument ALL-FRAMES
+have special meanings:
+
+- t means consider all windows on all existing frames.
+
+- `visible' means consider all windows on all visible frames on
+  the current terminal.
+
+- 0 (the number zero) means consider all windows on all visible
+  and iconified frames on the current terminal.
+
+- A frame means consider all windows on that frame only.
+
+Any other value of ALL-FRAMES means consider all windows on the
+selected frame and no others."
+  (let (best-window second-best-window)
+    (dolist (window (window-list-1 nil 'nomini all-frames))
+      (when (and (or (assq buffer (window-prev-buffers window))
+		     (assq buffer (window-next-buffers window)))
+		 (or dedicated (not (window-dedicated-p window))))
+	(if (eq window (selected-window))
+	    (setq second-best-window window)
+	  ;; We probably should throw WINDOW here.
+	  (setq best-window window))))
+    (or best-window second-best-window)))
+
  (defun display-buffer-use-some-window (buffer alist)
    "Display BUFFER in an existing window.
  Search for a usable window, set that window to the buffer, and
@@ -4864,7 +4897,8 @@
      (unwind-protect
  	(setq window
  	      ;; Reuse an existing window.
-	      (or (get-lru-window frame)
+	      (or (window-previously-showing buffer 'visible)
+		  (get-lru-window frame)
  		  (let ((window (get-buffer-window buffer 'visible)))
  		    (unless (and not-this-window
  				 (eq window (selected-window)))

bug#8789: 23.3; debug backtrace buffer changes window on step-through

[Stefan Monnier]

> We could also try `window-prev-buffers' and `window-next-buffers' as in
> the rather untested patch below.

Sounds good for the backtrace buffer, but the patch you propose would
affect many more cases, and while I think it might be good to do it
globally like you suggest, I wouldn't want to make such a change so late
in the pretest.
Can you provide another patch that limits the effect to the
backtrace buffer?


        Stefan


> === modified file 'lisp/window.el'
> --- lisp/window.el	2012-02-12 05:10:30 +0000
> +++ lisp/window.el	2012-02-15 16:54:41 +0000
> @@ -4846,6 +4846,39 @@
>        (and pop-up-windows
>  	   (display-buffer-pop-up-window buffer alist))))

> +(defun window-previously-showing (buffer &optional all-frames dedicated)
> +  "Return a window that previously showed BUFFER.
> +A minibuffer window is never a candidate.  A dedicated window is
> +never a candidate unless DEDICATED is non-nil, so if all windows
> +are dedicated, the value is nil.  Avoid returning the selected
> +window if possible.
> +
> +The following non-nil values of the optional argument ALL-FRAMES
> +have special meanings:
> +
> +- t means consider all windows on all existing frames.
> +
> +- `visible' means consider all windows on all visible frames on
> +  the current terminal.
> +
> +- 0 (the number zero) means consider all windows on all visible
> +  and iconified frames on the current terminal.
> +
> +- A frame means consider all windows on that frame only.
> +
> +Any other value of ALL-FRAMES means consider all windows on the
> +selected frame and no others."
> +  (let (best-window second-best-window)
> +    (dolist (window (window-list-1 nil 'nomini all-frames))
> +      (when (and (or (assq buffer (window-prev-buffers window))
> +		     (assq buffer (window-next-buffers window)))
> +		 (or dedicated (not (window-dedicated-p window))))
> +	(if (eq window (selected-window))
> +	    (setq second-best-window window)
> +	  ;; We probably should throw WINDOW here.
> +	  (setq best-window window))))
> +    (or best-window second-best-window)))
> +
>  (defun display-buffer-use-some-window (buffer alist)
>    "Display BUFFER in an existing window.
>  Search for a usable window, set that window to the buffer, and
> @@ -4864,7 +4897,8 @@
>      (unwind-protect
>  	(setq window
>  	      ;; Reuse an existing window.
> -	      (or (get-lru-window frame)
> +	      (or (window-previously-showing buffer 'visible)
> +		  (get-lru-window frame)
>  		  (let ((window (get-buffer-window buffer 'visible)))
>  		    (unless (and not-this-window
>  				 (eq window (selected-window)))

bug#8789: 23.3; debug backtrace buffer changes window on step-through

[martin rudalics]

 > Sounds good for the backtrace buffer, but the patch you propose would
 > affect many more cases, and while I think it might be good to do it
 > globally like you suggest, I wouldn't want to make such a change so late
 > in the pretest.

Neither do I.  The problem is that if a window is not very suitable for
getting reused, there's no easy way for the user (or the application) to
communicate that to the buffer display routines.

 > Can you provide another patch that limits the effect to the
 > backtrace buffer?

Can you?  I think that using `display-buffer-overriding-action' would be
too harsh so we would have to specify this via the ACTION argument in
(pop-to-buffer debugger-buffer).  A patch in that direction is below.

martin


=== modified file 'lisp/emacs-lisp/debug.el'
--- lisp/emacs-lisp/debug.el	2012-01-19 07:21:25 +0000
+++ lisp/emacs-lisp/debug.el	2012-02-16 07:51:35 +0000
@@ -194,7 +194,9 @@
  		  ;; Place an extra debug-on-exit for macro's.
  		  (when (eq 'lambda (car-safe (cadr (backtrace-frame 4))))
  		    (backtrace-debug 5 t)))
-                (pop-to-buffer debugger-buffer)
+                (pop-to-buffer
+		 debugger-buffer
+		 '((display-buffer-in-window-previously-showing-it . nil)))
  		(debugger-mode)
  		(debugger-setup-buffer debugger-args)
  		(when noninteractive

=== modified file 'lisp/window.el'
--- lisp/window.el	2012-02-12 05:10:30 +0000
+++ lisp/window.el	2012-02-16 07:54:35 +0000
@@ -4846,6 +4846,22 @@
        (and pop-up-windows
  	   (display-buffer-pop-up-window buffer alist))))

+(defun display-buffer-in-window-previously-showing-it (buffer &optional alist)
+  "Display BUFFER in a window previously showing it."
+  (let (best-window second-best-window window)
+    (catch 'best-window
+      (dolist (window (window-list-1 nil 'nomini 'visible))
+	(when (and (assq buffer (window-prev-buffers window))
+		   (not (window-dedicated-p window)))
+	  (if (eq window (selected-window))
+	      (setq second-best-window window)
+	    (setq best-window window)
+	    (throw 'best-window t)))))
+
+    (when (setq window (or best-window second-best-window))
+      (display-buffer-record-window 'reuse window buffer)
+      (window--display-buffer-2 buffer window display-buffer-mark-dedicated))))
+
  (defun display-buffer-use-some-window (buffer alist)
    "Display BUFFER in an existing window.
  Search for a usable window, set that window to the buffer, and

bug#8789: 23.3; debug backtrace buffer changes window on step-through

[Stefan Monnier]

>> Can you provide another patch that limits the effect to the
>> backtrace buffer?
> Can you?  I think that using `display-buffer-overriding-action' would be
> too harsh so we would have to specify this via the ACTION argument in
> (pop-to-buffer debugger-buffer).  A patch in that direction is below.

Looks fine to me, feel free to install,
thank you very much,


        Stefan

bug#8789: 23.3; debug backtrace buffer changes window on step-through

[martin rudalics]

Could someone (Pete, Michael) check whether the patch fixes the
original problem?

Thanks, martin

bug#8789: 23.3; debug backtrace buffer changes window on step-through

[Michael Heerdegen]

martin rudalics <rudalics@gmx.at> writes:

> Could someone (Pete, Michael) check whether the patch fixes the
> original problem?

I tested about 2 hours and encountered many problems.

At first, some general things:

 (1) If the user starts the debugger, do we really want that the
     Backtrace buffer pops up in some other frame only because it was
     displayed there in some window before?

 (2) A problem with this approach: if the Backtrace buffer was already
     visible in several windows, it still hops around, because the
     window `display-buffer-in-window-previously-showing-it' returns is
     not unique.


Now to my tests in detail:

 - When I start debugging with a 3-windowed frame, and this is the first
   time at all that I use the debugger at all, even then, the debugger
   hops around.  This has to do with (1), but I don't know why it hops
   the first time.


But it gets much worse.  Do the following:

 - emacs -Q
 - require 'debug, and load your patch
 - M-x debug-on-entry dired RET
 - C-x d RET
 - hit d three times -> Emacs crashs!

This is reproducible here.  I use GNU Emacs 24.0.93.1
(i486-pc-linux-gnu, GTK+ Version 3.2.3)\n of 2012-02-16 on zelenka,
modified by Debian, btw.


This is all a horror to debug.  Tell me if I can help with something.


Michael

bug#8789: 23.3; debug backtrace buffer changes window on step-through

[martin rudalics]

 > I tested about 2 hours

Thank you!

 > and encountered many problems.
 >
 > At first, some general things:
 >
 >  (1) If the user starts the debugger, do we really want that the
 >      Backtrace buffer pops up in some other frame only because it was
 >      displayed there in some window before?

Maybe not.  But we should also handle the case of the user preferring
*Backtrace* to appear on a standalone frame.  Detecting this (from
within `debug') is tricky.

 >  (2) A problem with this approach: if the Backtrace buffer was already
 >      visible in several windows, it still hops around, because the
 >      window `display-buffer-in-window-previously-showing-it' returns is
 >      not unique.

I see.  The first argument in the call of `window-list-1' could be made
the `frame-first-window' of the selected frame.  Can you try that, i.e.,
using a call like

       (dolist (window (window-list-1 (frame-first-window) 'nomini 'visible))

and, if you want to avoid the frame problem above as well,

       (dolist (window (window-list-1 (frame-first-window) 'nomini))

Or is it because the window where the *Backtrace* buffer earlier
appeared is the selected one?  Would it be OK to return the selected
window here if there's another choice?

BTW so far I don't handle the case yet where the *Backtrace* buffer is
already shown in some window.

 > Now to my tests in detail:
 >
 >  - When I start debugging with a 3-windowed frame, and this is the first
 >    time at all that I use the debugger at all, even then, the debugger
 >    hops around.  This has to do with (1), but I don't know why it hops
 >    the first time.

IIUC so far by "hop around" we meant the *Backtrace* buffer appearing in
one window and then in another.  How can the debugger "hop around" if
*Backtrace* hasn't been shown yet?

 > But it gets much worse.  Do the following:
 >
 >  - emacs -Q
 >  - require 'debug, and load your patch
 >  - M-x debug-on-entry dired RET
 >  - C-x d RET
 >  - hit d three times -> Emacs crashs!
 >
 > This is reproducible here.  I use GNU Emacs 24.0.93.1
 > (i486-pc-linux-gnu, GTK+ Version 3.2.3)\n of 2012-02-16 on zelenka,
 > modified by Debian, btw.

I can't reproduce that here (on Windows XP).  After C-x d I get the
*Backtrace* buffer in the bottom window, hitting "d" now steps through
the code.  Please try to get a backtrace of this.

 > This is all a horror to debug.

Debugging a debugger is painful.

Thanks, martin

bug#8789: 23.3; debug backtrace buffer changes window on step-through

[martin rudalics]

 > At first, some general things:
 >
 >  (1) If the user starts the debugger, do we really want that the
 >      Backtrace buffer pops up in some other frame only because it was
 >      displayed there in some window before?
 >
 >  (2) A problem with this approach: if the Backtrace buffer was already
 >      visible in several windows, it still hops around, because the
 >      window `display-buffer-in-window-previously-showing-it' returns is
 >      not unique.
 >
 >
 > Now to my tests in detail:
 >
 >  - When I start debugging with a 3-windowed frame, and this is the first
 >    time at all that I use the debugger at all, even then, the debugger
 >    hops around.  This has to do with (1), but I don't know why it hops
 >    the first time.

I finally managed to look into this issue and it's non-trivial for two
reasons:

(A) `debug' wraps all interesting actions in a `save-window-excursion'.
     Since `set-window-configuration' does not use `set-window-buffer' to
     restore the old buffer, it does not call `record-window-buffer'
     either.  This means that *Backtrace*, when displayed by `debug'
     only, never ends up on the previous buffers list of any window that
     shows it.  This explains why the debugger "hops the first time".

(B) When the debugger buffer has not existed before calling `debug', the
     line (kill-buffer debugger-buffer) will kill it and remove it from
     the previous buffers lists of all windows (this is needed to avoid
     that these lists get arbitrarily large).  In this case there's no
     way to find a window where the buffer was shown previously.

(A) can be fixed easily by having `set-window-configuration' record the
buffer it's going to replace by the saved one.  So if we avoid killing
the buffer in (B) all issues cited above can be resolved.

 > But it gets much worse.  Do the following:
 >
 >  - emacs -Q
 >  - require 'debug, and load your patch
 >  - M-x debug-on-entry dired RET
 >  - C-x d RET
 >  - hit d three times -> Emacs crashs!
 >
 > This is reproducible here.  I use GNU Emacs 24.0.93.1
 > (i486-pc-linux-gnu, GTK+ Version 3.2.3)\n of 2012-02-16 on zelenka,
 > modified by Debian, btw.
 >
 >
 > This is all a horror to debug.  Tell me if I can help with something.

This must be a different issue.  Please get a backtrace of this ASAP.

Thanks, martin

bug#8789: 23.3; debug backtrace buffer changes window on step-through

[Michael Heerdegen]

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

martin rudalics <rudalics@gmx.at> writes:

> > But it gets much worse.  Do the following:
> >
> >  - emacs -Q
> >  - require 'debug, and load your patch
> >  - M-x debug-on-entry dired RET
> >  - C-x d RET
> >  - hit d three times -> Emacs crashs!
> >
> This must be a different issue.  Please get a backtrace of this ASAP.

Here it comes, produced today with "GNU Emacs 24.0.93.1
(i486-pc-linux-gnu, GTK+ Version 3.2.3)\n of 2012-02-22 on zelenka,
modified by Debian".


[-- Attachment #2: debug.txt --]
[-- Type: text/plain, Size: 34192 bytes --]

Content of *Backtrace* before the crash:

* (set-window-configuration wconfig)
  (unwind-protect (progn (with-no-warnings (setq unread-command-char -1)) (when (eq (car debugger-args) (quote debug)) (backtrace-debug 4 t) (when (eq (quote lambda) (car-safe (cadr (backtrace-frame 4)))) (backtrace-debug 5 t))) (pop-to-buffer debugger-buffer (quote ((display-buffer-in-window-previously-showing-it)))) (debugger-mode) (debugger-setup-buffer debugger-args) (when noninteractive (when (> (count-lines (point-min) (point-max)) debugger-batch-max-lines) (goto-char (point-min)) (forward-line (/ 2 debugger-batch-max-lines)) (let ((middlestart (point))) (goto-char (point-max)) (forward-line (- (/ 2 debugger-batch-max-lines) debugger-batch-max-lines)) (delete-region middlestart (point))) (insert "...\n")) (goto-char (point-min)) (message "%s" (buffer-string)) (kill-emacs -1)) (message "") (let ((standard-output nil) (buffer-read-only t)) (message "") (save-excursion (recursive-edit)))) (set-window-configuration wconfig))
  (let ((wconfig (current-window-configuration))) (unwind-protect (progn (with-no-warnings (setq unread-command-char -1)) (when (eq (car debugger-args) (quote debug)) (backtrace-debug 4 t) (when (eq (quote lambda) (car-safe (cadr ...))) (backtrace-debug 5 t))) (pop-to-buffer debugger-buffer (quote ((display-buffer-in-window-previously-showing-it)))) (debugger-mode) (debugger-setup-buffer debugger-args) (when noninteractive (when (> (count-lines (point-min) (point-max)) debugger-batch-max-lines) (goto-char (point-min)) (forward-line (/ 2 debugger-batch-max-lines)) (let ((middlestart ...)) (goto-char (point-max)) (forward-line (- ... debugger-batch-max-lines)) (delete-region middlestart (point))) (insert "...\n")) (goto-char (point-min)) (message "%s" (buffer-string)) (kill-emacs -1)) (message "") (let ((standard-output nil) (buffer-read-only t)) (message "") (save-excursion (recursive-edit)))) (set-window-configuration wconfig)))
  (save-window-excursion (with-no-warnings (setq unread-command-char -1)) (when (eq (car debugger-args) (quote debug)) (backtrace-debug 4 t) (when (eq (quote lambda) (car-safe (cadr (backtrace-frame 4)))) (backtrace-debug 5 t))) (pop-to-buffer debugger-buffer (quote ((display-buffer-in-window-previously-showing-it)))) (debugger-mode) (debugger-setup-buffer debugger-args) (when noninteractive (when (> (count-lines (point-min) (point-max)) debugger-batch-max-lines) (goto-char (point-min)) (forward-line (/ 2 debugger-batch-max-lines)) (let ((middlestart (point))) (goto-char (point-max)) (forward-line (- (/ 2 debugger-batch-max-lines) debugger-batch-max-lines)) (delete-region middlestart (point))) (insert "...\n")) (goto-char (point-min)) (message "%s" (buffer-string)) (kill-emacs -1)) (message "") (let ((standard-output nil) (buffer-read-only t)) (message "") (save-excursion (recursive-edit))))
  (save-excursion (save-window-excursion (with-no-warnings (setq unread-command-char -1)) (when (eq (car debugger-args) (quote debug)) (backtrace-debug 4 t) (when (eq (quote lambda) (car-safe (cadr (backtrace-frame 4)))) (backtrace-debug 5 t))) (pop-to-buffer debugger-buffer (quote ((display-buffer-in-window-previously-showing-it)))) (debugger-mode) (debugger-setup-buffer debugger-args) (when noninteractive (when (> (count-lines (point-min) (point-max)) debugger-batch-max-lines) (goto-char (point-min)) (forward-line (/ 2 debugger-batch-max-lines)) (let ((middlestart (point))) (goto-char (point-max)) (forward-line (- (/ 2 debugger-batch-max-lines) debugger-batch-max-lines)) (delete-region middlestart (point))) (insert "...\n")) (goto-char (point-min)) (message "%s" (buffer-string)) (kill-emacs -1)) (message "") (let ((standard-output nil) (buffer-read-only t)) (message "") (save-excursion (recursive-edit)))))
  (unwind-protect (save-excursion (save-window-excursion (with-no-warnings (setq unread-command-char -1)) (when (eq (car debugger-args) (quote debug)) (backtrace-debug 4 t) (when (eq (quote lambda) (car-safe (cadr ...))) (backtrace-debug 5 t))) (pop-to-buffer debugger-buffer (quote ((display-buffer-in-window-previously-showing-it)))) (debugger-mode) (debugger-setup-buffer debugger-args) (when noninteractive (when (> (count-lines (point-min) (point-max)) debugger-batch-max-lines) (goto-char (point-min)) (forward-line (/ 2 debugger-batch-max-lines)) (let ((middlestart ...)) (goto-char (point-max)) (forward-line (- ... debugger-batch-max-lines)) (delete-region middlestart (point))) (insert "...\n")) (goto-char (point-min)) (message "%s" (buffer-string)) (kill-emacs -1)) (message "") (let ((standard-output nil) (buffer-read-only t)) (message "") (save-excursion (recursive-edit))))) (if (get-buffer-window debugger-buffer 0) (with-current-buffer debugger-buffer (with-selected-window (get-buffer-window debugger-buffer 0) (when (and (window-dedicated-p (selected-window)) (not debugger-will-be-back)) (bury-buffer)))) (unless debugger-previous-state (kill-buffer debugger-buffer))) (when (buffer-live-p debugger-buffer) (with-current-buffer debugger-buffer (let ((inhibit-read-only t)) (erase-buffer) (if (null debugger-previous-state) (fundamental-mode) (insert (nth 1 debugger-previous-state)) (funcall (nth 0 debugger-previous-state)))))) (with-timeout-unsuspend debugger-with-timeout-suspend) (set-match-data debugger-outer-match-data))
  (let ((last-command nil) this-command track-mouse (inhibit-trace t) (inhibit-debug-on-entry t) unread-command-events unread-post-input-method-events last-input-event last-command-event last-nonmenu-event last-event-frame overriding-local-map load-read-function (enable-recursive-minibuffers (or enable-recursive-minibuffers (> (minibuffer-depth) 0))) (standard-input t) (standard-output t) inhibit-redisplay (cursor-in-echo-area nil)) (unwind-protect (save-excursion (save-window-excursion (with-no-warnings (setq unread-command-char -1)) (when (eq (car debugger-args) (quote debug)) (backtrace-debug 4 t) (when (eq (quote lambda) (car-safe ...)) (backtrace-debug 5 t))) (pop-to-buffer debugger-buffer (quote ((display-buffer-in-window-previously-showing-it)))) (debugger-mode) (debugger-setup-buffer debugger-args) (when noninteractive (when (> (count-lines ... ...) debugger-batch-max-lines) (goto-char (point-min)) (forward-line (/ 2 debugger-batch-max-lines)) (let (...) (goto-char ...) (forward-line ...) (delete-region middlestart ...)) (insert "...\n")) (goto-char (point-min)) (message "%s" (buffer-string)) (kill-emacs -1)) (message "") (let ((standard-output nil) (buffer-read-only t)) (message "") (save-excursion (recursive-edit))))) (if (get-buffer-window debugger-buffer 0) (with-current-buffer debugger-buffer (with-selected-window (get-buffer-window debugger-buffer 0) (when (and (window-dedicated-p ...) (not debugger-will-be-back)) (bury-buffer)))) (unless debugger-previous-state (kill-buffer debugger-buffer))) (when (buffer-live-p debugger-buffer) (with-current-buffer debugger-buffer (let ((inhibit-read-only t)) (erase-buffer) (if (null debugger-previous-state) (fundamental-mode) (insert (nth 1 debugger-previous-state)) (funcall (nth 0 debugger-previous-state)))))) (with-timeout-unsuspend debugger-with-timeout-suspend) (set-match-data debugger-outer-match-data)))
  (let (debugger-value (debug-on-error nil) (debug-on-quit nil) (debugger-previous-state (if (get-buffer "*Backtrace*") (with-current-buffer (get-buffer "*Backtrace*") (list major-mode (buffer-string))))) (debugger-buffer (get-buffer-create "*Backtrace*")) (debugger-old-buffer (current-buffer)) (debugger-step-after-exit nil) (debugger-will-be-back nil) (executing-kbd-macro nil) (debugger-outer-match-data (match-data)) (debugger-outer-load-read-function load-read-function) (debugger-outer-overriding-local-map overriding-local-map) (debugger-outer-overriding-terminal-local-map overriding-terminal-local-map) (debugger-outer-track-mouse track-mouse) (debugger-outer-last-command last-command) (debugger-outer-this-command this-command) (debugger-outer-unread-command-char (with-no-warnings unread-command-char)) (debugger-outer-unread-command-events unread-command-events) (debugger-outer-unread-post-input-method-events unread-post-input-method-events) (debugger-outer-last-input-event last-input-event) (debugger-outer-last-command-event last-command-event) (debugger-outer-last-nonmenu-event last-nonmenu-event) (debugger-outer-last-event-frame last-event-frame) (debugger-outer-standard-input standard-input) (debugger-outer-standard-output standard-output) (debugger-outer-inhibit-redisplay inhibit-redisplay) (debugger-outer-cursor-in-echo-area cursor-in-echo-area) (debugger-with-timeout-suspend (with-timeout-suspend))) (setq overriding-terminal-local-map nil) (let ((last-command nil) this-command track-mouse (inhibit-trace t) (inhibit-debug-on-entry t) unread-command-events unread-post-input-method-events last-input-event last-command-event last-nonmenu-event last-event-frame overriding-local-map load-read-function (enable-recursive-minibuffers (or enable-recursive-minibuffers (> (minibuffer-depth) 0))) (standard-input t) (standard-output t) inhibit-redisplay (cursor-in-echo-area nil)) (unwind-protect (save-excursion (save-window-excursion (with-no-warnings (setq unread-command-char -1)) (when (eq (car debugger-args) (quote debug)) (backtrace-debug 4 t) (when (eq ... ...) (backtrace-debug 5 t))) (pop-to-buffer debugger-buffer (quote (...))) (debugger-mode) (debugger-setup-buffer debugger-args) (when noninteractive (when (> ... debugger-batch-max-lines) (goto-char ...) (forward-line ...) (let ... ... ... ...) (insert "...\n")) (goto-char (point-min)) (message "%s" (buffer-string)) (kill-emacs -1)) (message "") (let ((standard-output nil) (buffer-read-only t)) (message "") (save-excursion (recursive-edit))))) (if (get-buffer-window debugger-buffer 0) (with-current-buffer debugger-buffer (with-selected-window (get-buffer-window debugger-buffer 0) (when (and ... ...) (bury-buffer)))) (unless debugger-previous-state (kill-buffer debugger-buffer))) (when (buffer-live-p debugger-buffer) (with-current-buffer debugger-buffer (let ((inhibit-read-only t)) (erase-buffer) (if (null debugger-previous-state) (fundamental-mode) (insert ...) (funcall ...))))) (with-timeout-unsuspend debugger-with-timeout-suspend) (set-match-data debugger-outer-match-data))) (setq load-read-function debugger-outer-load-read-function) (setq overriding-local-map debugger-outer-overriding-local-map) (setq overriding-terminal-local-map debugger-outer-overriding-terminal-local-map) (setq track-mouse debugger-outer-track-mouse) (setq last-command debugger-outer-last-command) (setq this-command debugger-outer-this-command) (with-no-warnings (setq unread-command-char debugger-outer-unread-command-char)) (setq unread-command-events debugger-outer-unread-command-events) (setq unread-post-input-method-events debugger-outer-unread-post-input-method-events) (setq last-input-event debugger-outer-last-input-event) (setq last-command-event debugger-outer-last-command-event) (setq last-nonmenu-event debugger-outer-last-nonmenu-event) (setq last-event-frame debugger-outer-last-event-frame) (setq standard-input debugger-outer-standard-input) (setq standard-output debugger-outer-standard-output) (setq inhibit-redisplay debugger-outer-inhibit-redisplay) (setq cursor-in-echo-area debugger-outer-cursor-in-echo-area) (setq debug-on-next-call debugger-step-after-exit) debugger-value)
  (if inhibit-redisplay debugger-value (unless noninteractive (message "Entering debugger...")) (let (debugger-value (debug-on-error nil) (debug-on-quit nil) (debugger-previous-state (if (get-buffer "*Backtrace*") (with-current-buffer (get-buffer "*Backtrace*") (list major-mode (buffer-string))))) (debugger-buffer (get-buffer-create "*Backtrace*")) (debugger-old-buffer (current-buffer)) (debugger-step-after-exit nil) (debugger-will-be-back nil) (executing-kbd-macro nil) (debugger-outer-match-data (match-data)) (debugger-outer-load-read-function load-read-function) (debugger-outer-overriding-local-map overriding-local-map) (debugger-outer-overriding-terminal-local-map overriding-terminal-local-map) (debugger-outer-track-mouse track-mouse) (debugger-outer-last-command last-command) (debugger-outer-this-command this-command) (debugger-outer-unread-command-char (with-no-warnings unread-command-char)) (debugger-outer-unread-command-events unread-command-events) (debugger-outer-unread-post-input-method-events unread-post-input-method-events) (debugger-outer-last-input-event last-input-event) (debugger-outer-last-command-event last-command-event) (debugger-outer-last-nonmenu-event last-nonmenu-event) (debugger-outer-last-event-frame last-event-frame) (debugger-outer-standard-input standard-input) (debugger-outer-standard-output standard-output) (debugger-outer-inhibit-redisplay inhibit-redisplay) (debugger-outer-cursor-in-echo-area cursor-in-echo-area) (debugger-with-timeout-suspend (with-timeout-suspend))) (setq overriding-terminal-local-map nil) (let ((last-command nil) this-command track-mouse (inhibit-trace t) (inhibit-debug-on-entry t) unread-command-events unread-post-input-method-events last-input-event last-command-event last-nonmenu-event last-event-frame overriding-local-map load-read-function (enable-recursive-minibuffers (or enable-recursive-minibuffers (> (minibuffer-depth) 0))) (standard-input t) (standard-output t) inhibit-redisplay (cursor-in-echo-area nil)) (unwind-protect (save-excursion (save-window-excursion (with-no-warnings (setq unread-command-char -1)) (when (eq ... ...) (backtrace-debug 4 t) (when ... ...)) (pop-to-buffer debugger-buffer (quote ...)) (debugger-mode) (debugger-setup-buffer debugger-args) (when noninteractive (when ... ... ... ... ...) (goto-char ...) (message "%s" ...) (kill-emacs -1)) (message "") (let (... ...) (message "") (save-excursion ...)))) (if (get-buffer-window debugger-buffer 0) (with-current-buffer debugger-buffer (with-selected-window (get-buffer-window debugger-buffer 0) (when ... ...))) (unless debugger-previous-state (kill-buffer debugger-buffer))) (when (buffer-live-p debugger-buffer) (with-current-buffer debugger-buffer (let (...) (erase-buffer) (if ... ... ... ...)))) (with-timeout-unsuspend debugger-with-timeout-suspend) (set-match-data debugger-outer-match-data))) (setq load-read-function debugger-outer-load-read-function) (setq overriding-local-map debugger-outer-overriding-local-map) (setq overriding-terminal-local-map debugger-outer-overriding-terminal-local-map) (setq track-mouse debugger-outer-track-mouse) (setq last-command debugger-outer-last-command) (setq this-command debugger-outer-this-command) (with-no-warnings (setq unread-command-char debugger-outer-unread-command-char)) (setq unread-command-events debugger-outer-unread-command-events) (setq unread-post-input-method-events debugger-outer-unread-post-input-method-events) (setq last-input-event debugger-outer-last-input-event) (setq last-command-event debugger-outer-last-command-event) (setq last-nonmenu-event debugger-outer-last-nonmenu-event) (setq last-event-frame debugger-outer-last-event-frame) (setq standard-input debugger-outer-standard-input) (setq standard-output debugger-outer-standard-output) (setq inhibit-redisplay debugger-outer-inhibit-redisplay) (setq cursor-in-echo-area debugger-outer-cursor-in-echo-area) (setq debug-on-next-call debugger-step-after-exit) debugger-value))
  debug(debug)
  implement-debug-on-entry()
  dired("~/" nil)
  call-interactively(dired nil nil)

If I hit d, emacs crashs.


This is the gdb backtrace:

(gdb) bt
#0  0xb7fe2424 in __kernel_vsyscall ()
#1  0xb6a65c16 in kill () from /lib/i386-linux-gnu/i686/cmov/libc.so.6
#2  0x08139d78 in abort () at emacs.c:394
#3  0x0819441e in mark_object (arg=139036542) at alloc.c:5706
#4  0x081944d1 in mark_object (arg=139036318) at alloc.c:5702
#5  0x08194363 in mark_object (arg=145795178) at alloc.c:5592
#6  0x081944d1 in mark_object (arg=139173742) at alloc.c:5702
#7  0x081944d1 in mark_object (arg=139036606) at alloc.c:5702
#8  0x08194363 in mark_object (arg=145795154) at alloc.c:5592
#9  0x081944d1 in mark_object (arg=139036622) at alloc.c:5702
#10 0x081944d1 in mark_object (arg=139279422) at alloc.c:5702
#11 0x081944d1 in mark_object (arg=139279374) at alloc.c:5702
#12 0x08194363 in mark_object (arg=139220250) at alloc.c:5592
#13 0x081944d1 in mark_object (arg=142104630) at alloc.c:5702
#14 0x081944d1 in mark_object (arg=142085174) at alloc.c:5702
#15 0x08194515 in mark_object (arg=142042046) at alloc.c:5595
#16 0x081944d1 in mark_object (arg=142011406) at alloc.c:5702
#17 0x08194515 in mark_object (arg=141221730) at alloc.c:5595
#18 0x08194bb7 in mark_vectorlike (ptr=0x8a3f9a0) at alloc.c:5391
#19 0x08194358 in mark_object (arg=141644778) at alloc.c:5591
#20 0x081944d1 in mark_object (arg=142034150) at alloc.c:5702
#21 0x081944d1 in mark_object (arg=139533566) at alloc.c:5702
#22 0x08194358 in mark_object (arg=139533582) at alloc.c:5591
#23 0x081944d1 in mark_object (arg=139402182) at alloc.c:5702
#24 0x081944d1 in mark_object (arg=141998270) at alloc.c:5702
#25 0x081944d1 in mark_object (arg=141998582) at alloc.c:5702
#26 0x08194515 in mark_object (arg=142178478) at alloc.c:5595
#27 0x081944d1 in mark_object (arg=142178566) at alloc.c:5702
#28 0x08194515 in mark_object (arg=145874074) at alloc.c:5595
#29 0x08194bb7 in mark_vectorlike (ptr=0x8b18ce8) at alloc.c:5391
#30 0x08194358 in mark_object (arg=142724330) at alloc.c:5591
#31 0x08194bb7 in mark_vectorlike (ptr=0x8a3dad0) at alloc.c:5391
#32 0x08194358 in mark_object (arg=145858138) at alloc.c:5591
#33 0x08194bb7 in mark_vectorlike (ptr=0x8474578) at alloc.c:5391
#34 0x08194bb7 in mark_vectorlike (ptr=0x8687508) at alloc.c:5391
#35 0x08194515 in mark_object (arg=145874002) at alloc.c:5595
#36 0x08194bb7 in mark_vectorlike (ptr=0x8b18c08) at alloc.c:5391
#37 0x08194358 in mark_object (arg=145858378) at alloc.c:5591
#38 0x08194bb7 in mark_vectorlike (ptr=0x8a449c8) at alloc.c:5391
#39 0x08194358 in mark_object (arg=141370674) at alloc.c:5591
#40 0x08194bb7 in mark_vectorlike (ptr=0x8a39a70) at alloc.c:5391
#41 0x08194358 in mark_object (arg=142741266) at alloc.c:5591
#42 0x08194bb7 in mark_vectorlike (ptr=0x8b1fc58) at alloc.c:5391
#43 0x08194358 in mark_object (arg=139743194) at alloc.c:5591
#44 0x081944d1 in mark_object (arg=139419246) at alloc.c:5702
#45 0x081944d1 in mark_object (arg=139423270) at alloc.c:5702
#46 0x081944d1 in mark_object (arg=139423254) at alloc.c:5702
#47 0x08194363 in mark_object (arg=139076430) at alloc.c:5592
#48 0x08194515 in mark_object (arg=141375194) at alloc.c:5595
#49 0x081944d1 in mark_object (arg=142206438) at alloc.c:5702
#50 0x081944d1 in mark_object (arg=142206382) at alloc.c:5702
#51 0x081944d1 in mark_object (arg=142221678) at alloc.c:5702
#52 0x08194358 in mark_object (arg=139248374) at alloc.c:5591
#53 0x081944d1 in mark_object (arg=139291134) at alloc.c:5702
#54 0x08194358 in mark_object (arg=139209450) at alloc.c:5591
#55 0x08194b32 in mark_char_table (ptr=0x8490348) at alloc.c:5418
#56 0x08194b73 in mark_char_table (ptr=0x846dca8) at alloc.c:5415
#57 0x081944d1 in mark_object (arg=138826062) at alloc.c:5702
#58 0x08194515 in mark_object (arg=141221514) at alloc.c:5595
#59 0x08194bb7 in mark_vectorlike (ptr=0x8576368) at alloc.c:5391
#60 0x08194358 in mark_object (arg=139907954) at alloc.c:5591
#61 0x08194bb7 in mark_vectorlike (ptr=0x8a3fbc0) at alloc.c:5391
#62 0x08194358 in mark_object (arg=142383258) at alloc.c:5591
#63 0x081944d1 in mark_object (arg=141985334) at alloc.c:5702
#64 0x081944d1 in mark_object (arg=141985846) at alloc.c:5702
#65 0x081944d1 in mark_object (arg=141983494) at alloc.c:5702
#66 0x081944d1 in mark_object (arg=141982494) at alloc.c:5702
#67 0x081944d1 in mark_object (arg=142004046) at alloc.c:5702
#68 0x081944d1 in mark_object (arg=142004830) at alloc.c:5702
#69 0x08194515 in mark_object (arg=138899458) at alloc.c:5595
#70 0x08194bb7 in mark_vectorlike (ptr=0x8b1bc58) at alloc.c:5391
#71 0x08194358 in mark_object (arg=138899506) at alloc.c:5591
#72 0x08194bb7 in mark_vectorlike (ptr=0x8663448) at alloc.c:5391
#73 0x08194358 in mark_object (arg=138898810) at alloc.c:5591
#74 0x08194bb7 in mark_vectorlike (ptr=0x8ae2038) at alloc.c:5391
#75 0x081944d1 in mark_object (arg=139792686) at alloc.c:5702
#76 0x081944a1 in mark_object (arg=145629373) at alloc.c:5538
#77 0x08194358 in mark_object (arg=145857562) at alloc.c:5591
#78 0x08194bb7 in mark_vectorlike (ptr=0x857b058) at alloc.c:5391
#79 0x08194358 in mark_object (arg=139199954) at alloc.c:5591
#80 0x081944d1 in mark_object (arg=139789422) at alloc.c:5702
#81 0x081944d1 in mark_object (arg=139789406) at alloc.c:5702
#82 0x08194515 in mark_object (arg=139171558) at alloc.c:5595
#83 0x081944d1 in mark_object (arg=139170694) at alloc.c:5702
#84 0x081944d1 in mark_object (arg=139038830) at alloc.c:5702
#85 0x08194363 in mark_object (arg=139891002) at alloc.c:5592
#86 0x081944d1 in mark_object (arg=142059206) at alloc.c:5702
#87 0x081944d1 in mark_object (arg=142078702) at alloc.c:5702
#88 0x08194515 in mark_object (arg=142391666) at alloc.c:5595
#89 0x08194bb7 in mark_vectorlike (ptr=0x8b166e8) at alloc.c:5391
#90 0x08194358 in mark_object (arg=139631874) at alloc.c:5591
#91 0x081944d1 in mark_object (arg=139759566) at alloc.c:5702
#92 0x081944d1 in mark_object (arg=139300646) at alloc.c:5702
#93 0x08194363 in mark_object (arg=139316346) at alloc.c:5592
#94 0x081944d1 in mark_object (arg=139755950) at alloc.c:5702
#95 0x08194363 in mark_object (arg=142463418) at alloc.c:5592
#96 0x081944d1 in mark_object (arg=145746174) at alloc.c:5702
#97 0x08194bb7 in mark_vectorlike (ptr=0x86630f8) at alloc.c:5391
#98 0x081944d1 in mark_object (arg=139706910) at alloc.c:5702
#99 0x08194515 in mark_object (arg=142069646) at alloc.c:5595
#100 0x081944d1 in mark_object (arg=139707278) at alloc.c:5702
#101 0x081944d1 in mark_object (arg=139707342) at alloc.c:5702
#102 0x08194358 in mark_object (arg=142424706) at alloc.c:5591
#103 0x081944d1 in mark_object (arg=142088286) at alloc.c:5702
#104 0x081944d1 in mark_object (arg=142091542) at alloc.c:5702
#105 0x081944d1 in mark_object (arg=142091310) at alloc.c:5702
#106 0x08194515 in mark_object (arg=145794842) at alloc.c:5595
#107 0x08194bb7 in mark_vectorlike (ptr=0x8b1ad98) at alloc.c:5391
#108 0x08194358 in mark_object (arg=139317314) at alloc.c:5591
#109 0x08194bb7 in mark_vectorlike (ptr=0x8b02158) at alloc.c:5391
#110 0x08194358 in mark_object (arg=140128634) at alloc.c:5591
#111 0x08194bb7 in mark_vectorlike (ptr=0x8b02288) at alloc.c:5391
#112 0x08194358 in mark_object (arg=141073730) at alloc.c:5591
#113 0x08194b32 in mark_char_table (ptr=0x8adbdc8) at alloc.c:5418
#114 0x08194b73 in mark_char_table (ptr=0x881d278) at alloc.c:5415
#115 0x081944d1 in mark_object (arg=139422566) at alloc.c:5702
#116 0x08194515 in mark_object (arg=140007178) at alloc.c:5595
#117 0x08194bb7 in mark_vectorlike (ptr=0x87e5170) at alloc.c:5391
#118 0x08194358 in mark_object (arg=139390306) at alloc.c:5591
#119 0x081944d1 in mark_object (arg=142048814) at alloc.c:5702
#120 0x08194515 in mark_object (arg=142242466) at alloc.c:5595
#121 0x081944d1 in mark_object (arg=139381926) at alloc.c:5702
#122 0x081944d1 in mark_object (arg=139382614) at alloc.c:5702
#123 0x08194358 in mark_object (arg=142384978) at alloc.c:5591
#124 0x081944d1 in mark_object (arg=142008078) at alloc.c:5702
#125 0x081944d1 in mark_object (arg=142008374) at alloc.c:5702
#126 0x08194515 in mark_object (arg=145857610) at alloc.c:5595
#127 0x08194bb7 in mark_vectorlike (ptr=0x86693a8) at alloc.c:5391
#128 0x08194358 in mark_object (arg=139576830) at alloc.c:5591
#129 0x081944d1 in mark_object (arg=139048462) at alloc.c:5702
#130 0x08194363 in mark_object (arg=138862962) at alloc.c:5592
#131 0x081944d1 in mark_object (arg=139165646) at alloc.c:5702
#132 0x081944d1 in mark_object (arg=139165814) at alloc.c:5702
#133 0x081944d1 in mark_object (arg=139165878) at alloc.c:5702
#134 0x08194515 in mark_object (arg=139592874) at alloc.c:5595
#135 0x081944d1 in mark_object (arg=139246046) at alloc.c:5702
#136 0x08194515 in mark_object (arg=142441346) at alloc.c:5595
#137 0x081944d1 in mark_object (arg=142122510) at alloc.c:5702
#138 0x08194515 in mark_object (arg=142441226) at alloc.c:5595
#139 0x081944d1 in mark_object (arg=142121390) at alloc.c:5702
#140 0x081944d1 in mark_object (arg=139280198) at alloc.c:5702
#141 0x081944d1 in mark_object (arg=139280142) at alloc.c:5702
#142 0x08194363 in mark_object (arg=141375026) at alloc.c:5592
#143 0x08194bb7 in mark_vectorlike (ptr=0x8688600) at alloc.c:5391
#144 0x08194358 in mark_object (arg=141331954) at alloc.c:5591
#145 0x08194bb7 in mark_vectorlike (ptr=0x8477490) at alloc.c:5391
#146 0x08194358 in mark_object (arg=141103034) at alloc.c:5591
#147 0x08194b32 in mark_char_table (ptr=0x8696e90) at alloc.c:5418
#148 0x08194b73 in mark_char_table (ptr=0x8a3d300) at alloc.c:5415
#149 0x081944d1 in mark_object (arg=142203630) at alloc.c:5702
#150 0x08194515 in mark_object (arg=141331978) at alloc.c:5595
#151 0x08194bb7 in mark_vectorlike (ptr=0x868b000) at alloc.c:5391
#152 0x08194358 in mark_object (arg=142151086) at alloc.c:5591
#153 0x08194859 in mark_object (arg=142379122) at alloc.c:5611
#154 0x081944d1 in mark_object (arg=139746694) at alloc.c:5702
#155 0x081944d1 in mark_object (arg=139746678) at alloc.c:5702
#156 0x08194975 in mark_buffer (buf=<optimized out>) at alloc.c:5762
#157 mark_object (arg=138859077) at alloc.c:5520
#158 0x0819484e in mark_object (arg=139281542) at alloc.c:5610
#159 0x081944d1 in mark_object (arg=139382870) at alloc.c:5702
#160 0x08194363 in mark_object (arg=139133042) at alloc.c:5592
#161 0x08194bb7 in mark_vectorlike (ptr=0x86ba970) at alloc.c:5391
#162 0x08194358 in mark_object (arg=141370914) at alloc.c:5591
#163 0x08194bb7 in mark_vectorlike (ptr=0x866e4f0) at alloc.c:5391
#164 0x08194358 in mark_object (arg=139304206) at alloc.c:5591
#165 0x08194515 in mark_object (arg=139090634) at alloc.c:5595
#166 0x081944d1 in mark_object (arg=139303702) at alloc.c:5702
#167 0x081944d1 in mark_object (arg=139063790) at alloc.c:5702
#168 0x081944d1 in mark_object (arg=139050518) at alloc.c:5702
#169 0x08194363 in mark_object (arg=139086778) at alloc.c:5592
#170 0x08194b32 in mark_char_table (ptr=0x848fc78) at alloc.c:5418
#171 0x08194b73 in mark_char_table (ptr=0x846df28) at alloc.c:5415
#172 0x081944d1 in mark_object (arg=138826094) at alloc.c:5702
#173 0x08194358 in mark_object (arg=139813946) at alloc.c:5591
#174 0x081944d1 in mark_object (arg=139239526) at alloc.c:5702
#175 0x081944d1 in mark_object (arg=139246566) at alloc.c:5702
#176 0x08194363 in mark_object (arg=139813922) at alloc.c:5592
#177 0x081944d1 in mark_object (arg=139279814) at alloc.c:5702
#178 0x08194363 in mark_object (arg=142249050) at alloc.c:5592
#179 0x08194bb7 in mark_vectorlike (ptr=0x86afc10) at alloc.c:5391
#180 0x08194515 in mark_object (arg=142440402) at alloc.c:5595
#181 0x081944d1 in mark_object (arg=142145142) at alloc.c:5702
#182 0x081944d1 in mark_object (arg=139424534) at alloc.c:5702
#183 0x08194363 in mark_object (arg=139373402) at alloc.c:5592
#184 0x08194bb7 in mark_vectorlike (ptr=0x8b163f0) at alloc.c:5391
#185 0x08194358 in mark_object (arg=139210106) at alloc.c:5591
#186 0x08194bb7 in mark_vectorlike (ptr=0x8b1e850) at alloc.c:5391
#187 0x08194358 in mark_object (arg=139892794) at alloc.c:5591
#188 0x08194bb7 in mark_vectorlike (ptr=0x8a3d728) at alloc.c:5391
#189 0x08194358 in mark_object (arg=141103490) at alloc.c:5591
#190 0x08194bb7 in mark_vectorlike (ptr=0x8a3ddc0) at alloc.c:5391
#191 0x08194358 in mark_object (arg=145858162) at alloc.c:5591
#192 0x081944d1 in mark_object (arg=142104846) at alloc.c:5702
#193 0x081944d1 in mark_object (arg=142132110) at alloc.c:5702
#194 0x081944d1 in mark_object (arg=142035670) at alloc.c:5702
#195 0x08194515 in mark_object (arg=145858066) at alloc.c:5595
#196 0x08194bb7 in mark_vectorlike (ptr=0x8b2aa40) at alloc.c:5391
#197 0x08194358 in mark_object (arg=139219698) at alloc.c:5591
#198 0x08194bb7 in mark_vectorlike (ptr=0x8b2abf8) at alloc.c:5391
#199 0x08194358 in mark_object (arg=139892962) at alloc.c:5591
#200 0x081944d1 in mark_object (arg=139280550) at alloc.c:5702
#201 0x08194515 in mark_object (arg=138959538) at alloc.c:5595
#202 0x08194bb7 in mark_vectorlike (ptr=0x8a45918) at alloc.c:5391
#203 0x08194358 in mark_object (arg=142158054) at alloc.c:5591
#204 0x08194363 in mark_object (arg=142157838) at alloc.c:5592
#205 0x08194363 in mark_object (arg=139802962) at alloc.c:5592
#206 0x08194bb7 in mark_vectorlike (ptr=0x881d020) at alloc.c:5391
#207 0x08194358 in mark_object (arg=142724138) at alloc.c:5591
#208 0x081944d1 in mark_object (arg=142130574) at alloc.c:5702
#209 0x08194363 in mark_object (arg=142130558) at alloc.c:5592
#210 0x08194363 in mark_object (arg=139856842) at alloc.c:5592
#211 0x08194358 in mark_object (arg=139341802) at alloc.c:5591
#212 0x081944d1 in mark_object (arg=139236190) at alloc.c:5702
#213 0x081944d1 in mark_object (arg=139304134) at alloc.c:5702
#214 0x081944d1 in mark_object (arg=139158982) at alloc.c:5702
#215 0x08194363 in mark_object (arg=138915594) at alloc.c:5592
#216 0x081944d1 in mark_object (arg=139158902) at alloc.c:5702
#217 0x081944d1 in mark_object (arg=139173838) at alloc.c:5702
#218 0x081944d1 in mark_object (arg=139036718) at alloc.c:5702
#219 0x08194515 in mark_object (arg=139342402) at alloc.c:5595
#220 0x081944d1 in mark_object (arg=139301334) at alloc.c:5702
#221 0x081944d1 in mark_object (arg=139301286) at alloc.c:5702
#222 0x08194363 in mark_object (arg=139543494) at alloc.c:5592
#223 0x081944d1 in mark_object (arg=139542366) at alloc.c:5702
#224 0x081944d1 in mark_object (arg=139484606) at alloc.c:5702
#225 0x08194363 in mark_object (arg=139049038) at alloc.c:5592
#226 0x08194363 in mark_object (arg=139574558) at alloc.c:5592
#227 0x08194363 in mark_object (arg=139574494) at alloc.c:5592
#228 0x081944d1 in mark_object (arg=139049462) at alloc.c:5702
#229 0x08194363 in mark_object (arg=138862914) at alloc.c:5592
#230 0x081944d1 in mark_object (arg=139037230) at alloc.c:5702
#231 0x081944d1 in mark_object (arg=139037214) at alloc.c:5702
#232 0x08194363 in mark_object (arg=139513306) at alloc.c:5592
#233 0x08194b32 in mark_char_table (ptr=0x848ffe0) at alloc.c:5418
#234 0x08194b73 in mark_char_table (ptr=0x846dde8) at alloc.c:5415
#235 0x081944d1 in mark_object (arg=138826078) at alloc.c:5702
#236 0x08194515 in mark_object (arg=138871842) at alloc.c:5595
#237 0x081944d1 in mark_object (arg=142081110) at alloc.c:5702
#238 0x08194363 in mark_object (arg=142433946) at alloc.c:5592
#239 0x081944d1 in mark_object (arg=142111662) at alloc.c:5702
#240 0x081944d1 in mark_object (arg=142111574) at alloc.c:5702
#241 0x08194363 in mark_object (arg=139446734) at alloc.c:5592
#242 0x081944d1 in mark_object (arg=139446742) at alloc.c:5702
#243 0x081944d1 in mark_object (arg=139446574) at alloc.c:5702
#244 0x08194363 in mark_object (arg=142189014) at alloc.c:5592
#245 0x081944d1 in mark_object (arg=142188998) at alloc.c:5702
#246 0x08194363 in mark_object (arg=139203514) at alloc.c:5592
#247 0x081944d1 in mark_object (arg=139240590) at alloc.c:5702
#248 0x081944d1 in mark_object (arg=139301102) at alloc.c:5702
#249 0x08194363 in mark_object (arg=139038926) at alloc.c:5592
#250 0x081944d1 in mark_object (arg=139039046) at alloc.c:5702
#251 0x08194515 in mark_object (arg=139802986) at alloc.c:5595
#252 0x081944d1 in mark_object (arg=142151486) at alloc.c:5702
#253 0x081f668f in traverse_intervals_noorder (tree=0x858e8c8, function=0x8194bd0 <mark_interval>, 
    arg=138839322) at intervals.c:211
#254 0x0819184d in mark_interval_tree (tree=<optimized out>) at alloc.c:1552
#255 0x081949a2 in mark_buffer (buf=<optimized out>) at alloc.c:5739
#256 mark_object (arg=145858821) at alloc.c:5520
#257 0x0819484e in mark_object (arg=139198210) at alloc.c:5610
#258 0x081944d1 in mark_object (arg=139172230) at alloc.c:5702
#259 0x08194975 in mark_buffer (buf=<optimized out>) at alloc.c:5762
#260 mark_object (arg=144909237) at alloc.c:5520
#261 0x0819484e in mark_object (arg=138917834) at alloc.c:5610
#262 0x081944d1 in mark_object (arg=139486454) at alloc.c:5702
#263 0x081944d1 in mark_object (arg=139486438) at alloc.c:5702
#264 0x08194975 in mark_buffer (buf=<optimized out>) at alloc.c:5762
#265 mark_object (arg=139007421) at alloc.c:5520
#266 0x0819484e in mark_object (arg=139102682) at alloc.c:5610
#267 0x081944d1 in mark_object (arg=139838422) at alloc.c:5702
#268 0x08194363 in mark_object (arg=142384490) at alloc.c:5592
#269 0x081944d1 in mark_object (arg=142056454) at alloc.c:5702
#270 0x081944d1 in mark_object (arg=139162518) at alloc.c:5702
#271 0x08194363 in mark_object (arg=138860410) at alloc.c:5592
#272 0x081944d1 in mark_object (arg=142135822) at alloc.c:5702
#273 0x081944a1 in mark_object (arg=144984461) at alloc.c:5538
#274 0x08194358 in mark_object (arg=145858354) at alloc.c:5591
#275 0x08194bb7 in mark_vectorlike (ptr=0x8466d38) at alloc.c:5391
#276 0x08194d84 in Fgarbage_collect () at alloc.c:5099
#277 0x081ab536 in eval_sub (form=139285542) at eval.c:2239
#278 0x081ae303 in Feval (form=139285542, lexical=138839322) at eval.c:2198
#279 0x0813d1a9 in top_level_2 () at keyboard.c:1168
#280 0x081aa83d in internal_condition_case (bfun=0x813d190 <top_level_2>, handlers=138870354, 
    hfun=0x813ec10 <cmd_error>) at eval.c:1509
#281 0x0813d9a5 in top_level_1 (ignore=138839322) at keyboard.c:1176
#282 0x081aa759 in internal_catch (tag=138868330, func=0x813d940 <top_level_1>, arg=138839322)
    at eval.c:1266
#283 0x0813e72c in command_loop () at keyboard.c:1131
#284 recursive_edit_1 () at keyboard.c:758
#285 0x0813ea3e in Frecursive_edit () at keyboard.c:822
#286 0x080598c0 in main (argc=4, argv=Cannot access memory at address 0xa
) at emacs.c:1715

bug#8789: 23.3; debug backtrace buffer changes window on step-through

[martin rudalics]

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

 > Here it comes, produced today with "GNU Emacs 24.0.93.1
 > (i486-pc-linux-gnu, GTK+ Version 3.2.3)\n of 2012-02-22 on zelenka,
 > modified by Debian".

Thank you.  Is it true that you can reproduce this with the given recipe
at will?  The combination of

 > Content of *Backtrace* before the crash:
 >
 > * (set-window-configuration wconfig)

and

 > (gdb) bt
 > #0  0xb7fe2424 in __kernel_vsyscall ()
 > #1  0xb6a65c16 in kill () from /lib/i386-linux-gnu/i686/cmov/libc.so.6
 > #2  0x08139d78 in abort () at emacs.c:394
 > #3  0x0819441e in mark_object (arg=139036542) at alloc.c:5706

seems to indicate a collector problem when recovering from a window
excursion.  Reproducing a collector crash, however, is usually very
difficult.

Meanwhile please try the patch attached to check whether it (1) solves
the original problem and (2) results in this crash as well.

Thanks, martin

[-- Attachment #2: record_window_buffer.diff --]
[-- Type: text/plain, Size: 14696 bytes --]

=== modified file 'lisp/emacs-lisp/debug.el'
--- lisp/emacs-lisp/debug.el	2012-01-19 07:21:25 +0000
+++ lisp/emacs-lisp/debug.el	2012-02-26 18:55:02 +0000
@@ -194,7 +194,8 @@
 		  ;; Place an extra debug-on-exit for macro's.
 		  (when (eq 'lambda (car-safe (cadr (backtrace-frame 4))))
 		    (backtrace-debug 5 t)))
-                (pop-to-buffer debugger-buffer)
+                (pop-to-buffer
+		 debugger-buffer '((display-buffer-reuse-window display-buffer-in-previous-window) . nil))
 		(debugger-mode)
 		(debugger-setup-buffer debugger-args)
 		(when noninteractive
@@ -245,7 +246,8 @@
                     ;; best to do that.
                     (bury-buffer))))
             (unless debugger-previous-state
-              (kill-buffer debugger-buffer)))
+              ;; (kill-buffer debugger-buffer)
+	      ))
           ;; Restore the previous state of the debugger-buffer, in case we were
           ;; in a recursive invocation of the debugger.
           (when (buffer-live-p debugger-buffer)

=== modified file 'lisp/window.el'
--- lisp/window.el	2012-02-12 05:10:30 +0000
+++ lisp/window.el	2012-02-26 19:09:54 +0000
@@ -2482,69 +2482,6 @@
 
 ;;; Windows and buffers.
 
-;; `prev-buffers' and `next-buffers' are two reserved window slots used
-;; for (1) determining which buffer to show in the window when its
-;; buffer shall be buried or killed and (2) which buffer to show for
-;; `switch-to-prev-buffer' and `switch-to-next-buffer'.
-
-;; `prev-buffers' consists of <buffer, window-start, window-point>
-;; triples.  The entries on this list are ordered by the time their
-;; buffer has been removed from the window, the most recently removed
-;; buffer's entry being first.  The window-start and window-point
-;; components are `window-start' and `window-point' at the time the
-;; buffer was removed from the window which implies that the entry must
-;; be added when `set-window-buffer' removes the buffer from the window.
-
-;; `next-buffers' is the list of buffers that have been replaced
-;; recently by `switch-to-prev-buffer'.  These buffers are the least
-;; preferred candidates of `switch-to-prev-buffer' and the preferred
-;; candidates of `switch-to-next-buffer' to switch to.  This list is
-;; reset to nil by any action changing the window's buffer with the
-;; exception of `switch-to-prev-buffer' and `switch-to-next-buffer'.
-;; `switch-to-prev-buffer' pushes the buffer it just replaced on it,
-;; `switch-to-next-buffer' pops the last pushed buffer from it.
-
-;; Both `prev-buffers' and `next-buffers' may reference killed buffers
-;; if such a buffer was killed while the window was hidden within a
-;; window configuration.  Such killed buffers get removed whenever
-;; `switch-to-prev-buffer' or `switch-to-next-buffer' encounter them.
-
-;; The following function is called by `set-window-buffer' _before_ it
-;; replaces the buffer of the argument window with the new buffer.
-(defun record-window-buffer (&optional window)
-  "Record WINDOW's buffer.
-WINDOW must be a live window and defaults to the selected one."
-  (let* ((window (window-normalize-window window t))
-	 (buffer (window-buffer window))
-	 (entry (assq buffer (window-prev-buffers window))))
-    ;; Reset WINDOW's next buffers.  If needed, they are resurrected by
-    ;; `switch-to-prev-buffer' and `switch-to-next-buffer'.
-    (set-window-next-buffers window nil)
-
-    (when entry
-      ;; Remove all entries for BUFFER from WINDOW's previous buffers.
-      (set-window-prev-buffers
-       window (assq-delete-all buffer (window-prev-buffers window))))
-
-    ;; Don't record insignificant buffers.
-    (unless (eq (aref (buffer-name buffer) 0) ?\s)
-      ;; Add an entry for buffer to WINDOW's previous buffers.
-      (with-current-buffer buffer
-	(let ((start (window-start window))
-	      (point (window-point-1 window)))
-	  (setq entry
-		(cons buffer
-		      (if entry
-			  ;; We have an entry, update marker positions.
-			  (list (set-marker (nth 1 entry) start)
-				(set-marker (nth 2 entry) point))
-			;; Make new markers.
-			(list (copy-marker start)
-			      (copy-marker point)))))
-
-	  (set-window-prev-buffers
-	   window (cons entry (window-prev-buffers window))))))))
-
 (defun unrecord-window-buffer (&optional window buffer)
   "Unrecord BUFFER in WINDOW.
 WINDOW must be a live window and defaults to the selected one.
@@ -4846,6 +4783,50 @@
       (and pop-up-windows
 	   (display-buffer-pop-up-window buffer alist))))
 
+(defun display-buffer-in-previous-window (buffer alist)
+  "Display BUFFER in a window previously showing it.
+If ALIST has a non-nil `inhibit-same-window' entry, the selected
+window is not eligible for reuse.
+
+If ALIST contains a `reusable-frames' entry, its value determines
+which frames to search for a reusable window:
+  nil -- the selected frame (actually the last non-minibuffer frame)
+  A frame   -- just that frame
+  `visible' -- all visible frames
+  0   -- all frames on the current terminal
+  t   -- all frames.
+
+If ALIST contains no `reusable-frames' entry, search just the
+selected frame if `display-buffer-reuse-frames' and
+`pop-up-frames' are both nil; search all frames on the current
+terminal if either of those variables is non-nil."
+  (let* ((alist-entry (assq 'reusable-frames alist))
+	 (inhibit-same-window
+	  (cdr (assq 'inhibit-same-window alist)))
+	 (frames (cond
+		  (alist-entry (cdr alist-entry))
+		  ((if (eq pop-up-frames 'graphic-only)
+		       (display-graphic-p)
+		     pop-up-frames)
+		   0)
+		  (display-buffer-reuse-frames 0)
+		  (t (last-nonminibuffer-frame))))
+	 best-window second-best-window window)
+    (when inhibit-same-window (ding))
+    (catch 'best
+      (dolist (window (window-list-1 (frame-first-window) 'nomini frames))
+	(when (and (assq buffer (window-prev-buffers window))
+		   (not (window-dedicated-p window)))
+	  (if (eq window (selected-window))
+	      (unless inhibit-same-window
+		(setq second-best-window window))
+	    (setq best-window window)
+	    (throw 'best t)))))
+
+    (when (setq window (or best-window second-best-window))
+      (display-buffer-record-window 'reuse window buffer)
+      (window--display-buffer-2 buffer window display-buffer-mark-dedicated))))
+
 (defun display-buffer-use-some-window (buffer alist)
   "Display BUFFER in an existing window.
 Search for a usable window, set that window to the buffer, and

=== modified file 'src/window.c'
--- src/window.c	2012-02-23 17:40:33 +0000
+++ src/window.c	2012-02-27 07:43:06 +0000
@@ -51,7 +51,7 @@
 #endif
 
 Lisp_Object Qwindowp, Qwindow_live_p;
-static Lisp_Object Qwindow_configuration_p, Qrecord_window_buffer;
+static Lisp_Object Qwindow_configuration_p;
 static Lisp_Object Qwindow_deletable_p, Qdelete_window, Qdisplay_buffer;
 static Lisp_Object Qreplace_buffer_in_windows, Qget_mru_window;
 static Lisp_Object Qwindow_resize_root_window, Qwindow_resize_root_window_vertically;
@@ -1647,15 +1647,41 @@
 
 DEFUN ("set-window-prev-buffers", Fset_window_prev_buffers,
        Sset_window_prev_buffers, 2, 2, 0,
-       doc: /* Set WINDOW's previous buffers to PREV-BUFFERS.
+       doc:	     /* Set WINDOW's previous buffers to PREV-BUFFERS.
 WINDOW must be a live window and defaults to the selected one.
 
 PREV-BUFFERS should be a list of elements (BUFFER WINDOW-START POS),
 where BUFFER is a buffer, WINDOW-START is the start position of the
 window for that buffer, and POS is a window-specific point value.  */)
-     (Lisp_Object window, Lisp_Object prev_buffers)
+  (Lisp_Object window, Lisp_Object prev_buffers)
 {
-  return decode_window (window)->prev_buffers = prev_buffers;
+  register struct window *w = decode_window (window);
+
+  if (NILP (prev_buffers))
+    return w->prev_buffers = Qnil;
+  else if (!CONSP (prev_buffers))
+    return w->prev_buffers;
+  else
+    {
+      /* Run cycle detection on prev_buffers.  */
+      Lisp_Object tortoise, hare;
+
+      hare = tortoise = prev_buffers;
+      while (CONSP (hare))
+	{
+	  hare = XCDR (hare);
+	  if (!CONSP (hare))
+	    break;
+
+	  hare = XCDR (hare);
+	  tortoise = XCDR (tortoise);
+
+	  if (EQ (hare, tortoise))
+	    return w->prev_buffers;
+	}
+
+      return w->prev_buffers = prev_buffers;
+    }
 }
 
 DEFUN ("window-next-buffers", Fwindow_next_buffers, Swindow_next_buffers,
@@ -1674,7 +1700,33 @@
 NEXT-BUFFERS should be a list of buffers.  */)
      (Lisp_Object window, Lisp_Object next_buffers)
 {
-  return decode_window (window)->next_buffers = next_buffers;
+  register struct window *w = decode_window (window);
+
+  if (NILP (next_buffers))
+    return w->next_buffers = Qnil;
+  else if (!CONSP (next_buffers))
+    return w->next_buffers;
+  else
+    {
+      /* Run cycle detection on next_buffers.  */
+      Lisp_Object tortoise, hare;
+
+      hare = tortoise = next_buffers;
+      while (CONSP (hare))
+	{
+	  hare = XCDR (hare);
+	  if (!CONSP (hare))
+	    break;
+
+	  hare = XCDR (hare);
+	  tortoise = XCDR (tortoise);
+
+	  if (EQ (hare, tortoise))
+	    return w->next_buffers;
+	}
+
+      return w->next_buffers = next_buffers;
+    }
 }
 
 DEFUN ("window-parameters", Fwindow_parameters, Swindow_parameters,
@@ -2940,13 +2992,94 @@
 DEFUN ("run-window-configuration-change-hook", Frun_window_configuration_change_hook,
        Srun_window_configuration_change_hook, 1, 1, 0,
        doc: /* Run `window-configuration-change-hook' for FRAME.  */)
-     (Lisp_Object frame)
+  (Lisp_Object frame)
 {
   CHECK_LIVE_FRAME (frame);
   run_window_configuration_change_hook (XFRAME (frame));
   return Qnil;
 }
 
+/* `prev_buffers' and `next_buffers' are two reserved window slots used
+for determining
+
+(1) which buffer to show in the window when its buffer shall be buried
+    or killed, and
+
+(2) which buffer to show for `switch-to-prev-buffer' and
+    `switch-to-next-buffer'.
+
+`prev_buffers' is built from <buffer, window-start, window-point>
+triples.  The entries on this list are ordered by the time their buffer
+has been removed from the window, the most recently removed buffer's
+entry being first.  The window-start and window-point components are
+`window-start' and `window-point' at the time the buffer was removed
+from the window which implies that the entry must be added when
+Fset_window_buffer removes the buffer from the window.
+
+`next_buffers' is the list of buffers that have been replaced recently
+by `switch-to-prev-buffer'.  These buffers are the least preferred
+candidates of `switch-to-prev-buffer' and the preferred candidates of
+`switch-to-next-buffer' to switch to.  This list is reset to nil by any
+action changing the window's buffer with the exception of
+`switch-to-prev-buffer' and `switch-to-next-buffer'.
+`switch-to-prev-buffer' pushes the buffer it just replaced on it,
+`switch-to-next-buffer' pops the last pushed buffer from it.
+
+Both `prev_buffers' and `next_buffers' may reference killed buffers if
+such a buffer was killed while the window was hidden within a window
+configuration.  Such killed buffers get removed whenever
+`switch-to-prev-buffer' or `switch-to-next-buffer' encounter them.
+
+The following function must be called by Fset_window_buffer and
+Fset_window_configuration _before_ these replace the buffer of the
+argument window with the new buffer.  */
+
+static void
+record_window_buffer (Lisp_Object window)
+{
+  struct window *w = XWINDOW (window);
+  Lisp_Object buffer = w->buffer;
+  struct buffer *b = XBUFFER (buffer);
+  Lisp_Object entry = Fassq (buffer, w->prev_buffers);
+  Lisp_Object start_marker, point_marker, point;
+  int count = SPECPDL_INDEX ();
+
+  /* Return immediately if BUFFER is not a buffer.  */
+  if (!BUFFERP (buffer))
+    return;
+
+  /* Reset WINDOW's next buffers.  If needed, they are resurrected by
+     `switch-to-prev-buffer' and `switch-to-next-buffer'.  */
+  w->next_buffers = Qnil;
+
+  if (!NILP (entry))
+    /* Remove all entries for BUFFER from WINDOW's previous buffers.  */
+    w->prev_buffers = Fdelq (entry, w->prev_buffers);
+
+  if (NILP (BVAR (b, name)) || SREF (BVAR (b, name), 0) == ' ')
+    /* Don't record dead or insignificant buffers.  */
+    return;
+
+  if (current_buffer != b)
+    {
+      /* Make sure Fpoint below gets the right buffer.  */
+      record_unwind_protect (set_buffer_if_live, Fcurrent_buffer ());
+      set_buffer_internal (b);
+    }
+
+  /* Reuse existing markers if possible.  */
+  start_marker = !NILP (entry) ? Fnth (make_number (1), entry) : Fmake_marker ();
+  point_marker = !NILP (entry) ? Fnth (make_number (2), entry) : Fmake_marker ();
+  point = EQ (window, selected_window) ? Fpoint () : w->pointm;
+  set_marker_restricted (start_marker, w->start, buffer);
+  set_marker_restricted (point_marker, point, buffer);
+  w->prev_buffers = Fcons (list3 (buffer, start_marker, point_marker),
+			   w->prev_buffers);
+
+  unbind_to (count, Qnil);
+}
+
+
 /* Make WINDOW display BUFFER as its contents.  RUN_HOOKS_P non-zero
    means it's allowed to run hooks.  See make_frame for a case where
    it's not allowed.  KEEP_MARGINS_P non-zero means that the current
@@ -3094,7 +3227,7 @@
 	       dedication.  */
 	    w->dedicated = Qnil;
 
-	  call1 (Qrecord_window_buffer, window);
+	  record_window_buffer (window);
 	}
 
       unshow_buffer (w);
@@ -5587,6 +5720,8 @@
 	  else if (!NILP (BVAR (XBUFFER (p->buffer), name)))
 	    /* If saved buffer is alive, install it.  */
 	    {
+	      if (!EQ (w->buffer, p->buffer))
+		record_window_buffer (window);
 	      w->buffer = p->buffer;
 	      w->start_at_line_beg = p->start_at_line_beg;
 	      set_marker_restricted (w->start, p->start, w->buffer);
@@ -5620,6 +5755,7 @@
 		   && SCHARS (auto_buffer_name) != 0
 		   && !NILP (w->buffer = Fget_buffer_create (auto_buffer_name)))
 	    {
+	      record_window_buffer (window);
 	      set_marker_restricted (w->start, make_number (0), w->buffer);
 	      set_marker_restricted (w->pointm, make_number (0), w->buffer);
 	      w->start_at_line_beg = Qt;
@@ -5627,6 +5763,7 @@
 	  else
 	    /* Window has no live buffer, get one.  */
 	    {
+	      record_window_buffer (window);
 	      /* Get the buffer via other_buffer_safely in order to
 	      avoid showing an unimportant buffer and, if necessary, to
 	      recreate *scratch* in the course (part of Juanma's bs-show
@@ -6509,7 +6646,6 @@
   DEFSYM (Qsafe, "safe");
   DEFSYM (Qdisplay_buffer, "display-buffer");
   DEFSYM (Qreplace_buffer_in_windows, "replace-buffer-in-windows");
-  DEFSYM (Qrecord_window_buffer, "record-window-buffer");
   DEFSYM (Qget_mru_window, "get-mru-window");
   DEFSYM (Qtemp_buffer_show_hook, "temp-buffer-show-hook");
   DEFSYM (Qabove, "above");

bug#8789: 23.3; debug backtrace buffer changes window on step-through

[Michael Heerdegen]

martin rudalics <rudalics@gmx.at> writes:

> Is it true that you can reproduce this with the given recipe at will?
> The combination of
>
> > Content of *Backtrace* before the crash:
> >
> > * (set-window-configuration wconfig)
>
> and
>
> > (gdb) bt
> > #0  0xb7fe2424 in __kernel_vsyscall ()
> > #1  0xb6a65c16 in kill () from /lib/i386-linux-gnu/i686/cmov/libc.so.6
> > #2  0x08139d78 in abort () at emacs.c:394
> > #3  0x0819441e in mark_object (arg=139036542) at alloc.c:5706
>
> seems to indicate a collector problem when recovering from a window
> excursion.  Reproducing a collector crash, however, is usually very
> difficult.

Yes, I can reproduce it at will.  I tried a few times again, and
everytime the backtrace looked like this.

> Meanwhile please try the patch attached to check whether it (1) solves
> the original problem and (2) results in this crash as well.

I'm afraid I can't do this, at least not at the moment.  I can't build
Emacs right now - I'm changing residence, having not much time and no
relyable connection to the net.  Maybe someone else can test it?  Or is
it appropriate to test the Elisp parts of your patch seperately?

BTW, I can reproduce the crash on different Gnu/Linux systems, so it's
likely that the crash can be reproduced on other computers as well.


Michael

bug#8789: 23.3; debug backtrace buffer changes window on step-through

[martin rudalics]

I now checked in a fix for this in revision 109937 on trunk.
Please test it.

Thanks, martin

bug#8789: 23.3; debug backtrace buffer changes window on step-through

[Michael Heerdegen]

martin rudalics <rudalics@gmx.at> writes:

> I now checked in a fix for this in revision 109937 on trunk.
> Please test it.

Thanks so much for your work, Martin!

After some quick tests with emacs -Q, as well as with my own setup, I
must say that this works quite well now.  No more "hopping" of the
*Backtrace* buffer, and no crashes.  So, your fix seems ok to me, but
others may make some tests as well with their setups.

Only one wish remains: it is not possible to resize the height of the
window displaying the *Backtrace* buffer durably.  When I resize it with
the mouse in emacs -Q, this is undone when I hit d in the debugger.  It
would be cool if the size of the window could be changed durably.


Regards,

Michael.

bug#8789: 23.3; debug backtrace buffer changes window on step-through

[martin rudalics]

 > Only one wish remains: it is not possible to resize the height of the
 > window displaying the *Backtrace* buffer durably.  When I resize it with
 > the mouse in emacs -Q, this is undone when I hit d in the debugger.  It
 > would be cool if the size of the window could be changed durably.

I committed a fix.  Please try it.

martin

bug#8789: 23.3; debug backtrace buffer changes window on step-through

[Michael Heerdegen]

Hello Martin,

> > Only one wish remains: it is not possible to resize the height of the
> > window displaying the *Backtrace* buffer durably.  When I resize it with
> > the mouse in emacs -Q, this is undone when I hit d in the debugger.  It
> > would be cool if the size of the window could be changed durably.
>
> I committed a fix.  Please try it.

Sorry - but I don't see any difference to what I wrote at this time.  I
use "GNU Emacs 24.2.50.1 (x86_64-pc-linux-gnu, GTK+ Version 3.4.2)\n of
2012-10-18 on dex, modified by Debian" now, so your fix should
definitely be included.  But neither does it work with my setup, nor
with emacs -Q.  I see the same behavior as before.


Michael.

bug#8789: 23.3; debug backtrace buffer changes window on step-through

[martin rudalics]

 >>> Only one wish remains: it is not possible to resize the height of the
 >>> window displaying the *Backtrace* buffer durably.  When I resize it with
 >>> the mouse in emacs -Q, this is undone when I hit d in the debugger.  It
 >>> would be cool if the size of the window could be changed durably.
 >> I committed a fix.  Please try it.
 >
 > Sorry - but I don't see any difference to what I wrote at this time.  I
 > use "GNU Emacs 24.2.50.1 (x86_64-pc-linux-gnu, GTK+ Version 3.4.2)\n of
 > 2012-10-18 on dex, modified by Debian" now, so your fix should
 > definitely be included.  But neither does it work with my setup, nor
 > with emacs -Q.  I see the same behavior as before.

It should have worked from 2012-09-12 until 2012-10-03 but apparently
you never tried in that period ;-)

Anyway, it should now work again.  Please try.

Thanks, martin

bug#8789: 23.3; debug backtrace buffer changes window on step-through

[Drew Adams]

I'm guessing, but I do not know for sure, that it is the change you made for
this bug that has now broken the debugger for me.

For me, *Backtrace* is a special-display buffer, so it is shown in its own,
special-display frame.

In this build, things are not broken (still OK):

In GNU Emacs 24.2.50.1 (i386-mingw-nt5.1.2600)
 of 2012-09-02 on MARVIN
Bzr revision: 109861 eggert@cs.ucla.edu-20120902171035-7mzihil3xd6bjfiy
Windowing system distributor `Microsoft Corp.', version 5.1.2600
Configured using:
 `configure --with-gcc (4.6) --no-opt --enable-checking --cflags
 -ID:/devel/emacs/libs/libXpm-3.5.8/include
 -ID:/devel/emacs/libs/libXpm-3.5.8/src
 -ID:/devel/emacs/libs/libpng-dev_1.4.3-1/include
 -ID:/devel/emacs/libs/zlib-dev_1.2.5-2/include
 -ID:/devel/emacs/libs/giflib-4.1.4-1/include
 -ID:/devel/emacs/libs/jpeg-6b-4/include
 -ID:/devel/emacs/libs/tiff-3.8.2-1/include
 -ID:/devel/emacs/libs/gnutls-3.0.9/include
 -ID:/devel/emacs/libs/libiconv-1.13.1-1-dev/include
 -ID:/devel/emacs/libs/libxml2-2.7.8/include/libxml2'

And in this build, things are broken:

In GNU Emacs 24.2.50.1 (i386-mingw-nt5.1.2600)
 of 2012-09-17 on MARVIN
Bzr revision: 110062 cyd@gnu.org-20120917054104-r93rtwkrtva73ewe
Windowing system distributor `Microsoft Corp.', version 5.1.2600
Configured using:
 `configure --with-gcc (4.7) --no-opt --enable-checking --cflags
 -ID:/devel/emacs/libs/libXpm-3.5.8/include
 -ID:/devel/emacs/libs/libXpm-3.5.8/src
 -ID:/devel/emacs/libs/libpng-dev_1.4.3-1/include
 -ID:/devel/emacs/libs/zlib-dev_1.2.5-2/include
 -ID:/devel/emacs/libs/giflib-4.1.4-1/include
 -ID:/devel/emacs/libs/jpeg-6b-4/include
 -ID:/devel/emacs/libs/tiff-3.8.2-1/include
 -ID:/devel/emacs/libs/gnutls-3.0.9/include
 -ID:/devel/emacs/libs/libiconv-1.13.1-1-dev/include
 -ID:/devel/emacs/libs/libxml2-2.7.8/include/libxml2'

What is broken is this:

Before, the same frame (seemingly) existed throughout.  I could hit `d' any
number of times, and everything was smooth.  I could expand the frame size or
reposition it, and it stayed wherever I put it.

Now, it appears that each time I hit `d' the frame is deleted and a new frame is
created to replace it.  And it is always re-created with the same, default size
and position (top left of screen).

This is horrible.  Not only does the re-creation produce a tremendous
blink/flash, but the repositioning and resizing back to the default position and
size are intolerable.

I cannot see anything useful in the buffer - I need to stretch the frame out
again after each `d' to see anything wide.

And I need to reposition the frame to the right (for example) after each `d', if
I have another frame at the left that I want to continue to see (e.g. a frame
showing the source code, or *Completions*).

If you prefer this as a separate bug report, feel free to copy the above into a
new bug - you have all of the info.  This is with my own setup, which Martin is
pretty familiar with: non-nil popup-frames etc.

For me, this change is a horrible regression - makes the debugger unusable.

bug#8789: 23.3; debug backtrace buffer changes window on step-through

[martin rudalics]

 > Before, the same frame (seemingly) existed throughout.  I could hit `d' any
 > number of times, and everything was smooth.  I could expand the frame size or
 > reposition it, and it stayed wherever I put it.
 >
 > Now, it appears that each time I hit `d' the frame is deleted and a new frame is
 > created to replace it.  And it is always re-created with the same, default size
 > and position (top left of screen).

Try customizing `debugger-bury-or-kill'.

martin

bug#8789: 23.3; debug backtrace buffer changes window on step-through

[Drew Adams]

> Try customizing `debugger-bury-or-kill'.

1. OK, I was not aware of that option; thanks.  Please document it.  (I do not
see it in either the Emacs manual or the Elisp manual.)

2. I tried each of the values listed in the doc string.  None of them had any
effect at all.  Same broken behavior, always: the frame is deleted, then
re-created with the default size and position (i.e., ignoring its previous size
and position).  That re-creation takes perhaps 0.5 sec or 1 sec, which means
that it is visually quite distracting, besides the fact that the size and
position prevent using the debugger efffectively (really, prevent using it at
all).

I am using the regular Emacs debugger, not `edebug'.  E.g., I am using
`debug-on-entry' etc.  Dunno whether that is pertinent.  The doc says nothing
about `edebug', in any case.

3. Wrt the new option's defcustom: If the documented four possible values are
the only possible values, then the defcustom should be rewritten so that the
user can choose (and can only choose) by using the Value Menu.  S?he should not
have to or be allowed to enter a quoted symbol name in a text edit field.

If the documented possible values are not the only possible values, then the doc
string should be updated to mention what other possible values there are and
what they do.

This (#3) is a bug.  Do you want me to file a separate bug report for it?

bug#8789: 23.3; debug backtrace buffer changes window on step-through

[martin rudalics]

 > 1. OK, I was not aware of that option; thanks.  Please document it.  (I do not
 > see it in either the Emacs manual or the Elisp manual.)

It's not yet documented.

 > 2. I tried each of the values listed in the doc string.  None of them had any
 > effect at all.  Same broken behavior, always: the frame is deleted, then
 > re-created with the default size and position (i.e., ignoring its previous size
 > and position).  That re-creation takes perhaps 0.5 sec or 1 sec, which means
 > that it is visually quite distracting, besides the fact that the size and
 > position prevent using the debugger efffectively (really, prevent using it at
 > all).
 >
 > I am using the regular Emacs debugger, not `edebug'.  E.g., I am using
 > `debug-on-entry' etc.  Dunno whether that is pertinent.  The doc says nothing
 > about `edebug', in any case.

I checked in a fix for this in revision 110085.  Please try it.

 > 3. Wrt the new option's defcustom: If the documented four possible values are
 > the only possible values, then the defcustom should be rewritten so that the
 > user can choose (and can only choose) by using the Value Menu.  S?he should not
 > have to or be allowed to enter a quoted symbol name in a text edit field.
 >
 > If the documented possible values are not the only possible values, then the doc
 > string should be updated to mention what other possible values there are and
 > what they do.
 >
 > This (#3) is a bug.  Do you want me to file a separate bug report for it?

I checked in a fix for this in the same revision.

Thanks, martin

bug#8789: 23.3; debug backtrace buffer changes window on step-through

[Drew Adams]

> It's not yet documented.

OK.  I guess it will be, before the code is in a release.  Thx.

> I checked in a fix for this in revision 110085.  Please try it.
>
> > This (#3) is a bug.  Do you want me to file a separate bug 
> > report for it?
> 
> I checked in a fix for this in the same revision.

Thanks for your fixes.  I'll check the next Windows binary. - Drew

bug#8789: 23.3; debug backtrace buffer changes window on step-through

[Drew Adams]

> Thanks for your fixes.  I'll check the next Windows binary. - Drew

I have not yet been able to do that (no Windows binary), but here is some more
info.  (I have not customized `debugger-bury-or-kill' - the value is still
`bury'.)

Sometimes I can grab the border of the *Backtrace* frame, as usual, and resize
it (even though it goes back to the default size when I hit `d', as described
earlier).

But sometimes I cannot: as soon as I touch the mouse to the frame edge and try
to drag it, the frame disappears!  I can just touch it (e.g. click it) without
it disappearing, but as soon as I try to drag the touched edge, the frame
disappears.  It does not matter which edge (e.g. bottom or right) I try to drag.

No idea what is going on here - I have never seen anything like this.

This happpens systematically when I enter the debugger in a certain context, and
it never seems to happen otherwise.  But that context is far too complex to try
to communicate.  Suffice it to say that this happens.

When it happens I see nothing additional in *Messages*, and there is no crash.
The *Backtrace* frame just disappears, and the mode line indicates that I am no
longer in a recursive edit - IOW, the debugger is exited.  And if I explicitly
visit buffer *Backtrace*, I see that it is indeed empty.

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.

bug#8789: 23.3; debug backtrace buffer changes window on step-through

[martin rudalics]

 >> Thanks for your fixes.  I'll check the next Windows binary. - Drew
 >
 > I have not yet been able to do that (no Windows binary),

It's trivial to get the change from say

http://lists.gnu.org/archive/html/emacs-diffs/2012-09/msg00266.html

and apply it.  You don't have to rebuild Emacs for this change, just recompile
debug.el.

 > but here is some more
 > info.  (I have not customized `debugger-bury-or-kill' - the value is still
 > `bury'.)
 >
 > Sometimes I can grab the border of the *Backtrace* frame, as usual, and resize
 > it (even though it goes back to the default size when I hit `d', as described
 > earlier).

This should have changed now.

 > But sometimes I cannot: as soon as I touch the mouse to the frame edge and try
 > to drag it, the frame disappears!  I can just touch it (e.g. click it) without
 > it disappearing, but as soon as I try to drag the touched edge, the frame
 > disappears.  It does not matter which edge (e.g. bottom or right) I try to drag.
 >
 > No idea what is going on here - I have never seen anything like this.
 >
 > This happpens systematically when I enter the debugger in a certain context, and
 > it never seems to happen otherwise.  But that context is far too complex to try
 > to communicate.  Suffice it to say that this happens.
 >
 > When it happens I see nothing additional in *Messages*, and there is no crash.
 > The *Backtrace* frame just disappears, and the mode line indicates that I am no
 > longer in a recursive edit - IOW, the debugger is exited.  And if I explicitly
 > visit buffer *Backtrace*, I see that it is indeed empty.
 >
 > It is as if trying to drag the frame edge is (sometimes) the equivalent of
 > hitting `q' in the debugger.

Looks like.  Try with my change.  Later we can try to put in some code
immediately before the call to `quit-restore-window' to investigate the
last command or input event that triggers this.

martin

bug#8789: 23.3; debug backtrace buffer changes window on step-through

[Drew Adams]

> It's trivial to get the change from say
> http://lists.gnu.org/archive/html/emacs-diffs/2012-09/msg00266.html
> and apply it.  You don't have to rebuild Emacs for this 
> change, just recompile debug.el.

OK, I did that.  I patched a copy of debug.el (MARTIN-debug.el) and loaded it.
That changed nothing.  I byte-compiled it and loaded that (MARTIN-debug.elc).
That changed nothing.

Everything I have described today still behaved the same, unfortunately.

>  > Sometimes I can grab the border of the *Backtrace* frame, 
>  > as usual, and resize it (even though it goes back to the
>  > default size when I hit `d', as described earlier).
> 
> This should have changed now.

No, it did not appear to have changed - see above.

OK, so I quit that Emacs session and started a new one.  Loaded the patched
debug code first (MARTIN-debug.el).  Now I no longer see the bizarre debugger
effects I described today.  Perhaps something was weird about that session;
dunno.

And I can now resize and reposition the *Backtrace* frame as I could in the
past.  So it seems that this bug is fixed.  Thank you.

However, some things still seem weird.  Dunno whether they happen because I
loaded the MARTIN-debug.elc file (patched debug.el) after the original debug.elc
had already been loaded.  Sometimes during stepping it does blow away my frame
and re-create the frame at the original position and with the original size.
Not sure whether everything is fixed, but feel free to close the bug if you are
done fixing.  I can always reopen the bug if I find something else.

bug#8789: 23.3; debug backtrace buffer changes window on step-through

[Drew Adams]

There seem still to be problems.

emacs -Q

M-x load-file MARTIN-debug.elc

;; That's debug.el, with your patch.
;; If I load the .el instead of the .elc, then the debugger is
;; called even for implement-debugger etc. - a mess.

M-x load-library files.el

M-x debug-on-entry file-remote-p

That puts me immediately into the debugger, with a call to `file-remote-p'.  Why
does debugging file-remote-p cause the debugger to enter even for that M-x
invocation?  There is not even any reading of a file name.

Thereafter, I cannot exit the debugger, no matter what I do.  `c' and `q' seem
to do nothing.  `d' just steps into `file-remote-p'.  Even `C-]' does not exit
the debugger.  I can use C-x k to kill the *Backtrace* buffer, but that leaves
Emacs in a recursive edit, and `C-]' then brings Emacs back into the debugger.
After the `C-x k', *Messages* shows this multiple times, always ending by
entering:

Entering debugger...
Quit
Entering debugger...
Quit
Entering debugger...
Quit
Entering debugger...
Quit
Entering debugger...

This really seems to be a mess.  For me, the debugger is not usable now, even
with emacs -Q.

bug#8789: 23.3; debug backtrace buffer changes window on step-through

[Drew Adams]

Here's another problem.  I would have reported it as a separate bug, but since I
ran into it after loading your patched debug.el I thought perhaps it is best to
report it here.

emacs -Q

M-x load-file MARTIN-debug.elc

M-x load-library files.el

M-x debug-on-entry file-name-nondirectory

C-x 4 f ; or something else, to enter the debugger

In the debugger: hit `e' and enter `last-command', to evaluate that variable.

I get this error:

call-interactively: Wrong type argument: stringp, nil

You should be able to evaluate a variable using `e' in the debugger.

bug#8789: 23.3; debug backtrace buffer changes window on step-through

[martin rudalics]

 > emacs -Q
 >
 > M-x load-file MARTIN-debug.elc
 >
 > M-x load-library files.el
 >
 > M-x debug-on-entry file-name-nondirectory
 >
 > C-x 4 f ; or something else, to enter the debugger
 >
 > In the debugger: hit `e' and enter `last-command', to evaluate that variable.
 >
 > I get this error:
 >
 > call-interactively: Wrong type argument: stringp, nil
 >
 > You should be able to evaluate a variable using `e' in the debugger.

My bad.  I inadvertently removed an assignment in `debug'.  Should work
now as before.  You can pick the change here:

http://bzr.savannah.gnu.org/lh/emacs/trunk/revision/110113

Thanks, martin

bug#8789: 23.3; debug backtrace buffer changes window on step-through

[Drew Adams]

> My bad.  I inadvertently removed an assignment in `debug'.  
> Should work now as before.  You can pick the change here:
> 
> http://bzr.savannah.gnu.org/lh/emacs/trunk/revision/110113

Thanks for the quick fix for that part.  Confirmed OK.

bug#8789: 23.3; debug backtrace buffer changes window on step-through

[martin rudalics]

 > emacs -Q
 >
 > M-x load-file MARTIN-debug.elc
 >
 > ;; That's debug.el, with your patch.
 > ;; If I load the .el instead of the .elc, then the debugger is
 > ;; called even for implement-debugger etc. - a mess.
 >
 > M-x load-library files.el
 >
 > M-x debug-on-entry file-remote-p
 >
 > That puts me immediately into the debugger, with a call to `file-remote-p'.  Why
 > does debugging file-remote-p cause the debugger to enter even for that M-x
 > invocation?  There is not even any reading of a file name.
 >
 > Thereafter, I cannot exit the debugger, no matter what I do.  `c' and `q' seem
 > to do nothing.  `d' just steps into `file-remote-p'.  Even `C-]' does not exit
 > the debugger.  I can use C-x k to kill the *Backtrace* buffer, but that leaves
 > Emacs in a recursive edit, and `C-]' then brings Emacs back into the debugger.
 > After the `C-x k', *Messages* shows this multiple times, always ending by
 > entering:
 >
 > Entering debugger...
 > Quit
 > Entering debugger...
 > Quit
 > Entering debugger...
 > Quit
 > Entering debugger...
 > Quit
 > Entering debugger...
 >
 > This really seems to be a mess.  For me, the debugger is not usable now, even
 > with emacs -Q.

Suppose I do

(progn
   (load-library "files.el")
   (debug-on-entry 'file-remote-p))

then I can observe the same behavior as you, more or less.

Emacs 23 reacts in precisely the same manner here.  Emacs 22 doesn't.
So this is something that must have changed in between these two
versions.  I don't have the slightest idea what may have caused this and
whether this qualifies as an error.

martin

bug#8789: 23.3; debug backtrace buffer changes window on step-through

[Michael Heerdegen]

martin rudalics <rudalics@gmx.at> writes:

> Suppose I do
>
> (progn
>   (load-library "files.el")
>   (debug-on-entry 'file-remote-p))
>
> then I can observe the same behavior as you, more or less.
>
> Emacs 23 reacts in precisely the same manner here.  Emacs 22 doesn't.
> So this is something that must have changed in between these two
> versions.  I don't have the slightest idea what may have caused this and
> whether this qualifies as an error.

It's caused by the calculation of the mode-line.  Try this:

  (setq-default mode-line-remote nil)

and the problem is gone.


Michael.

bug#8789: 23.3; debug backtrace buffer changes window on step-through

[martin rudalics]

 >> Emacs 23 reacts in precisely the same manner here.  Emacs 22 doesn't.
 >> So this is something that must have changed in between these two
 >> versions.  I don't have the slightest idea what may have caused this and
 >> whether this qualifies as an error.
 >
 > It's caused by the calculation of the mode-line.  Try this:
 >
 >   (setq-default mode-line-remote nil)
 >
 > and the problem is gone.

Good catch ;-)

So the solution is probably to never enable `debug-on-entry' for
functions that run through the mode-line mechanism.

martin

bug#8789: 23.3; debug backtrace buffer changes window on step-through

[Drew Adams]

>  > It's caused by the calculation of the mode-line.  Try this:
>  >   (setq-default mode-line-remote nil)
>  > and the problem is gone.
> 
> So the solution is probably to never enable `debug-on-entry' for
> functions that run through the mode-line mechanism.

That does not sound like the solution to me.  That sounds like giving up on
using the debugger.  What does "run through the mode-line mechanism" even mean,
and how does a user tell whether a given function might "run through..."?  And
for such functions (whatever that might mean), what workaround do you propose,
to get the effect of `debug-on-entry'.

This is a regression, and should just be fixed.  Users should not have to work
around it or jump over it - that is not "the solution".

`mode-line-remote' was introduced in Emacs 23.  If it is that introduction that
introduced this regression then that change needs to be fixed somehow, or
reverted.

bug#8789: 23.3; debug backtrace buffer changes window on step-through

[Eli Zaretskii]

> From: "Drew Adams" <drew.adams@oracle.com>
> Date: Thu, 20 Sep 2012 11:08:26 -0700
> Cc: 8789@debbugs.gnu.org
> 
> >  > It's caused by the calculation of the mode-line.  Try this:
> >  >   (setq-default mode-line-remote nil)
> >  > and the problem is gone.
> > 
> > So the solution is probably to never enable `debug-on-entry' for
> > functions that run through the mode-line mechanism.
> 
> That does not sound like the solution to me.

Please suggest another solution, then, for a function that is
constantly called as part of redisplay (which is what happens here,
see below).  AFAIU, this is why you "cannot exit the debugger":
anything that you do redisplays the mode line, and re-enters the
debugger.

> What does "run through the mode-line mechanism" even mean,

It means functions that are called when some Lisp form is evaluated as
part of displaying the mode line.

> and how does a user tell whether a given function might "run through..."? 

By examining the C-level call stack, I presume.

> And
> for such functions (whatever that might mean), what workaround do you propose,
> to get the effect of `debug-on-entry'.

Why do you need a work-around?  The feature works, it just has nasty
side-effects due to the fact that the function is constantly called.

> This is a regression, and should just be fixed.

How do you "fix"  situation where a function you want to debug is
called at a very high frequency?  The only way I know if is to stop
calling it -- which is precisely what was suggested: set
mode-line-remote to nil, which avoids the invocation of file-remote-p
as part of mode-line redisplay.

>  > M-x debug-on-entry file-remote-p
>  >
>  > That puts me immediately into the debugger, with a call to `file-remote-p'.  Why
>  > does debugging file-remote-p cause the debugger to enter even for that M-x
>  > invocation?

Typing "M-x" causes redisplay of certain parts of the Emacs frame,
including the mode line.  And redisplaying the mode line calls
file-remote-p because of mode-line-remote, which puts an indication of
a file being remote on the mode line.

>  > There is not even any reading of a file name.

The file name in question is buffer-file-name.

>  > Thereafter, I cannot exit the debugger, no matter what I do.  `c' and `q' seem
>  > to do nothing.  `d' just steps into `file-remote-p'.  Even `C-]' does not exit
>  > the debugger.  I can use C-x k to kill the *Backtrace* buffer, but that leaves
>  > Emacs in a recursive edit, and `C-]' then brings Emacs back into the 

You just re-enter the debugger again and again, and the indication is:

>  > After the `C-x k', *Messages* shows this multiple times, always ending by
>  > entering:
>  >
>  > Entering debugger...
>  > Quit
>  > Entering debugger...
>  > Quit
>  > Entering debugger...
>  > Quit
>  > Entering debugger...
>  > Quit
>  > Entering debugger...

bug#8789: 23.3; debug backtrace buffer changes window on step-through

[Drew Adams]

> > > So the solution is probably to never enable `debug-on-entry' for
> > > functions that run through the mode-line mechanism.
> > 
> > That does not sound like the solution to me.
> 
> Please suggest another solution, then, for a function that is
> constantly called as part of redisplay (which is what happens here,
> see below).  AFAIU, this is why you "cannot exit the debugger":
> anything that you do redisplays the mode line, and re-enters the
> debugger.

Gee, Eli, I don't know what the solution is.  Except maybe to revert the change
that caused the regression.

Or maybe the debugger should skip over such mode-line refreshing?  I really
don't know, sorry.

I do know that there is all kinds of code, including user code, that calls
`file-remote-p' - if nothing else, to avoid tramp digging in its heels and
trying to access remote machines.  If we cannot debug such code without first
manually fiddling with the mode-line spec, then that's a sorry situation, IMHO.

What users will even be aware that they will need to fiddle with such a
workaround?  A user stepping through code that happens to call `file-remote-p'
at some point will be quite surprised, and will typically have no clue what to
do at that point.

> > What does "run through the mode-line mechanism" even mean,
> 
> It means functions that are called when some Lisp form is evaluated as
> part of displaying the mode line.

I would say that it is indeed unfortunate if we are now calling `file-remote-p'
as part of displaying the mode line.  Sure, individual users can remove that.
And sure, having an indication in the mode line of whether or not something is
remote is nice.  But if this is the price then I'd say we should find some other
solution - i.e., some other way to add that feature.

If nothing else, it might be enough to duplicate the code for `file-remote-p' as
`mode-line-file-remote-p', and use only the latter for mode-line update.  That
should reduce interference with most Elisp code.

I don't claim that is the best way to handle this.  My point is that we should
not have mode-line updating invoke `file-remote-p', if that means that breaking
debugging, so that the debugger barfs and rebarfs whenever it invokes
`file-remote-p'.

> > and how does a user tell whether a given function might 
> "run through..."? 
> 
> By examining the C-level call stack, I presume.

Wunderbar.  Lisp debugger users now need to dig deeper into the bowels of Emacs.

> > And for such functions (whatever that might mean), what 
> > workaround do you propose, to get the effect of `debug-on-entry'.
> 
> Why do you need a work-around?  The feature works, it just has nasty
> side-effects due to the fact that the function is constantly called.

IOW, it works but it just doesn't work, in practice.

> > This is a regression, and should just be fixed.
> 
> How do you "fix"  situation where a function you want to debug is
> called at a very high frequency?

It should not be called for mode-line display.  IMHO.  That was a misguided
enhancement.

> The only way I know if is to stop
> calling it -- which is precisely what was suggested: set
> mode-line-remote to nil, which avoids the invocation of file-remote-p
> as part of mode-line redisplay.

Not as an individual user - that's just Emacs Dev punting.  Perhaps the debugger
could do that automatically.  Whether it should or not, and whether that should
be a user option, I also don't know.  But we should not expect users to dig in
and discover this stuff and work around it on an individual basis.

bug#8789: 23.3; debug backtrace buffer changes window on step-through

[Eli Zaretskii]

> From: "Drew Adams" <drew.adams@oracle.com>
> Cc: <rudalics@gmx.at>, <michael_heerdegen@web.de>, <8789@debbugs.gnu.org>
> Date: Thu, 20 Sep 2012 11:49:43 -0700
> 
> > > > So the solution is probably to never enable `debug-on-entry' for
> > > > functions that run through the mode-line mechanism.
> > > 
> > > That does not sound like the solution to me.
> > 
> > Please suggest another solution, then, for a function that is
> > constantly called as part of redisplay (which is what happens here,
> > see below).  AFAIU, this is why you "cannot exit the debugger":
> > anything that you do redisplays the mode line, and re-enters the
> > debugger.
> 
> Gee, Eli, I don't know what the solution is.  Except maybe to revert the change
> that caused the regression.
> 
> Or maybe the debugger should skip over such mode-line refreshing?  I really
> don't know, sorry.

Well, ideas are certainly welcome.  It's a hard problem, given the
potentially conflicting goals.  I don't think removing the feature
will be welcome.

One such solution already exists: set inhibit-eval-during-redisplay to
a non-nil value (it will inhibit _all_ calls to Lisp by all display
features, though).  I'm not sure how visible is that feature.  Perhaps
we need to advertise it more.

> I do know that there is all kinds of code, including user code, that calls
> `file-remote-p' - if nothing else, to avoid tramp digging in its heels and
> trying to access remote machines.  If we cannot debug such code without first
> manually fiddling with the mode-line spec, then that's a sorry situation, IMHO.

This is a potential problem with any code, C or Lisp, that runs during
each redisplay cycle.  On the C level, the only sane way of dealing
with this is to use conditional breakpoints with cleverly designed
conditions that cause the breakpoints break only when the function
being debugged is called in the right context, bypassing the myriads
of irrelevant calls.

> I would say that it is indeed unfortunate if we are now calling `file-remote-p'
> as part of displaying the mode line.

Surely, there's nothing special in 'file-remote-p', except the fact
that you needed to debug it in this case.  Any code that is eval'ed as
part of displaying the mode line, or redisplay in general, will be
susceptible to similar problems.  A solution specific to a single
function won't do, would it?

> > > This is a regression, and should just be fixed.
> > 
> > How do you "fix"  situation where a function you want to debug is
> > called at a very high frequency?
> 
> It should not be called for mode-line display.  IMHO.  That was a misguided
> enhancement.

I disagree.  That indication is important when you work with remote
files a lot.  And again, this particular function is not the issue;
the issue is more general.

> > The only way I know if is to stop
> > calling it -- which is precisely what was suggested: set
> > mode-line-remote to nil, which avoids the invocation of file-remote-p
> > as part of mode-line redisplay.
> 
> Not as an individual user - that's just Emacs Dev punting.

When you debug, you _are_ a developer.

> Perhaps the debugger could do that automatically.

Not unconditionally, because it is perfectly valid to debug code that
runs off redisplay.

> Whether it should or not, and whether that should be a user option,
> I also don't know.  But we should not expect users to dig in and
> discover this stuff and work around it on an individual basis.

Even if we have an option (please see if inhibit-eval-during-redisplay
suits your needs), using it already requires to know or suspect that
calls from redisplay are the reason for "strange" behavior during
debugging.  So I'm not sure I see how any such option will solve the
problem of discoverability; again, ideas welcome.

bug#8789: 23.3; debug backtrace buffer changes window on step-through

[Drew Adams]

> One such solution already exists: set inhibit-eval-during-redisplay to
> a non-nil value (it will inhibit _all_ calls to Lisp by all display
> features, though).  I'm not sure how visible is that feature.  Perhaps
> we need to advertise it more.

More than what? ;-)  I never heard of it.  And it does not appear to be
documented in the Elisp manual.

But how about an option that does that only for eval when the debugger is
active?  IOW, that sounds like something that is a broader brush than what is
needed here.

> This is a potential problem with any code, C or Lisp, that runs during
> each redisplay cycle.  On the C level, the only sane way of dealing
> with this is to use conditional breakpoints with cleverly designed
> conditions that cause the breakpoints break only when the function
> being debugged is called in the right context, bypassing the myriads
> of irrelevant calls.
> 
> > I would say that it is indeed unfortunate if we are now 
> > calling `file-remote-p' as part of displaying the mode line.
> 
> Surely, there's nothing special in 'file-remote-p', except the fact
> that you needed to debug it in this case.

No, of course there is nothing special about it.  The point is that it is a
commonly called function, and now it is also called to display the mode line.
That is a powder-keg combination.  That is the problem.  It is asking for
trouble to call such a function as part of the mode-line display.

> Any code that is eval'ed as
> part of displaying the mode line, or redisplay in general, will be
> susceptible to similar problems.

Precisely.

> A solution specific to a single function won't do, would it?

It would do for this particular bug. ;-)  But yes, the same principle and
potential problem applies to all functions called during display of the mode
line (or other redisplay stuff).

> > > > This is a regression, and should just be fixed.
> > > 
> > > How do you "fix"  situation where a function you want to debug is
> > > called at a very high frequency?
> > 
> > It should not be called for mode-line display.  IMHO.  That 
> > was a misguided enhancement.
> 
> I disagree.  That indication is important when you work with remote
> files a lot.

No one said it was not useful.  In fact, I explicitly said it was.

> And again, this particular function is not the issue;
> the issue is more general.

Yes and no.  Agreed that there is a general problem.  But let's not let the
perfect become the enemy of the good.

This particular regression was introduced because `file-remote-p' is now called
to update the mode line.  Take care of that bug and you take care of that bug
;-), which is already a good thing.

> > Perhaps the debugger could do that automatically.
> 
> Not unconditionally, because it is perfectly valid to debug code that
> runs off redisplay.

Agreed.  That's why I mentioned doing so optionally (and probably by default, to
lessen surprise).

> > Whether it should or not, and whether that should be a user option,
> > I also don't know.  But we should not expect users to dig in and
> > discover this stuff and work around it on an individual basis.
> 
> Even if we have an option (please see if inhibit-eval-during-redisplay
> suits your needs), using it already requires to know or suspect that
> calls from redisplay are the reason for "strange" behavior during
> debugging.  So I'm not sure I see how any such option will solve the
> problem of discoverability; again, ideas welcome.

Make it not only optional, but the default behavior for the debugger.  No, I do
not mean `inhibit-eval-during-redisplay', which paints with a broader brush.  I
mean an option to have the debugger skip over/through calls involving redisplay.

But you ignored the simple solution I proposed: just make the mode-line code
call a separate function from `file-remote-p'.  That function can do the same
thing, and it could even have exactly the same definition.  But it would be
called out as being something that is intended to be called only by the
mode-line code.  IOW, try to keep this separate and make that intention
explicit.

It seems to me that that would go a long way - maybe all the way - to preventing
typical debugging from falling down the hole that this discussion is about. 

bug#8789: 23.3; debug backtrace buffer changes window on step-through

[Stefan Monnier]

> But how about an option that does that only for eval when the debugger is
> active?  IOW, that sounds like something that is a broader brush than what is
> needed here.

There are 2 different situations:
1- calling the debugger while it's already active.  This can easily be
   avoided by checking inhibit-debugger.  `debug-on-error' already does that,
   and it would probably make sense to make debug-on-entry do it as well.
2- calling the debugger from a function that's called all the time.
   I think in the file-remote-p case, we'll hit this one, which means that
   every time you exit the debugger you'll get right back into it.
   Emacs is not rendered unusable, but if you're trying to debug an
   unrelated call to that function, you're out of luck.

Number 2 can be solved by making the breakpoint conditional on some
predicate which might check the backtrace to determine the context of
the call.


        Stefan

bug#8789: 23.3; debug backtrace buffer changes window on step-through

[Michael Heerdegen]

Eli Zaretskii <eliz@gnu.org> writes:

> > > So the solution is probably to never enable `debug-on-entry' for
> > > functions that run through the mode-line mechanism.
> > 
> > That does not sound like the solution to me.

I don't see this as critical as Drew, IMHO this is not really a bug.  It
is consistent behavior, and sometimes it can useful to be able to enter
the debugger from code run by redisplaying.

But OTOH, invoking the debugger in such situations can (a) be
surprising, and even a experienced user may take some time to see what's
happening.  And, b), it is not what you want most of the time.

So, what would be cool is a user-option for that behavior.  The default
could be to not invoke the debugger from redisplay code.

A question would be how to handle similar stuff, like menu calculation,
things in pre|post-command-hook, code run by timers, etc.  I mean all
the stuff that is not run directly while processing a user command.

If such an option could easily be implemented, that would be fine.  But
if it would be too much work, I also could live without it.  I can use
`debug' to invoke the debugger directly, which prevents such surprises.


Michael.

bug#8789: 23.3; debug backtrace buffer changes window on step-through

[Drew Adams]

> I can use `debug' to invoke the debugger directly, which
> prevents such surprises.

1. Not if you put `debug' in `file-remote-p'.  Or in some function that then
calls `file-remote-p.  Or then calls some function that calls `file-remote-p'...

This is not about `debug-on-entry', AFAICT.  It is about the debugger debugging
anything that might call `file-remote-p'.

2. You are right to have underlined the fact that there are other, similar areas
that can be problematic for the debugger.  A user option that lets you list such
areas for the debugger to skip over could be useful.  IOW, mode line and other
redisplay would constitute one or more such optional list items.

3. But I also think that it should be enough, for this problematic mode line
enhancement, to simply call a duplicate of `file-remote-p' and not
`file-remote-p' itself, which is used by all kinds of code.

If that duplicate (e.g., `mode-line-file-remote-p') is called only by the
mode-line code then that should greatly reduce, if not eliminate, this problem
for the debugger.

bug#8789: 23.3; debug backtrace buffer changes window on step-through

[Eli Zaretskii]

> From: "Drew Adams" <drew.adams@oracle.com>
> Date: Thu, 20 Sep 2012 13:34:07 -0700
> 
> 3. But I also think that it should be enough, for this problematic mode line
> enhancement, to simply call a duplicate of `file-remote-p' and not
> `file-remote-p' itself, which is used by all kinds of code.
> 
> If that duplicate (e.g., `mode-line-file-remote-p') is called only by the
> mode-line code then that should greatly reduce, if not eliminate, this problem
> for the debugger.

This has 2 problems, at least:

 . what if I need to debug mode-line-file-remote-p?

 . what about calling Lisp from display features other than the mode
   line, such as tool-bar buttons and menu items?

In general, I think this is a slippery slope: before long we will be
duplicating many important functions, and we will have to enforce some
kind of coding standards whereby redisplay features cannot call
"ordinary" functions.  I think this is absurd.

bug#8789: 23.3; debug backtrace buffer changes window on step-through

[Drew Adams]

> > 3. But I also think that it should be enough, for this 
> > problematic mode line enhancement, to simply call a
> > duplicate of `file-remote-p' and not `file-remote-p'
> > itself, which is used by all kinds of code.
> > 
> > If that duplicate (e.g., `mode-line-file-remote-p') is 
> > called only by the mode-line code then that should
> > greatly reduce, if not eliminate, this problem
> > for the debugger.
> 
> This has 2 problems, at least:
> 
>  . what if I need to debug mode-line-file-remote-p?

Just do it.  With the same problems you encounter today - no more and no less.

The point is that the number of people who would, today, fall upon this
`file-remote-p' sword accidentally _far_ outnumbers the people who will need to
debug `mode-line-remote-p'.  And those in the latter group will be likely to do
so with cognizance of cause.  Not so those in the first group.

That's the (should-be-obvious) point: `file-remote-p' is called all over the
place, by code that has nothing at all to do with the mode line or redisplay.
`mode-line-file-remote-p' would have as its raison d'etre to be called only by
mode-line code.

>  . what about calling Lisp from display features other than the mode
>    line, such as tool-bar buttons and menu items?

Hey, I have nothing against your coming up with an elegant, general solution.
But while waiting, why not solve the problem at hand?  If you later manage to
square the circle, then you can rename `mode-line-file-remote-p' back to
`file-remote-p'.  Easy.

> In general, I think this is a slippery slope: before long we will be
> duplicating many important functions, and we will have to enforce some
> kind of coding standards whereby redisplay features cannot call
> "ordinary" functions.  I think this is absurd.

You are exaggerating.

If you have a better, immediate solution, please go for it.  Or if you want to
revert the change that caused the regression, go for it.

But if you just want to wave your hands wildly about this not being the only
problem, then I say, again, let's not let the perfect become the enemy of the
good.

In sum, I do not claim that my suggestion is the only or the best possible
solution.  Better ideas are welcome.  But let's not avoid solving the problem
just because there are potentially other, similar problems.

bug#8789: 23.3; debug backtrace buffer changes window on step-through

[Michael Heerdegen]

"Drew Adams" <drew.adams@oracle.com> writes:

> > I can use `debug' to invoke the debugger directly, which
> > prevents such surprises.
>
> 1. Not if you put `debug' in `file-remote-p'.  Or in some function
> that then calls `file-remote-p.  Or then calls some function that
> calls file-remote-p'...

I agree that this is problematic.

> 3. But I also think that it should be enough, for this problematic
> mode line enhancement, to simply call a duplicate of `file-remote-p'
> and not `file-remote-p' itself, which is used by all kinds of code.
>
> If that duplicate (e.g., `mode-line-file-remote-p') is called only by
> the mode-line code then that should greatly reduce, if not eliminate,
> this problem for the debugger.

But do you really think that this is the right approach?  E.g. in
dired+, we use (:eval ...) in the dired mode-string.  It's not very
useful to create a duplicate of all lisp functions we call in this form
only because of the fact that they are used for the mode-line.

And, in the case of `file-remote-p', it wouldn't even be enough to
duplicate just this function.  We would have to duplicate any function that
could be called by `file-remote-p' as well.


Michael.

bug#8789: 23.3; debug backtrace buffer changes window on step-through

[Drew Adams]

> > 3. But I also think that it should be enough, for this problematic
> > mode line enhancement, to simply call a duplicate of `file-remote-p'
> > and not `file-remote-p' itself, which is used by all kinds of code.
> >
> > If that duplicate (e.g., `mode-line-file-remote-p') is 
> > called only by the mode-line code then that should greatly reduce,
> > if not eliminate, this problem for the debugger.
> 
> But do you really think that this is the right approach?  E.g. in
> dired+, we use (:eval ...) in the dired mode-string.  It's not very
> useful to create a duplicate of all lisp functions we call in 
> this form only because of the fact that they are used for the mode-line.

Again, if you have an elegant, general solution, I'm all ears.

We are confronted with a particular regression, caused by the new occurrence of
calling `file-remote-p' when updating the mode line.  Why not fix that?

> And, in the case of `file-remote-p', it wouldn't even be enough to
> duplicate just this function.  We would have to duplicate any 
> function that could be called by `file-remote-p' as well.

No, sorry, I don't see that.  The problem is only calls to `file-remote-p', not
also calls to `find-file-name-handler' (which is called by `file-remote-p') or
calls to `if' or `funcall' (also called by `file-remote-p').  

AFAICT, it does not matter that `mode-line-file-remote-p' would call
`find-file-name-handler' or `if' or `funcall'.  `M-x debug-on-entry
file-remote-p', or adding `debug' to your (non mode-line) code that calls
`file-remote-p', would not cause the debugger to open when
`mode-line-file-remote-p' is called or when any of the functions it calls is
called.

But perhaps I'm missing something?

bug#8789: 23.3; debug backtrace buffer changes window on step-through

[Michael Heerdegen]

"Drew Adams" <drew.adams@oracle.com> writes:

> > And, in the case of `file-remote-p', it wouldn't even be enough to
> > duplicate just this function.  We would have to duplicate any 
> > function that could be called by `file-remote-p' as well.
>
> No, sorry, I don't see that.  The problem is only calls to
> file-remote-p', not
> also calls to `find-file-name-handler' (which is called by
> file-remote-p') or
> calls to `if' or `funcall' (also called by `file-remote-p').  
>
> AFAICT, it does not matter that `mode-line-file-remote-p' would call
> `find-file-name-handler' or `if' or `funcall'.  `M-x debug-on-entry
> file-remote-p', or adding `debug' to your (non mode-line) code that
> calls `file-remote-p', would not cause the debugger to open when
> `mode-line-file-remote-p' is called or when any of the functions it
> calls is called.

But what if you want to M-x debug-on-entry find-file-name-handler or any
other function called by `file-remote-p' (or your mode-line version)?

Going to bed now - good night.

bug#8789: 23.3; debug backtrace buffer changes window on step-through

[Drew Adams]

> But what if you want to M-x debug-on-entry 
> find-file-name-handler or any other function called by
> `file-remote-p' (or your mode-line version)?

Yes of course, agreed.  If you explicitly access the debugger intentionally for
`find-file-name-handler', `if', or `funcall' (the 3 fns called by
`file-remote-p'), then you will run into the same problem.

The proposed fix would nevertheless be a big improvement.  And you will not run
into such a problem if you debug other code that calls any of those three fns or
`file-remote-p'.  That was my point.

I think you are perhaps exaggerating the problems, _in practice_, that such a
simple fix might not handle, and you are perhaps downplaying the real problem
already caused by the regression.

IOW, while Someone (TM) works on an elegant, general fix, implementing a simple
fix that does a pretty good job now is better than doing nothing now and until
that general fix is available.

bug#8789: 23.3; debug backtrace buffer changes window on step-through

[Drew Adams]

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

bug#8789: 23.3; debug backtrace buffer changes window on step-through

[martin rudalics]

 > I now checked in a fix for this in revision 109937 on trunk.

Bug closed.  For related problems that emerged in the discussion
please submit a new bug report.

martin

bug#8789: 23.3; debug backtrace buffer changes window on step-through

[Drew Adams]

>  > I now checked in a fix for this in revision 109937 on trunk.
> 
> Bug closed.  For related problems that emerged in the discussion
> please submit a new bug report.

Confirming that the original bug seems fixed.

Thanks for making *Backtrace* once again usable with my separate-frame setup.
It's now (finally!) back to working just as well as it did for Emacs 20-22.  And
that's saying something.  The frame stays where I put it: same size and
location.  And the frame is not deleted and re-created at each `d' or `c' I hit.
Dunno what your fix was, but thank you.

[FWIW, I do get crashes sometimes in the debugger now (e.g. using C-g or C-]),
but I expect that is unrelated.  I have been getting lots of crashes with recent
dev versions.  I cannot submit a helpful gdb backtrace according to Eli, so
we'll just have to see if someone else reports such crashes.]

bug#8789: 23.3; debug backtrace buffer changes window on step-through

[martin rudalics]

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

 >  > The general approach sounds good, but we should probably try to refine
 >  > it so as to minimize changes in behavior, and so it works right in the
 >  > multi-frame and even multi-terminal case.
 >  >
 >  > We could try to store the last-used-window in a variable
 >  > `debugger-last-used-window' and use that window after checking that it's
 >  > still live and is visible in the selected terminal.

OK.  Attached find my last ;-) stab at this.

martin

[-- Attachment #2: debug.el.diff --]
[-- Type: text/plain, Size: 1785 bytes --]

=== modified file 'lisp/emacs-lisp/debug.el'
--- lisp/emacs-lisp/debug.el	2012-01-19 07:21:25 +0000
+++ lisp/emacs-lisp/debug.el	2012-03-11 18:00:23 +0000
@@ -108,6 +108,25 @@
 - exit: called because of exit of a flagged function.
 - error: called because of `debug-on-error'.")
 
+(defvar debugger-buffer-last-window nil
+  "If non-nil, the last window displaying `debugger-buffer'")
+
+;; An appropriate substitute for this should be implemented in
+;; window.el.
+(defun debugger-buffer-use-last-window (buffer alist)
+  "Try displaying debugger buffer in last window where it was seen."
+  ;; Reuse only a window on the selected frame, excluding the selected
+  ;; and dedicated windows.
+  (when (and (window-live-p debugger-buffer-last-window)
+	     (not (eq debugger-buffer-last-window (selected-window)))
+	     (not (window-dedicated-p debugger-buffer-last-window))
+	     (eq (window-frame debugger-buffer-last-window)
+		 (selected-frame)))
+    (display-buffer-record-window
+     'reuse debugger-buffer-last-window buffer)
+    (window--display-buffer-2
+     buffer debugger-buffer-last-window display-buffer-mark-dedicated)))
+
 ;;;###autoload
 (setq debugger 'debug)
 ;;;###autoload
@@ -194,7 +213,15 @@
 		  ;; Place an extra debug-on-exit for macro's.
 		  (when (eq 'lambda (car-safe (cadr (backtrace-frame 4))))
 		    (backtrace-debug 5 t)))
-                (pop-to-buffer debugger-buffer)
+
+                (pop-to-buffer
+		 debugger-buffer
+		 '((display-buffer-reuse-window
+		    ;; Try reusing the last window where debugger-buffer
+		    ;; was seen (Bug#8789).
+		    debugger-buffer-use-last-window) . nil))
+		(setq debugger-buffer-last-window (selected-window))
+
 		(debugger-mode)
 		(debugger-setup-buffer debugger-args)
 		(when noninteractive

bug#8789: 23.3; debug backtrace buffer changes window on step-through

[martin rudalics]

 > It should IMHO be sufficient to add to the
 >
 >   (pop-to-buffer debugger-buffer)
 >
 > call in `debug' an action argument that ensures that always the same
 > window is chosen, by an deterministic algorithm.  For example:
 >
 >   (pop-to-buffer debugger-buffer
 >      '((lambda (buffer _)
 >          (let ((first-win (frame-first-window)))
 >            (select-window first-win)
 >            (switch-to-buffer buffer)
 >            first-win))))
 >
 > would always choose the first window for *Backtrace*.

Have you tried adding an according rule to `display-buffer-alist'?

martin

bug#8789: 23.3; debug backtrace buffer changes window on step-through

[Michael Heerdegen]

martin rudalics <rudalics@gmx.at> writes:

> >   (pop-to-buffer debugger-buffer
> >      '((lambda (buffer _)
> >          (let ((first-win (frame-first-window)))
> >            (select-window first-win)
> >            (switch-to-buffer buffer)
> >            first-win))))
> >
> > would always choose the first window for *Backtrace*.
>
> Have you tried adding an according rule to `display-buffer-alist'?

Yes, that also works for me.


Michael.