bug#13154: 24.3.50; emacs_backtrace.txt (different one)

bug#13154: 24.3.50; emacs_backtrace.txt (different one)

[Drew Adams]

This backtrace is different from the others I reported today.
Also, with this one I did not get a double fatal-error dialog box.

And I did get the Windows dialog box asking me if I wanted to report the problem
to Microsoft.

HTH.
 
Backtrace:
0x01154B7D
0x01154BEF
0x010E4B0C
0x01015BC6
0x0101505F
0x010E19C3
0x01015BC6
0x0101505F
0x010E19C3
0x01015BC6
0x0101505F
0x01014401
0x01071391
0x010717DD
0x01014CAC
0x010E19C3
0x01015BC6
0x0101505F
0x010E19C3
0x01015BC6
0x010153A0
0x01013375
0x0100F0C2
0x0101030B
0x01012ADC
0x0100F0C2
0x01015A91
0x01015131
0x010E19C3
0x01015BC6
0x0101505F
0x010143CD
0x011C6214
0x011C6730
0x011CFE3A
0x0101678A
0x010E24C8
0x01015BC6
0x0101505F
0x010E19C3
0x01015BC6
0x0101505F
0x01013E8B
0x010142C2
0x01013ED0
0x011C7556
0x010E26E1
0x01015BC6
0x0101505F
0x010E19C3
0x01015BC6
0x0101505F
0x010E19C3
0x01015BC6
0x0101505F
0x01012D6D
0x01010BB9
0x010E2600
0x01015BC6
0x0101505F
0x01014378
0x010E5725
...
 
 
 
In GNU Emacs 24.3.50.1 (i386-mingw-nt5.1.2600)
 of 2012-12-07 on MS-W7-DANI
Bzr revision: 111150 eggert@cs.ucla.edu-20121207175317-wxhrqxpp0173whq0
Windowing system distributor `Microsoft Corp.', version 5.1.2600
Configured using:
 `configure --with-gcc (4.7) --no-opt --enable-checking --cflags
 -Ic:/emacs/libs/libXpm-3.5.10/include -Ic:/emacs/libs/libXpm-3.5.10/src
 -Ic:/emacs/libs/libpng-1.2.37-lib/include -Ic:/emacs/libs/zlib-1.2.5
 -Ic:/emacs/libs/giflib-4.1.4-1-lib/include
 -Ic:/emacs/libs/jpeg-6b-4-lib/include
 -Ic:/emacs/libs/tiff-3.8.2-1-lib/include
 -Ic:/emacs/libs/libxml2-2.7.8-w32-bin/include/libxml2
 -Ic:/emacs/libs/gnutls-3.0.9-w32-bin/include
 -Ic:/emacs/libs/libiconv-1.9.2-1-lib/include'
 

bug#13154: 24.3.50; emacs_backtrace.txt (different one)

[Eli Zaretskii]

> From: "Drew Adams" <drew.adams@oracle.com>
> Date: Tue, 11 Dec 2012 21:04:29 -0800
> 
> 
> This backtrace is different from the others I reported today.
> Also, with this one I did not get a double fatal-error dialog box.

Yes, it's definitely different, see below.

> And I did get the Windows dialog box asking me if I wanted to report the problem
> to Microsoft.

I don't recommend that ;-)

> Backtrace:
> 0x01154B7D
> 0x01154BEF
> 0x010E4B0C
> 0x01015BC6
> 0x0101505F
> 0x010E19C3
> 0x01015BC6
> 0x0101505F
> 0x010E19C3
> 0x01015BC6
> 0x0101505F
> 0x01014401
> 0x01071391
> 0x010717DD
> 0x01014CAC
> 0x010E19C3
> 0x01015BC6
> 0x0101505F
> 0x010E19C3
> 0x01015BC6
> 0x010153A0
> 0x01013375
> 0x0100F0C2
> 0x0101030B
> 0x01012ADC
> 0x0100F0C2
> 0x01015A91
> 0x01015131
> 0x010E19C3
> 0x01015BC6
> 0x0101505F
> 0x010143CD
> 0x011C6214
> 0x011C6730
> 0x011CFE3A
> 0x0101678A
> 0x010E24C8
> 0x01015BC6
> 0x0101505F
> 0x010E19C3
> 0x01015BC6
> 0x0101505F
> 0x01013E8B
> 0x010142C2
> 0x01013ED0
> 0x011C7556
> 0x010E26E1
> 0x01015BC6
> 0x0101505F
> 0x010E19C3
> 0x01015BC6
> 0x0101505F
> 0x010E19C3
> 0x01015BC6
> 0x0101505F
> 0x01012D6D
> 0x01010BB9
> 0x010E2600
> 0x01015BC6
> 0x0101505F
> 0x01014378
> 0x010E5725
> ...

