GNU bug report logs - #8789
23.3; debug backtrace buffer changes window on step-through

Previous Next

Full log

Message #50 received at 8789 <at> debbugs.gnu.org (full text, mbox):

From: martin rudalics <rudalics <at> gmx.at>
To: michael_heerdegen <at> web.de
Cc: 8789 <at> debbugs.gnu.org
Subject: Re: bug#8789: 23.3;
	debug backtrace buffer changes window on step-through
Date: Fri, 17 Feb 2012 10:58:34 +0100

> 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

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.