bug#15213: 24.3.50; emacs_backtrace.txt

bug#15213: 24.3.50; emacs_backtrace.txt

[Drew Adams]

Backtrace:
0x011e6e89
0x011e6efb
0x010d9b0c
0x0114ee2f
0x01145048
0x0107c77c
0x011ad7f9
0x0116cfc9
0x0116c65f
0x011acacd
0x0116cfc9
0x0116c65f
0x011acacd
0x0116cfc9
0x0116c65f
0x0116be85
0x011646de
0x0116c478
0x011acacd
0x0116cc05
0x0116c65f
0x0116bf0e
0x010dddbf
0x0116928c
0x010dd24e
0x01168ba6
0x010dd1b5
0x010dc9bd
0x0111529a
0x01115b18
0x0116c5b2
0x011acacd
0x0116cfc9
0x0116c65f
0x011acacd
0x0116cfc9
0x0116c65f
0x011acacd
0x011abf84
0x0116b0b3
0x01168ba6
0x011ad6aa
0x0116cfc9
0x0116c65f
0x011acacd
0x0116cfc9
0x0116c65f
0x011acacd
0x011abf84
0x0116b0b3
0x01168ba6
0x011ad6aa
0x011abf84
0x0116b0b3
0x011691c2
0x011ad759
0x0116cfc9
0x0116c65f
0x011acacd
0x0116cfc9
0x0116c65f
0x011acacd
...




In GNU Emacs 24.3.50.1 (i686-pc-mingw32)
 of 2013-08-23 on ODIEONE
Bzr revision: 113986 rgm@gnu.org-20130823185841-zoy6h1qk433ibrlf
Windowing system distributor `Microsoft Corp.', version 6.1.7601
Configured using:
 `configure --prefix=/c/Devel/emacs/binary --enable-checking=yes,glyphs
 'CFLAGS=-O0 -g3' LDFLAGS=-Lc:/Devel/emacs/lib
 CPPFLAGS=-Ic:/Devel/emacs/include'

bug#15213: 24.3.50; emacs_backtrace.txt

[Juanma Barranquero]

> Backtrace:

w32_backtrace at w32fns.c:7982
emacs_abort at w32fns.c:8014
terminate_due_to_signal at emacs.c:369
die at alloc.c:6573
XWINDOW at lisp.h:799
temp_output_buffer_show at window.c:3360
exec_byte_code at bytecode.c:1119
funcall_lambda at eval.c:3087
Ffuncall at eval.c:2902
exec_byte_code at bytecode.c:905
funcall_lambda at eval.c:3087
Ffuncall at eval.c:2902
exec_byte_code at bytecode.c:905
funcall_lambda at eval.c:3087
Ffuncall at eval.c:2902
apply1 at eval.c:2619
Fcall_interactively at callint.c:378
Ffuncall at eval.c:2860
exec_byte_code at bytecode.c:905
funcall_lambda at eval.c:3021
Ffuncall at eval.c:2902
call1 at eval.c:2652
command_loop_1 at keyboard.c:1560
internal_condition_case at eval.c:1339
command_loop_2 at keyboard.c:1161
internal_catch at eval.c:1113
command_loop at keyboard.c:1132
recursive_edit_1 at keyboard.c:779
read_minibuf at minibuf.c:664
Fread_from_minibuffer at minibuf.c:962
Ffuncall at eval.c:2879
exec_byte_code at bytecode.c:905
funcall_lambda at eval.c:3087
Ffuncall at eval.c:2902
exec_byte_code at bytecode.c:905
funcall_lambda at eval.c:3087
Ffuncall at eval.c:2902
exec_byte_code at bytecode.c:905
Fbyte_code at bytecode.c:478
eval_sub at eval.c:2229
internal_catch at eval.c:1113
exec_byte_code at bytecode.c:1086
funcall_lambda at eval.c:3087
Ffuncall at eval.c:2902
exec_byte_code at bytecode.c:905
funcall_lambda at eval.c:3087
Ffuncall at eval.c:2902
exec_byte_code at bytecode.c:905
Fbyte_code at bytecode.c:478
eval_sub at eval.c:2229
internal_catch at eval.c:1113
exec_byte_code at bytecode.c:1086
Fbyte_code at bytecode.c:478
eval_sub at eval.c:2229
internal_lisp_condition_case at eval.c:1294
exec_byte_code at bytecode.c:1101
funcall_lambda at eval.c:3087
Ffuncall at eval.c:2902
exec_byte_code at bytecode.c:905
funcall_lambda at eval.c:3087
Ffuncall at eval.c:2902
exec_byte_code at bytecode.c:905
??
??:0

bug#15213: 24.3.50; emacs_backtrace.txt

[Eli Zaretskii]

merge 15213 15183
thanks