Translation:

  ??
  ??:0
  w32_backtrace at C:\emacs\trunk\src/w32fns.c:7722
  emacs_abort at C:\emacs\trunk\src/w32fns.c:7754
  exec_byte_code at C:\emacs\trunk\src/bytecode.c:1955
  funcall_lambda at C:\emacs\trunk\src/eval.c:2903
  Ffuncall at C:\emacs\trunk\src/eval.c:2720
  exec_byte_code at C:\emacs\trunk\src/bytecode.c:897
  funcall_lambda at C:\emacs\trunk\src/eval.c:2903
  Ffuncall at C:\emacs\trunk\src/eval.c:2720
  exec_byte_code at C:\emacs\trunk\src/bytecode.c:897
  funcall_lambda at C:\emacs\trunk\src/eval.c:2903
  Ffuncall at C:\emacs\trunk\src/eval.c:2720
  call1 at C:\emacs\trunk\src/eval.c:2465
  mapcar1 at C:\emacs\trunk\src/fns.c:2311
  Fmapcar at C:\emacs\trunk\src/fns.c:2381
  Ffuncall at C:\emacs\trunk\src/eval.c:2674
  exec_byte_code at C:\emacs\trunk\src/bytecode.c:897
  funcall_lambda at C:\emacs\trunk\src/eval.c:2903
  Ffuncall at C:\emacs\trunk\src/eval.c:2720
  exec_byte_code at C:\emacs\trunk\src/bytecode.c:897
  funcall_lambda at C:\emacs\trunk\src/eval.c:2903
  apply_lambda at C:\emacs\trunk\src/eval.c:2780
  eval_sub at C:\emacs\trunk\src/eval.c:2081
  Fprogn at C:\emacs\trunk\src/eval.c:358
  Flet at C:\emacs\trunk\src/eval.c:817
  eval_sub at C:\emacs\trunk\src/eval.c:1984
  Fprogn at C:\emacs\trunk\src/eval.c:358
  funcall_lambda at C:\emacs\trunk\src/eval.c:2896
  Ffuncall at C:\emacs\trunk\src/eval.c:2732
  exec_byte_code at C:\emacs\trunk\src/bytecode.c:897
  funcall_lambda at C:\emacs\trunk\src/eval.c:2903
  Ffuncall at C:\emacs\trunk\src/eval.c:2720
  call0 at C:\emacs\trunk\src/eval.c:2450
  run_funs at C:\emacs\trunk\src/window.c:3044
  run_window_configuration_change_hook at C:\emacs\trunk\src/window.c:3105
  Fset_window_configuration at C:\emacs\trunk\src/window.c:5867
  unbind_to at C:\emacs\trunk\src/eval.c:3094
  exec_byte_code at C:\emacs\trunk\src/bytecode.c:1063
  funcall_lambda at C:\emacs\trunk\src/eval.c:2903
  Ffuncall at C:\emacs\trunk\src/eval.c:2720
  exec_byte_code at C:\emacs\trunk\src/bytecode.c:897
  funcall_lambda at C:\emacs\trunk\src/eval.c:2903
  Ffuncall at C:\emacs\trunk\src/eval.c:2720
  funcall_nil at C:\emacs\trunk\src/eval.c:2217
  run_hook_with_args at C:\emacs\trunk\src/eval.c:2402
  Frun_hooks at C:\emacs\trunk\src/eval.c:2244
  temp_output_buffer_show at C:\emacs\trunk\src/window.c:3374
  exec_byte_code at C:\emacs\trunk\src/bytecode.c:1111
  funcall_lambda at C:\emacs\trunk\src/eval.c:2903
  Ffuncall at C:\emacs\trunk\src/eval.c:2720
  exec_byte_code at C:\emacs\trunk\src/bytecode.c:897
  funcall_lambda at C:\emacs\trunk\src/eval.c:2903
  Ffuncall at C:\emacs\trunk\src/eval.c:2720
  exec_byte_code at C:\emacs\trunk\src/bytecode.c:897
  funcall_lambda at C:\emacs\trunk\src/eval.c:2903
  Ffuncall at C:\emacs\trunk\src/eval.c:2720
  eval_sub at C:\emacs\trunk\src/eval.c:2008
  internal_lisp_condition_case at C:\emacs\trunk\src/eval.c:1146
  exec_byte_code at C:\emacs\trunk\src/bytecode.c:1093
  funcall_lambda at C:\emacs\trunk\src/eval.c:2903
  Ffuncall at C:\emacs\trunk\src/eval.c:2720
  apply1 at C:\emacs\trunk\src/eval.c:2432
  Fcall_interactively at C:\emacs\trunk\src/callint.c:377
  ??
  ??:0

