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

From: Eli Zaretskii <[email-masked]>
Date: Thu, 13 Dec 2012 19:08:32 +0200

> Date: Thu, 13 Dec 2012 11:29:34 +0100
> From: martin rudalics <[email-masked]>
> CC: Drew Adams <[email-masked]>, [email-masked]
> 
> 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.