GNU bug report logs -
#13154
24.3.50; emacs_backtrace.txt (different one)
Previous Next
Full log
Message #20 received at 13154 <at> debbugs.gnu.org (full text, mbox):
> Date: Thu, 13 Dec 2012 11:29:34 +0100
> From: martin rudalics <rudalics <at> gmx.at>
> CC: Drew Adams <drew.adams <at> oracle.com>, 13154 <at> 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.
This bug report was last modified 11 years and 108 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.