It crashes here:

    /* Binds and unbinds are supposed to be compiled balanced.  */
    if (SPECPDL_INDEX () != count)
  #ifdef BYTE_CODE_SAFE
      error ("binding stack not balanced (serious byte compiler bug)");
  #else
      emacs_abort ();
  #endif

I immediately thought about this:

  http://lists.gnu.org/archive/html/emacs-devel/2012-12/msg00079.html

but Andreas fixed that in revision 111096, which was committed before
111150, used to produce Drew's binary.

So I have no idea what could have caused that, and without Lisp-level
stack it's hard to tell anything about the possible villains.  The
only noteworthy thing I see is this:

  run_window_configuration_change_hook at C:\emacs\trunk\src/window.c:3105
  Fset_window_configuration at C:\emacs\trunk\src/window.c:5867

Drew, any chance of you showing the code that was run by this hook?

bug#13154: 24.3.50; emacs_backtrace.txt (different one)

[Drew Adams]

>   run_window_configuration_change_hook at 
> C:\emacs\trunk\src/window.c:3105
>   Fset_window_configuration at C:\emacs\trunk\src/window.c:5867
> 
> Drew, any chance of you showing the code that was run by this hook?

I'm afraid not, unless you can tell me how.

AFAIK, I do not use that hook (I guess you meant, for Lisp,
`run-window-configuration-change-hook') in any of my code.  Of course, perhaps
some code that I call might use it - dunno.

At least, grepping my code and other 3rd-party code I have does not show any
hits for `run-window-configuration-change-hook'.  (Well, there were some hits
for different versions of vanilla `window.el' that I saved from mails with
Martin last June, when we were debugging some problems, but those files are not
used in any way.)

bug#13154: 24.3.50; emacs_backtrace.txt (different one)

[Eli Zaretskii]

> From: "Drew Adams" <drew.adams@oracle.com>
> Cc: <13154@debbugs.gnu.org>
> Date: Wed, 12 Dec 2012 09:06:39 -0800
> 
> >   run_window_configuration_change_hook at 
> > C:\emacs\trunk\src/window.c:3105
> >   Fset_window_configuration at C:\emacs\trunk\src/window.c:5867
> > 
> > Drew, any chance of you showing the code that was run by this hook?
> 
> I'm afraid not, unless you can tell me how.

Like you did: searching through your code.

> AFAIK, I do not use that hook (I guess you meant, for Lisp,
> `run-window-configuration-change-hook') in any of my code.  Of course, perhaps
> some code that I call might use it - dunno.

Martin, any advice or ideas?  If Drew didn't set up this hook, what
other code could do that?

bug#13154: 24.3.50; emacs_backtrace.txt (different one)

[martin rudalics]

 > Martin, any advice or ideas?  If Drew didn't set up this hook, what
 > other code could do that?

IIUC the only useful lines in the backtrace are

   run_window_configuration_change_hook at C:\emacs\trunk\src/window.c:3105
   Fset_window_configuration at C:\emacs\trunk\src/window.c:5867
   ...
   temp_output_buffer_show at C:\emacs\trunk\src/window.c:3374

so the obvious first conclusion is that moving code from C to Elisp
harms interpreting stuff like emacs_backtrace.txt ;-)

 From the backtrace I understand that Drew did show a temporary buffer
