GNU bug report logs -
#13154
24.3.50; emacs_backtrace.txt (different one)
Previous Next
To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 13154 in the body.
You can then email your comments to 13154 AT debbugs.gnu.org in the normal way.
Toggle the display of automated, internal messages from the tracker.
Report forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#13154; Package
emacs.
(Wed, 12 Dec 2012 05:06:02 GMT)
Full text and
rfc822 format available.
Acknowledgement sent
to
"Drew Adams" <drew.adams <at> oracle.com>:
New bug report received and forwarded. Copy sent to
bug-gnu-emacs <at> gnu.org.
(Wed, 12 Dec 2012 05:06:02 GMT)
Full text and
rfc822 format available.
Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):
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 <at> 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'
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#13154; Package
emacs.
(Wed, 12 Dec 2012 16:57:01 GMT)
Full text and
rfc822 format available.
Message #8 received at 13154 <at> debbugs.gnu.org (full text, mbox):
> From: "Drew Adams" <drew.adams <at> 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?
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#13154; Package
emacs.
(Wed, 12 Dec 2012 17:08:02 GMT)
Full text and
rfc822 format available.
Message #11 received at 13154 <at> debbugs.gnu.org (full text, mbox):
> 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.)
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#13154; Package
emacs.
(Wed, 12 Dec 2012 18:54:01 GMT)
Full text and
rfc822 format available.
Message #14 received at 13154 <at> debbugs.gnu.org (full text, mbox):
> From: "Drew Adams" <drew.adams <at> oracle.com>
> Cc: <13154 <at> 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?
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#13154; Package
emacs.
(Thu, 13 Dec 2012 10:31:01 GMT)
Full text and
rfc822 format available.
Message #17 received at 13154 <at> debbugs.gnu.org (full text, mbox):
> 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
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#13154; Package
emacs.
(Thu, 13 Dec 2012 17:10:02 GMT)
Full text and
rfc822 format available.
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.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#13154; Package
emacs.
(Thu, 13 Dec 2012 21:18:02 GMT)
Full text and
rfc822 format available.
Message #23 received at 13154 <at> debbugs.gnu.org (full text, mbox):
> > 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).
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#13154; Package
emacs.
(Fri, 14 Dec 2012 07:50:02 GMT)
Full text and
rfc822 format available.
Message #26 received at 13154 <at> debbugs.gnu.org (full text, mbox):
> From: "Drew Adams" <drew.adams <at> oracle.com>
> Cc: <13154 <at> 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?
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#13154; Package
emacs.
(Fri, 14 Dec 2012 10:26:03 GMT)
Full text and
rfc822 format available.
Message #29 received at 13154 <at> debbugs.gnu.org (full text, mbox):
> 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
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#13154; Package
emacs.
(Fri, 14 Dec 2012 10:28:03 GMT)
Full text and
rfc822 format available.
Message #32 received at 13154 <at> debbugs.gnu.org (full text, mbox):
>> 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
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#13154; Package
emacs.
(Fri, 14 Dec 2012 15:27:01 GMT)
Full text and
rfc822 format available.
Message #35 received at 13154 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
> > * 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.
[throw-helpfns.el (application/octet-stream, attachment)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#13154; Package
emacs.
(Fri, 14 Dec 2012 15:29:01 GMT)
Full text and
rfc822 format available.
Message #38 received at 13154 <at> debbugs.gnu.org (full text, mbox):
> 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.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#13154; Package
emacs.
(Fri, 14 Dec 2012 15:53:02 GMT)
Full text and
rfc822 format available.
Message #41 received at 13154 <at> debbugs.gnu.org (full text, mbox):
> >> 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.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#13154; Package
emacs.
(Fri, 14 Dec 2012 16:15:01 GMT)
Full text and
rfc822 format available.
Message #44 received at 13154 <at> debbugs.gnu.org (full text, mbox):
> 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
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#13154; Package
emacs.
(Fri, 14 Dec 2012 16:15:02 GMT)
Full text and
rfc822 format available.
Message #47 received at 13154 <at> debbugs.gnu.org (full text, mbox):
> 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
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#13154; Package
emacs.
(Fri, 14 Dec 2012 16:21:02 GMT)
Full text and
rfc822 format available.
Message #50 received at 13154 <at> debbugs.gnu.org (full text, mbox):
> 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.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#13154; Package
emacs.
(Fri, 14 Dec 2012 16:21:02 GMT)
Full text and
rfc822 format available.
Message #53 received at 13154 <at> debbugs.gnu.org (full text, mbox):
> > 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'.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#13154; Package
emacs.
(Fri, 14 Dec 2012 16:37:01 GMT)
Full text and
rfc822 format available.
Message #56 received at 13154 <at> debbugs.gnu.org (full text, mbox):
>> ... 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
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#13154; Package
emacs.
(Fri, 14 Dec 2012 16:48:01 GMT)
Full text and
rfc822 format available.
Message #59 received at 13154 <at> debbugs.gnu.org (full text, mbox):
> >> 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.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#13154; Package
emacs.
(Sat, 23 Feb 2013 01:15:01 GMT)
Full text and
rfc822 format available.
Message #62 received at 13154 <at> debbugs.gnu.org (full text, mbox):
It seems pretty unlikely that anyone is going to figure this out AFAICS.
Merged 13154 13980.
Request was from
Glenn Morris <rgm <at> gnu.org>
to
control <at> debbugs.gnu.org.
(Tue, 16 Apr 2013 17:42:02 GMT)
Full text and
rfc822 format available.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#13154; Package
emacs.
(Mon, 10 Feb 2014 04:39:01 GMT)
Full text and
rfc822 format available.
Message #71 received at 13154 <at> debbugs.gnu.org (full text, mbox):
Glenn Morris <rgm <at> 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/
bug closed, send any further explanations to
14298 <at> debbugs.gnu.org and "Drew Adams" <drew.adams <at> oracle.com>
Request was from
Lars Ingebrigtsen <larsi <at> gnus.org>
to
control <at> debbugs.gnu.org.
(Mon, 10 Feb 2014 04:39:03 GMT)
Full text and
rfc822 format available.
bug archived.
Request was from
Debbugs Internal Request <help-debbugs <at> gnu.org>
to
internal_control <at> debbugs.gnu.org.
(Mon, 10 Mar 2014 11:24:10 GMT)
Full text and
rfc822 format available.
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.