> From: Juanma Barranquero <lekktu@gmail.com>
> Date: Sat, 31 Aug 2013 03:36:22 +0200
> Cc: 15213@debbugs.gnu.org
> 
> > Backtrace:
> 
> w32_backtrace at w32fns.c:7982
> emacs_abort at w32fns.c:8014
> terminate_due_to_signal at emacs.c:369
> die at alloc.c:6573
> XWINDOW at lisp.h:799
> temp_output_buffer_show at window.c:3360

Thanks for the annotations, Juanma.

This is the same as #15183, we hope Martin fixed that in revision
14005 (the backtrace was produced from revision 113986).

bug#15213: 24.3.50; emacs_backtrace.txt

[martin rudalics]

 >> w32_backtrace at w32fns.c:7982
 >> emacs_abort at w32fns.c:8014
 >> terminate_due_to_signal at emacs.c:369
 >> die at alloc.c:6573
 >> XWINDOW at lisp.h:799
 >> temp_output_buffer_show at window.c:3360
 >
 > Thanks for the annotations, Juanma.
 >
 > This is the same as #15183, we hope Martin fixed that in revision
 > 14005 (the backtrace was produced from revision 113986).

It's not related.  Basically, what happens here is that the window
produced by `display-buffer' for `temp-output-buffer-show' is not live.
This is a case `temp-output-buffer-show' doesn't handle, at least not on
trunk:

       window = display_buffer (buf, Qnil, Qnil);

       if (!EQ (XWINDOW (window)->frame, selected_frame))
	Fmake_frame_visible (WINDOW_FRAME (XWINDOW (window)));

But `temp-output-buffer-show' is obsolete since 24.3.  I suppose Drew
runs code byte-compiled with some pre 24.3 Emcas on trunk and either
does not produce a new window in `display-buffer' or delete it before
`temp-output-buffer-show' can deal with it.

martin

Bug tracker automated control server message

[martin rudalics]

The "GNU bug tracker automated control server" just told me that

> Processing commands for control@debbugs.gnu.org:
> 
>>  >> w32_backtrace at w32fns.c:7982
> Unknown command or malformed arguments to command.
> 
>>  >> emacs_abort at w32fns.c:8014
> Unknown command or malformed arguments to command.
> 
>>  >> terminate_due_to_signal at emacs.c:369
> Unknown command or malformed arguments to command.
> 
>>  >> die at alloc.c:6573
> Unknown command or malformed arguments to command.
> 
>>  >> XWINDOW at lisp.h:799
> Unknown command or malformed arguments to command.
> 
> Too many unknown commands, stopping here.
> 
> No commands successfully parsed; sending the help text(s).
> Sending instructions for control@debbugs.gnu.org in separate message.
> 
> Please contact help-debbugs@gnu.org if you need assistance.
> 
> GNU bugs database, http://debbugs.gnu.org/

I'd like to avoid this.  Any suggestions?

Thanks, martin

bug#15213: 24.3.50; emacs_backtrace.txt

[martin rudalics]