and (probably after being done with that) restored a previous window
configuration.  This could come from a `with-output-to-temp-buffer'
wrapped in a `save-window-excursion', which as we know is evil but
usually not evil enough to corrupt the stack.

`set-window-configuration' runs `window-configuration-change-hook' which
is normal.  There might be some function on the hook (like those from
linum.el) but I doubt that Drew uses that.  And I doubt that anything
done here can corrupt the stack.

martin

bug#13154: 24.3.50; emacs_backtrace.txt (different one)

[Eli Zaretskii]

> Date: Thu, 13 Dec 2012 11:29:34 +0100
> From: martin rudalics <rudalics@gmx.at>
> CC: Drew Adams <drew.adams@oracle.com>, 13154@debbugs.gnu.org
> 
> IIUC the only useful lines in the backtrace are
> 
>    run_window_configuration_change_hook at C:\emacs\trunk\src/window.c:3105
>    Fset_window_configuration at C:\emacs\trunk\src/window.c:5867
>    ...
>    temp_output_buffer_show at C:\emacs\trunk\src/window.c:3374
> 
> so the obvious first conclusion is that moving code from C to Elisp
> harms interpreting stuff like emacs_backtrace.txt ;-)
> 
>  From the backtrace I understand that Drew did show a temporary buffer
> and (probably after being done with that) restored a previous window
> configuration.  This could come from a `with-output-to-temp-buffer'
> wrapped in a `save-window-excursion', which as we know is evil but
> usually not evil enough to corrupt the stack.

Drew, does this allow to identify potential villains?  We are looking
for some code that runs inside the above 2 forms.

> `set-window-configuration' runs `window-configuration-change-hook' which
> is normal.  There might be some function on the hook (like those from
> linum.el) but I doubt that Drew uses that.  And I doubt that anything
> done here can corrupt the stack.

Corrupted stack is not the issue.  AFAIU, we are looking for some C
code which doesn't balance specbind/record_unwind_protect with the
corresponding unbind_to.  This code could be executed by some
primitive, or some C function called from some primitive, that is
invoked from Lisp.  The problem is to find that Lisp.  I hope Drew
will be able to, given the above hints.

bug#13154: 24.3.50; emacs_backtrace.txt (different one)

[Drew Adams]

> > From the backtrace I understand that Drew did show a 
> > temporary buffer and (probably after being done with that)
> > restored a previous window configuration.  This could come
> > from a `with-output-to-temp-buffer' wrapped in a
> > `save-window-excursion', which as we know is evil but
> > usually not evil enough to corrupt the stack.
> 
> Drew, does this allow to identify potential villains?  We are looking
> for some code that runs inside the above 2 forms.

I grepped my code for `with-output-to-temp-buffer' and checked each occurrence
to see if lexically within a `save-excursion'.  Took me a while.    I have lots
of calls to `with-output-to-temp-buffer'.

Of course, that is not a complete test, since some code doing a `save-excursion'
could call a function that then does `with-output-to-temp-buffer'.  I cannot
check for that - far too time-consuming.

FWIW, it's not clear to me that `w-o-t-t-b' inside `s-e' is "evil".  It might be
ineffectual in some contexts, in the sense that it might not do what some users
mistakenly might expect, but - for my own understanding - just why do you
consider it evil?

Anyway, this is all my search turned up.  Neither of these is pertinent, IMO.

* I found an occurrence in my version of `describe-function', which is based on
the vanilla Emacs 22 version in this respect.  It has to work for 22+, and 22
does not have macro `with-help-window'.  (Yes, I could duplicate the code and
have a version for Emacs 23+...)  In my own help commands (`describe-file',
`describe-keymap'), I do not use `save-excursion.

* I found one other occurrence of `with-output-to-temp-buffer' inside
`save-excursion', but that code is used only when running Emacs 22, and it is a
copy of the vanilla Emacs 22 code (for `describe-text-properties').  IOW, the
fault is with vanilla Emacs in this case, and this case cannot be manifested in
Emacs 24 anyway.

HTH (but I doubt it).

bug#13154: 24.3.50; emacs_backtrace.txt (different one)

[Eli Zaretskii]

> From: "Drew Adams" <drew.adams@oracle.com>
> Cc: <13154@debbugs.gnu.org>
> Date: Thu, 13 Dec 2012 13:16:03 -0800
> 
> FWIW, it's not clear to me that `w-o-t-t-b' inside `s-e' is "evil".  It might be
> ineffectual in some contexts, in the sense that it might not do what some users
> mistakenly might expect, but - for my own understanding - just why do you
> consider it evil?

Martin will probably tell, but in any case I don't think this is
related to the abort we are discussing.

> * I found an occurrence in my version of `describe-function', which is based on
> the vanilla Emacs 22 version in this respect.  It has to work for 22+, and 22
> does not have macro `with-help-window'.  (Yes, I could duplicate the code and
> have a version for Emacs 23+...)  In my own help commands (`describe-file',
> `describe-keymap'), I do not use `save-excursion.
> 
> * I found one other occurrence of `with-output-to-temp-buffer' inside
> `save-excursion', but that code is used only when running Emacs 22, and it is a
> copy of the vanilla Emacs 22 code (for `describe-text-properties').  IOW, the
> fault is with vanilla Emacs in this case, and this case cannot be manifested in
> Emacs 24 anyway.

We are looking for Lisp code that would show calls to some primitives,
wherein we could look for potential bugs on the C level.  Does the
body of Lisp code inside save-excursion in the first occurrence call
any primitives, or any functions at all?  If so, can you show that
body?

bug#13154: 24.3.50; emacs_backtrace.txt (different one)

[martin rudalics]

 > Corrupted stack is not the issue.  AFAIU, we are looking for some C
 > code which doesn't balance specbind/record_unwind_protect with the
 > corresponding unbind_to.

I don't see the difference.  In either case the stack is inconsistent
when popped.

 > This code could be executed by some
 > primitive, or some C function called from some primitive, that is
 > invoked from Lisp.  The problem is to find that Lisp.  I hope Drew
 > will be able to, given the above hints.

FWIW I suppose that Drew ended up with some invalid byte code from a
binary afflicted with

  http://lists.gnu.org/archive/html/emacs-devel/2012-12/msg00079.html

and didn't recompile with the later binaries (or a bug similar to the
one fixed by Andreas still persists).

martin

bug#13154: 24.3.50; emacs_backtrace.txt (different one)

[martin rudalics]

 >> FWIW, it's not clear to me that `w-o-t-t-b' inside `s-e' is "evil".  It might be
 >> ineffectual in some contexts, in the sense that it might not do what some users
 >> mistakenly might expect, but - for my own understanding - just why do you
 >> consider it evil?
 >
 > Martin will probably tell,

It's evil because `with-output-to-temp-buffer' may pop up a new frame
while `save-window-excursion' gives you the false impression that it can
cope with that situation.

 > but in any case I don't think this is
 > related to the abort we are discussing.

It should be unrelated.

 >> * I found an occurrence in my version of `describe-function', which is based on
 >> the vanilla Emacs 22 version in this respect.  It has to work for 22+, and 22
 >> does not have macro `with-help-window'.  (Yes, I could duplicate the code and
 >> have a version for Emacs 23+...)  In my own help commands (`describe-file',
 >> `describe-keymap'), I do not use `save-excursion.
 >>
 >> * I found one other occurrence of `with-output-to-temp-buffer' inside
 >> `save-excursion', but that code is used only when running Emacs 22, and it is a
 >> copy of the vanilla Emacs 22 code (for `describe-text-properties').  IOW, the
 >> fault is with vanilla Emacs in this case, and this case cannot be manifested in
 >> Emacs 24 anyway.

`save-window-excursion' and not `save-excursion', I presume.

 > We are looking for Lisp code that would show calls to some primitives,
 > wherein we could look for potential bugs on the C level.  Does the
 > body of Lisp code inside save-excursion in the first occurrence call
 > any primitives, or any functions at all?  If so, can you show that
 > body?

I still don't know whether you are sure that Drew runs some code within
`window-configuration-change-hook'.

martin

bug#13154: 24.3.50; emacs_backtrace.txt (different one)

[Drew Adams]

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

> > * I found an occurrence in my version of 
> > `describe-function', which is based on the vanilla
> > Emacs 22 version in this respect.  It has to work for 22+,
> > and 22 does not have macro `with-help-window'.
> 
> We are looking for Lisp code that would show calls to some primitives,
> wherein we could look for potential bugs on the C level.  Does the
> body of Lisp code inside save-excursion in the first occurrence call
> any primitives, or any functions at all?  If so, can you show that
> body?

The code is attached.  Clearly the body calls "any functions at all".  HTH.

[-- Attachment #2: throw-helpfns.el --]
[-- Type: application/octet-stream, Size: 2263 bytes --]

;; REPLACE ORIGINAL in `help-fns.el':
;;
;; 1. Preferred candidate is `symbol-nearest-point'.
;; 2. With a prefix argument, candidates are commands only.
;; 3. No no-function message if not called interactively.
;;
;;;###autoload
(defun describe-function (function &optional commandp)
  "Display the full documentation of FUNCTION (a symbol).
FUNCTION names an Emacs Lisp function, possibly a user command.
With a prefix argument, candidates are commands (interactive) only.
Default candidate is: preferably the `symbol-nearest-point', or else
the innermost function call surrounding point
\(`function-called-at-point').
Return the description that was displayed, as a string."
  (interactive
   (let ((fn                            (or (and (fboundp 'symbol-nearest-point)
                                                 (symbol-nearest-point))
                                            (function-called-at-point)))
         (enable-recursive-minibuffers  t)
         (completion-annotate-function  (lambda (fn)
                                          (and (commandp (intern-soft fn))  "  (command)")))
         val)
     (setq val  (completing-read (if current-prefix-arg "Describe command: " "Describe function: ")
                                 obarray (if current-prefix-arg 'commandp 'fboundp) t nil nil
                                 (and fn  (symbol-name fn))))
     (list (if (equal val "") fn (intern val)) current-prefix-arg)))
  (if (not function)
      (when (interactive-p) (message "You did not specify a function"))
    (unless (or (not commandp)  (commandp function))
      (error "Not a defined Emacs command (interactive function): `%s'" function))
    ;;$$$  (unless (fboundp function) (error "Not a defined Emacs function: `%s'" function))
    (help-setup-xref (list #'describe-function function) (interactive-p))
    (save-excursion
      (with-output-to-temp-buffer (help-buffer)
        (prin1 function)
        ;; Use " is " instead of ": " so it is easier to get the function name using `forward-sexp'.
        (princ " is ")
        (describe-function-1 function)
        (print-help-return-message)
        (with-current-buffer standard-output (buffer-string)))))) ; Return help text.

bug#13154: 24.3.50; emacs_backtrace.txt (different one)

[Drew Adams]

> FWIW I suppose that Drew ended up with some invalid byte code from a
> binary afflicted with
> 
>   http://lists.gnu.org/archive/html/emacs-devel/2012-12/msg00079.html
> 
> and didn't recompile with the later binaries (or a bug similar to the
> one fixed by Andreas still persists).

I compile the file in question using Emacs 23.4.  Dunno what that means here.

bug#13154: 24.3.50; emacs_backtrace.txt (different one)

[Drew Adams]

>  >> FWIW, it's not clear to me that `w-o-t-t-b' inside `s-e' 
>  >> is "evil".  It might be ineffectual in some contexts,
>  >> in the sense that it might not do what some users
>  >> mistakenly might expect, but - for my own understanding - 
>  >> just why do you consider it evil?
>  >
>  > Martin will probably tell,
> 
> It's evil because `with-output-to-temp-buffer' may pop up a new frame
> while `save-window-excursion' gives you the false impression 
> that it can cope with that situation.

That's exactly what I meant by "It might be ineffectual in some contexts, in the
sense that it might not do what some users mistakenly might expect."

In practice (IMHO), that is probably more of a problem/annoyance for Emacs Dev,
having to field false-bug reports from users, than it is a real problem for
users.  Just one opinion.

>  >> * I found an occurrence in my version of 
>  >> `describe-function', which is based on
>  >> the vanilla Emacs 22 version in this respect.  It has to 
>  >> work for 22+, and 22 does not have macro `with-help-window'.
>  >>
>  >> * I found one other occurrence of 
>  >> `with-output-to-temp-buffer' inside `save-excursion', but
>  >> that code is used only when running Emacs 22, and it is a
>  >> copy of the vanilla Emacs 22 code (for 
>  >> `describe-text-properties').  IOW, the fault is with
>  >> vanilla Emacs in this case, and this case cannot be
>  >> manifested in Emacs 24 anyway.
> 
> `save-window-excursion' and not `save-excursion', I presume.

No, `save-excursion'.  It is `save-excursion' that occurs in the vanilla Emacs
22 code, in both cases (vanilla `describe-function' and `describe-variable', for
Emacs 22 and prior).  Emacs was "evil" for decades...

> I still don't know whether you are sure that Drew runs some 
> code within `window-configuration-change-hook'.

Didn't know I was expected to look for that one.  Grepping for
`window-configuration-change-hook' finds the following two occurrences:

1. Inside the definition of command `dired-sort-dialogue' (from Francis Wright's
library dired-sort-menu.el).  But I did not invoke this command, AFAIK.

(add-hook 'window-configuration-change-hook
          'dired-sort-dialogue-auto-kill-2)

2. In pp-c-l.el.  I do use this one.

(add-hook 'window-configuration-change-hook
          'refresh-pretty-control-l)

(defun refresh-pretty-control-l ()
  "Reinitialize `pretty-control-l-mode', if on, to update the display."
  (interactive)
  (when pretty-control-l-mode (pretty-control-l-mode t)))

`pretty-control-l-mode' is a global minor mode that does only this:

(walk-windows 
  (lambda (window)
    (let ((display-table  (or (window-display-table window)
                              (make-display-table))))
      (aset display-table ?\014
            (and pretty-control-l-mode
                 (pp^L-^L-display-table-entry window)))
      (set-window-display-table window display-table)))
  'no-minibuf
  'visible)

HTH.

bug#13154: 24.3.50; emacs_backtrace.txt (different one)

[martin rudalics]

 > The code is attached.  Clearly the body calls "any functions at all".  HTH.

This

     (save-excursion
       (with-output-to-temp-buffer (help-buffer)

uses plain `save-excursion'.  We're looking for `save-window-excursion'.
But don't bother.  There are plenty of `save-window-excursion' calls in
the lisp directory, so it very likely comes from there.  And the
`with-output-to-temp-buffer' call might be wrapped in the call to
another function so we probably won't find it anyway.

martin

bug#13154: 24.3.50; emacs_backtrace.txt (different one)

[martin rudalics]

 > No, `save-excursion'.  It is `save-excursion' that occurs in the vanilla Emacs
 > 22 code, in both cases (vanilla `describe-function' and `describe-variable', for
 > Emacs 22 and prior).  Emacs was "evil" for decades...

... as I said in my other mail I'm looking for `save-window-excursion'.

 > 2. In pp-c-l.el.  I do use this one.
 >
 > (add-hook 'window-configuration-change-hook
 >           'refresh-pretty-control-l)
 >
 > (defun refresh-pretty-control-l ()
 >   "Reinitialize `pretty-control-l-mode', if on, to update the display."
 >   (interactive)
 >   (when pretty-control-l-mode (pretty-control-l-mode t)))
 >
 > `pretty-control-l-mode' is a global minor mode that does only this:
 >
 > (walk-windows
 >   (lambda (window)
 >     (let ((display-table  (or (window-display-table window)
 >                               (make-display-table))))
 >       (aset display-table ?\014
 >             (and pretty-control-l-mode
 >                  (pp^L-^L-display-table-entry window)))
 >       (set-window-display-table window display-table)))
 >   'no-minibuf
 >   'visible)

If this were the culprit we'd probably see the corresponding calls in
the backtrace.

martin

bug#13154: 24.3.50; emacs_backtrace.txt (different one)

[Drew Adams]

>  > No, `save-excursion'.  It is `save-excursion' that occurs 
>  > in the vanilla Emacs 22 code, in both cases (vanilla
>  > `describe-function' and `describe-variable', for
>  > Emacs 22 and prior).  Emacs was "evil" for decades...
> 
> ... as I said in my other mail I'm looking for 
> `save-window-excursion'.

No, you did not say that at all.  You said only this:

>> `save-window-excursion' and not `save-excursion', I presume.

Eli asked that I search for `save-excursion' wrapping `with...'.  I thought your
statement was saying that you presumed that I meant to write
`save-window-excursion' but mistakenly wrote `save-excursion'.

bug#13154: 24.3.50; emacs_backtrace.txt (different one)

[Drew Adams]

> But don't bother.  There are plenty of 
> `save-window-excursion' calls in
> the lisp directory, so it very likely comes from there.  And the
> `with-output-to-temp-buffer' call might be wrapped in the call to
> another function so we probably won't find it anyway.

OK.

bug#13154: 24.3.50; emacs_backtrace.txt (different one)

[martin rudalics]

 >> ... as I said in my other mail I'm looking for
 >> `save-window-excursion'.
 >
 > No, you did not say that at all.

How often do you want me to repeat it?

 > You said only this:
 >
 >>> `save-window-excursion' and not `save-excursion', I presume.

Because I assumed that you read Eli's mail before ...

 > Eli asked that I search for `save-excursion' wrapping `with...'.

... where he said:

 >>  From the backtrace I understand that Drew did show a temporary buffer
 >> and (probably after being done with that) restored a previous window
 >> configuration.  This could come from a `with-output-to-temp-buffer'
 >> wrapped in a `save-window-excursion', which as we know is evil but
 >> usually not evil enough to corrupt the stack.
 >
 > Drew, does this allow to identify potential villains?  We are looking
 > for some code that runs inside the above 2 forms.

You were apparently concentrating on the second part of my statement.
At least you understand its evilness now.

martin

bug#13154: 24.3.50; emacs_backtrace.txt (different one)

[Drew Adams]

>  >> From the backtrace I understand that Drew did show a 
>  >> temporary buffer and (probably after being done with
>  >> that) restored a previous window configuration.  This
>  >> could come from a `with-output-to-temp-buffer' wrapped
>  >> in a `save-window-excursion', which as we know is evil
>  >> but usually not evil enough to corrupt the stack.
> 
> You were apparently concentrating on the second part of my statement.
> At least you understand its evilness now.

I guess I misunderstood.  Sorry.

bug#13154: 24.3.50; emacs_backtrace.txt (different one)

[Glenn Morris]

It seems pretty unlikely that anyone is going to figure this out AFAICS.

bug#13154: 24.3.50; emacs_backtrace.txt (different one)

[Lars Ingebrigtsen]

Glenn Morris <rgm@gnu.org> writes:

> It seems pretty unlikely that anyone is going to figure this out AFAICS.

Yup.  Closing.

-- 
(domestic pets only, the antidote for overdose, milk.)
  bloggy blog http://lars.ingebrigtsen.no/