> This is a case `temp-output-buffer-show' doesn't handle, at least not on
> trunk:
> 
>       window = display_buffer (buf, Qnil, Qnil);
> 
>       if (!EQ (XWINDOW (window)->frame, selected_frame))
>     Fmake_frame_visible (WINDOW_FRAME (XWINDOW (window)));

I checked in a fix for this (revision#114078 on trunk).  Bug closed.

Thanks, martin

Re: Bug tracker automated control server message

[Eli Zaretskii]

> Date: Sat, 31 Aug 2013 10:38:55 +0200
> From: martin rudalics <rudalics@gmx.at>
> 
> The "GNU bug tracker automated control server" just told me that
> 
> > Processing commands for control@debbugs.gnu.org:
> > 
> >>  >> w32_backtrace at w32fns.c:7982
> > Unknown command or malformed arguments to command.
> > 
> >>  >> emacs_abort at w32fns.c:8014
> > Unknown command or malformed arguments to command.
> > 
> >>  >> terminate_due_to_signal at emacs.c:369
> > Unknown command or malformed arguments to command.
> > 
> >>  >> die at alloc.c:6573
> > Unknown command or malformed arguments to command.
> > 
> >>  >> XWINDOW at lisp.h:799
> > Unknown command or malformed arguments to command.
> > 
> > Too many unknown commands, stopping here.
> > 
> > No commands successfully parsed; sending the help text(s).
> > Sending instructions for control@debbugs.gnu.org in separate message.
> > 
> > Please contact help-debbugs@gnu.org if you need assistance.
> > 
> > GNU bugs database, http://debbugs.gnu.org/
> 
> I'd like to avoid this.  Any suggestions?

Put "stop" or "thanks" line before the stuff that isn't meant for the
tracker.

Re: Bug tracker automated control server message

[martin rudalics]

> Put "stop" or "thanks" line before the stuff that isn't meant for the
> tracker.

But this behavior of the tracker is new?

martin

Re: Bug tracker automated control server message

[David Engster]

martin rudalics writes:
>> Put "stop" or "thanks" line before the stuff that isn't meant for the
>> tracker.
>
> But this behavior of the tracker is new?

No, this happened because you also send the mail to the control server
at control@debbugs. My guess is that you did a wide reply on a message
were control@debbugs was in the CC without you noticing.

This is why the control@debbugs address should usually go in the BCC, so
that people who do a wide reply do not mail the control server by
accident.

-David

Re: Bug tracker automated control server message

[martin rudalics]

 >> But this behavior of the tracker is new?
 >
 > No, this happened because you also send the mail to the control server
 > at control@debbugs. My guess is that you did a wide reply on a message
 > were control@debbugs was in the CC without you noticing.
 >
 > This is why the control@debbugs address should usually go in the BCC, so
 > that people who do a wide reply do not mail the control server by
 > accident.

Thanks.  Eli merged the bugs and that's apparently how control@debbugs
came in.  I didn't know about the consequences.

martin

Re: Bug tracker automated control server message

[Eli Zaretskii]

> From: David Engster <deng@randomsample.de>
> Date: Sat, 31 Aug 2013 15:04:43 +0200
> Cc: Eli Zaretskii <eliz@gnu.org>, emacs-devel@gnu.org
> 
> This is why the control@debbugs address should usually go in the BCC, so
> that people who do a wide reply do not mail the control server by
> accident.

If control@debbugs goes in BCC, people will become confused about
those weird commands at the beginning of the message.

Re: Bug tracker automated control server message

[David Engster]

Eli Zaretskii writes:
>> From: David Engster <deng@randomsample.de>
>> Date: Sat, 31 Aug 2013 15:04:43 +0200
>> Cc: Eli Zaretskii <eliz@gnu.org>, emacs-devel@gnu.org
>> 
>> This is why the control@debbugs address should usually go in the BCC, so
>> that people who do a wide reply do not mail the control server by
>> accident.
>
> If control@debbugs goes in BCC, people will become confused about
> those weird commands at the beginning of the message.

I think those commands are pretty clear; before I learned about
control@debbugs, I used to think that the bugtracker simply always
processes them. IMO the messages you get from an accidental mail to the
control server are much weirder; also, as a guideline, using BCC is
recommended in admin/notes/bugtracker.

-David

bug#15213: 24.3.50; emacs_backtrace.txt

[Drew Adams]

Thanks for fixing the bug(s).

15213 and 15183 were merged.  Not sure whether your "It's not related."
means that those are two different bugs or that your previous fix for
15183 is unrelated to 15213.

Anyway, I just wanted to point out, relative to your guess that this
might be a result of my using a file compiled in an earlier Emacs
release, that 15183 was from emacs -Q, and IIRC none of my code was
ever loaded in that session.  The crash came very soon after emacs -Q.

(Also, FWIW, I have no code that calls `temp-output-buffer-show'.
But of course it might be called by other code, including vanilla code
from a previous release, as you suggest.)

HTH.

>  > This is the same as #15183, we hope Martin fixed that in revision
>  > 14005 (the backtrace was produced from revision 113986).
> 
> It's not related.  Basically, what happens here is that the window
> produced by `display-buffer' for `temp-output-buffer-show' is not live.
> This is a case `temp-output-buffer-show' doesn't handle, at least not on
> trunk:
>        window = display_buffer (buf, Qnil, Qnil);
> 
>        if (!EQ (XWINDOW (window)->frame, selected_frame))
> 	Fmake_frame_visible (WINDOW_FRAME (XWINDOW (window)));
> 
> But `temp-output-buffer-show' is obsolete since 24.3.  I suppose Drew
> runs code byte-compiled with some pre 24.3 Emcas on trunk and either
> does not produce a new window in `display-buffer' or delete it before
> `temp-output-buffer-show' can deal with it.

bug#15213: 24.3.50; emacs_backtrace.txt

[martin rudalics]

 > 15213 and 15183 were merged.  Not sure whether your "It's not related."
 > means that those are two different bugs

They are different bugs although both end up crashing when trying to
dereference a nil window pointer.

 > or that your previous fix for
 > 15183 is unrelated to 15213.

It is unrelated.

 > Anyway, I just wanted to point out, relative to your guess that this
 > might be a result of my using a file compiled in an earlier Emacs
 > release, that 15183 was from emacs -Q, and IIRC none of my code was
 > ever loaded in that session.  The crash came very soon after emacs -Q.

I've been talking exclusively about bug#15213 here.

 > (Also, FWIW, I have no code that calls `temp-output-buffer-show'.
 > But of course it might be called by other code, including vanilla code
 > from a previous release, as you suggest.)

Current trunk nowhere calls `temp-output-buffer-show' so it must come
from a previous release.

martin