GNU bug report logs -
#16207
24.3.50; emacs_backtrace.txt
Previous Next
Reported by: Drew Adams <drew.adams <at> oracle.com>
Date: Fri, 20 Dec 2013 21:40:03 UTC
Severity: normal
Found in version 24.3.50
Done: martin rudalics <rudalics <at> gmx.at>
Bug is archived. No further changes may be made.
To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 16207 in the body.
You can then email your comments to 16207 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#16207; Package
emacs.
(Fri, 20 Dec 2013 21:40:03 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.
(Fri, 20 Dec 2013 21:40:04 GMT)
Full text and
rfc822 format available.
Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):
Backtrace:
011f90c2
011f9134
010edc19
0115fe24
010e9bab
0108856c
0100e6c5
0100e1a8
0108f611
0117e030
011be773
0117e812
0117e26c
0117cb98
0117884c
011788b4
0117f394
011be816
0117e812
0117e26c
0117d591
0117dac6
0117835c
0117d0d8
0117884c
01179fd7
0117ca06
0117884c
01178799
0117ca06
0117884c
0117eb41
0117e33f
0117d591
0117df20
011be773
0117e812
0117e26c
0117d591
0117cb98
0117884c
0117eb41
0117e33f
011be773
0117e812
0117e26c
011be773
0117e812
0117e26c
011be773
0117e812
0117e26c
011be773
0117e812
0117e26c
011be773
0117e812
0117e26c
0117d591
0117df20
011be773
0117e812
...
In GNU Emacs 24.3.50.1 (i686-pc-mingw32)
of 2013-12-16 on ODIEONE
Bzr revision: 115543 rudalics <at> gmx.at-20131216095844-lbjh5yerk6ff0tm7
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'
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#16207; Package
emacs.
(Fri, 20 Dec 2013 21:54:01 GMT)
Full text and
rfc822 format available.
Message #8 received at 16207 <at> debbugs.gnu.org (full text, mbox):
This is with emacs -Q. I was in the debugger, and I widened the frame using the mouse. That caused the crash. Twice now - same backtrace.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#16207; Package
emacs.
(Fri, 20 Dec 2013 22:42:02 GMT)
Full text and
rfc822 format available.
Message #11 received at 16207 <at> debbugs.gnu.org (full text, mbox):
??
??:0
Ffile_system_info at w32fns.c:7436
Ffile_system_info at w32fns.c:7452
GLYPH_CODE_P at dispextern.h:1851
mark_object at alloc.c:5996
face_for_overlay_string at xfaces.c:6068
window_loop at window.c:2761
change_frame_size_1 at dispnew.c:5570
do_pending_window_change at dispnew.c:5413
Frecenter at window.c:5577
eval_sub at eval.c:2137
copy_executable_and_dump_data at unexw32.c:605
Fapply at eval.c:2316
eval_sub at eval.c:2189
xsignal2 at eval.c:1599
Fcall_interactively at callint.c:774
Fcall_interactively at callint.c:774
Ffuncall at eval.c:2778
copy_executable_and_dump_data at unexw32.c:615
Fapply at eval.c:2316
eval_sub at eval.c:2189
Fcommandp at eval.c:1850
grow_specpdl at eval.c:2021
Fcall_interactively at callint.c:679
maybe_call_debugger at eval.c:1714
Fcall_interactively at callint.c:774
Fsetq at eval.c:542
Fsignal at eval.c:1536
Fcall_interactively at callint.c:774
Fcall_interactively at callint.c:775
Fsignal at eval.c:1536
Fcall_interactively at callint.c:774
Frun_hook_with_args_until_success at eval.c:2422
eval_sub at eval.c:2199
Fcommandp at eval.c:1850
eval_sub at eval.c:2129
copy_executable_and_dump_data at unexw32.c:605
Fapply at eval.c:2316
eval_sub at eval.c:2189
Fcommandp at eval.c:1850
xsignal2 at eval.c:1599
Fcall_interactively at callint.c:774
Frun_hook_with_args_until_success at eval.c:2422
eval_sub at eval.c:2199
copy_executable_and_dump_data at unexw32.c:605
Fapply at eval.c:2316
eval_sub at eval.c:2189
copy_executable_and_dump_data at unexw32.c:605
Fapply at eval.c:2316
eval_sub at eval.c:2189
copy_executable_and_dump_data at unexw32.c:605
Fapply at eval.c:2316
eval_sub at eval.c:2189
copy_executable_and_dump_data at unexw32.c:605
Fapply at eval.c:2316
eval_sub at eval.c:2189
copy_executable_and_dump_data at unexw32.c:605
Fapply at eval.c:2316
eval_sub at eval.c:2189
Fcommandp at eval.c:1850
eval_sub at eval.c:2129
copy_executable_and_dump_data at unexw32.c:605
Fapply at eval.c:2316
??
??:0
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#16207; Package
emacs.
(Sat, 21 Dec 2013 09:39:01 GMT)
Full text and
rfc822 format available.
Message #14 received at 16207 <at> debbugs.gnu.org (full text, mbox):
> Date: Fri, 20 Dec 2013 13:38:47 -0800 (PST)
> From: Drew Adams <drew.adams <at> oracle.com>
>
>
>
> Backtrace:
> 011f90c2
Where are my first 2 lines in the file, which show the exception and
its address? They come before the "Backtrace" part. Were they
absent, or did you omit them from your post?
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#16207; Package
emacs.
(Sat, 21 Dec 2013 09:48:02 GMT)
Full text and
rfc822 format available.
Message #17 received at 16207 <at> debbugs.gnu.org (full text, mbox):
> Date: Fri, 20 Dec 2013 13:53:53 -0800 (PST)
> From: Drew Adams <drew.adams <at> oracle.com>
>
> This is with emacs -Q. I was in the debugger, and I widened the frame using the mouse. That caused the crash. Twice now - same backtrace.
Can you please show a recipe starting with "emacs -Q"? The backtrace
makes no sense at all: it shows call sequences that don't exist in the
sources. So a reproducible recipe is our only hope.
Please be as detailed in the recipe as you can. E.g., please tell
exactly how did you "widen the frame with the mouse" -- which portion
of the frame did you drag and in what direction.
Thanks.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#16207; Package
emacs.
(Sat, 21 Dec 2013 16:23:02 GMT)
Full text and
rfc822 format available.
Message #20 received at 16207 <at> debbugs.gnu.org (full text, mbox):
> > Backtrace:
> > 011f90c2
>
> Where are my first 2 lines in the file, which show the exception and
> its address? They come before the "Backtrace" part. Were they
> absent, or did you omit them from your post?
I posted the complete contents of the file, using `insert-file'.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#16207; Package
emacs.
(Sat, 21 Dec 2013 16:28:01 GMT)
Full text and
rfc822 format available.
Message #23 received at 16207 <at> debbugs.gnu.org (full text, mbox):
> Can you please show a recipe starting with "emacs -Q"? The backtrace
> makes no sense at all: it shows call sequences that don't exist in the
> sources. So a reproducible recipe is our only hope.
>
> Please be as detailed in the recipe as you can. E.g., please tell
> exactly how did you "widen the frame with the mouse" -- which portion
> of the frame did you drag and in what direction.
emacs -Q
(Well actually, my Windows shortcut for -Q has it open a directory with
Dired.)
M-x load-library pp.el
M-x debug-on-entry pp-eval-expression
M-x pp-eval-expression global-map
In debugger, hit `d' once or twice.
Then grab the right frame edge and pull it to the right a few inches.
Hit `d' -> crash.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#16207; Package
emacs.
(Sat, 21 Dec 2013 16:55:01 GMT)
Full text and
rfc822 format available.
Message #26 received at 16207 <at> debbugs.gnu.org (full text, mbox):
lisp.h:874: Emacs fatal error: assertion failed: BUFFERP (a)
Breakpoint 1, terminate_due_to_signal (sig=22,
backtrace_limit=2147483647) at emacs.c:351
351 signal (sig, SIG_DFL);
(gdb) bt
#0 terminate_due_to_signal (sig=22, backtrace_limit=2147483647) at emacs.c:351
#1 0x011615dc in die (msg=0x148b198 "BUFFERP (a)", file=0x148b10c
"lisp.h", line=874) at alloc.c:6742
#2 0x010eb7fb in XBUFFER (a=58132514) at lisp.h:874
#3 0x01089e14 in run_window_configuration_change_hook (f=0x3aa1a08
<__register_frame_info+61479432>) at window.c:3257
#4 0x0100e79c in change_frame_size_1 (f=0x3aa1a08
<__register_frame_info+61479432>, new_width=824, new_height=608,
pretend=false, delay=false, safe=false,
pixelwise=true) at dispnew.c:5588
#5 0x0100e27f in change_frame_size (f=0x3aa1a08
<__register_frame_info+61479432>, new_width=824, new_height=608,
pretend=false, delay=false, safe=false,
pixelwise=true) at dispnew.c:5457
#6 0x01090ff6 in Fset_window_configuration (configuration=86847613)
at window.c:6233
#7 0x0117f87f in Ffuncall (nargs=2, args=0x88db24) at eval.c:2805
#8 0x011c0344 in exec_byte_code (bytestr=58650753, vector=86847981,
maxdepth=12, args_template=0, nargs=0, args=0x88de54) at
bytecode.c:919
#9 0x01180061 in funcall_lambda (fun=86848077, nargs=0,
arg_vector=0x88de54) at eval.c:2973
#10 0x0117fabb in Ffuncall (nargs=1, args=0x88de50) at eval.c:2854
#11 0x0117e3e7 in eval_sub (form=62132246) at eval.c:2147
#12 0x0117a078 in Fprogn (body=62132254) at eval.c:458
#13 0x0117a0e0 in unwind_body (body=62132254) at eval.c:472
#14 0x01180c08 in unbind_to (count=26, value=58132514) at eval.c:3296
#15 0x011c03e7 in exec_byte_code (bytestr=58732321, vector=58472509,
maxdepth=172, args_template=512, nargs=1, args=0x88e408) at
bytecode.c:941
#16 0x01180061 in funcall_lambda (fun=58472829, nargs=1,
arg_vector=0x88e408) at eval.c:2973
#17 0x0117fabb in Ffuncall (nargs=2, args=0x88e404) at eval.c:2854
#18 0x0117ea0f in Fapply (nargs=2, args=0x88e404) at eval.c:2291
#19 0x0117f315 in apply1 (fn=58262082, arg=62135166) at eval.c:2578
#20 0x01179b88 in call_debugger (arg=62135166) at eval.c:322
#21 0x01179be6 in do_debug_on_call (code=58183842) at eval.c:338
#22 0x0117f61b in Ffuncall (nargs=2, args=0x88e61c) at eval.c:2759
#23 0x0117ea0f in Fapply (nargs=2, args=0x88e61c) at eval.c:2291
#24 0x0117f76f in Ffuncall (nargs=3, args=0x88e618) at eval.c:2786
#25 0x011c0344 in exec_byte_code (bytestr=60319409, vector=62168693,
maxdepth=16, args_template=512, nargs=1, args=0x88e9a8) at
bytecode.c:919
#26 0x01180061 in funcall_lambda (fun=61883925, nargs=1,
arg_vector=0x88e9a8) at eval.c:2973
#27 0x0117fabb in Ffuncall (nargs=2, args=0x88e9a4) at eval.c:2854
#28 0x0117ea0f in Fapply (nargs=2, args=0x88e9a4) at eval.c:2291
#29 0x0117f315 in apply1 (fn=60622306, arg=62140750) at eval.c:2578
#30 0x011776de in Fcall_interactively (function=60622306,
record_flag=60294018, keys=58153845) at callint.c:378
#31 0x0117f8d4 in Ffuncall (nargs=4, args=0x88ebdc) at eval.c:2812
#32 0x011c0344 in exec_byte_code (bytestr=19806545, vector=19806565,
maxdepth=52, args_template=4100, nargs=2, args=0x88ef30) at
bytecode.c:919
#33 0x01180061 in funcall_lambda (fun=19806525, nargs=2,
arg_vector=0x88ef28) at eval.c:2973
#34 0x0117fabb in Ffuncall (nargs=3, args=0x88ef24) at eval.c:2854
#35 0x011c0344 in exec_byte_code (bytestr=19806217, vector=19806237,
maxdepth=60, args_template=2052, nargs=2, args=0x88f26c) at
bytecode.c:919
#36 0x01180061 in funcall_lambda (fun=19806189, nargs=2,
arg_vector=0x88f264) at eval.c:2973
#37 0x0117fabb in Ffuncall (nargs=3, args=0x88f260) at eval.c:2854
#38 0x0117ede0 in Fapply (nargs=2, args=0x88f2e4) at eval.c:2344
#39 0x0117f315 in apply1 (fn=58340930, arg=60849846) at eval.c:2578
#40 0x011776de in Fcall_interactively (function=58340930,
record_flag=58132514, keys=58153845) at callint.c:378
#41 0x0117f8d4 in Ffuncall (nargs=4, args=0x88f51c) at eval.c:2812
#42 0x011c0344 in exec_byte_code (bytestr=19806545, vector=19806565,
maxdepth=52, args_template=4100, nargs=1, args=0x88f860) at
bytecode.c:919
#43 0x01180061 in funcall_lambda (fun=19806525, nargs=1,
arg_vector=0x88f85c) at eval.c:2973
#44 0x0117fabb in Ffuncall (nargs=2, args=0x88f858) at eval.c:2854
#45 0x0117f36a in call1 (fn=58178658, arg1=58340930) at eval.c:2604
#46 0x010f3c29 in command_loop_1 () at keyboard.c:1552
#47 0x0117c765 in internal_condition_case (bfun=0x10f35c5
<command_loop_1>, handlers=58183970, hfun=0x10f2e2b <cmd_error>) at
eval.c:1344
#48 0x010f327a in command_loop_2 (ignore=58132514) at keyboard.c:1170
#49 0x0117bd12 in internal_catch (tag=58179330, func=0x10f3256
<command_loop_2>, arg=58132514) at eval.c:1108
#50 0x010f3232 in command_loop () at keyboard.c:1149
#51 0x010f29c8 in recursive_edit_1 () at keyboard.c:777
#52 0x010f2b84 in Frecursive_edit () at keyboard.c:841
#53 0x010f0d7c in main (argc=2, argv=0xbb1b20) at emacs.c:1634
Lisp Backtrace:
"set-window-configuration" (0x88db28)
0x52d3248 PVEC_COMPILED
"funcall" (0x88de50)
"debug" (0x88e408)
0x37cb620 PVEC_COMPILED
"apply" (0x88e61c)
"pp-eval-expression" (0x88e9a8)
"call-interactively" (0x88ebe0)
"command-execute" (0x88ef28)
"execute-extended-command" (0x88f264)
"call-interactively" (0x88f520)
"command-execute" (0x88f85c)
(gdb)
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#16207; Package
emacs.
(Sat, 21 Dec 2013 16:57:02 GMT)
Full text and
rfc822 format available.
Message #29 received at 16207 <at> debbugs.gnu.org (full text, mbox):
Here is the backtrace I got with that recipe. Dunno why the first file I included ended with `...'. This one starts out the same, anyway. HTH.
Backtrace:
011f90c2
011f9134
010edc19
0115fe24
010e9bab
0108856c
0100e6c5
0100e1a8
0108f611
0117e030
011be773
0117e812
0117e26c
0117cb98
0117884c
011788b4
0117f394
011be816
0117e812
0117e26c
0117d1c0
0117dac6
0117835c
011783ba
0117ddcc
0117d1c0
0117df20
011be773
0117e812
0117e26c
0117d1c0
0117dac6
01175eaa
0117e085
011be773
0117e812
0117e26c
011be773
0117e812
0117e26c
0117d591
0117dac6
01175eaa
0117e085
011be773
0117e812
0117e26c
0117db1b
010f1fa8
0117af2c
010f15fc
0117a4d9
010f15b4
010f0d4c
010f0f08
010ef113
010010f9
76f43366
77899f6e
77899f41
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#16207; Package
emacs.
(Sat, 21 Dec 2013 17:16:01 GMT)
Full text and
rfc822 format available.
Message #32 received at 16207 <at> debbugs.gnu.org (full text, mbox):
> Breakpoint 1, terminate_due_to_signal (sig=22,
> backtrace_limit=2147483647) at emacs.c:351
> 351 signal (sig, SIG_DFL);
> (gdb) bt
> #0 terminate_due_to_signal (sig=22, backtrace_limit=2147483647) at emacs.c:351
> #1 0x011615dc in die (msg=0x148b198 "BUFFERP (a)", file=0x148b10c
> "lisp.h", line=874) at alloc.c:6742
> #2 0x010eb7fb in XBUFFER (a=58132514) at lisp.h:874
> #3 0x01089e14 in run_window_configuration_change_hook (f=0x3aa1a08
> <__register_frame_info+61479432>) at window.c:3257
...
> "set-window-configuration" (0x88db28)
The selected window doesn't have a buffer. I have no idea how to track
this down. Basically, we'd have to record in some variable a triple
<operation executed, selected window, its buffer> whenever we (1) select
a window, (2) delete a window, (3) kill a buffer, and check at strategic
positions (e.g. as above in run_window_configuration_change_hook)
whether this variable contains something fishy and put that variable's
value somewhere before aborting. Tedious ...
martin
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#16207; Package
emacs.
(Sat, 21 Dec 2013 18:32:03 GMT)
Full text and
rfc822 format available.
Message #35 received at 16207 <at> debbugs.gnu.org (full text, mbox):
> > Breakpoint 1, terminate_due_to_signal (sig=22,
> > backtrace_limit=2147483647) at emacs.c:351
> > 351 signal (sig, SIG_DFL);
> > (gdb) bt
> > #0 terminate_due_to_signal (sig=22, backtrace_limit=2147483647) at
> emacs.c:351
> > #1 0x011615dc in die (msg=0x148b198 "BUFFERP (a)", file=0x148b10c
> > "lisp.h", line=874) at alloc.c:6742
> > #2 0x010eb7fb in XBUFFER (a=58132514) at lisp.h:874
> > #3 0x01089e14 in run_window_configuration_change_hook (f=0x3aa1a08
> > <__register_frame_info+61479432>) at window.c:3257
> ...
> > "set-window-configuration" (0x88db28)
Which is obviously bug#16051 which I've been now able to reproduce for
the first time. And it's definitively the toolbar-window which causes
the crash. And I can get it crash or loop forever (no C-g exit) on my
Gtk build too.
martin
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#16207; Package
emacs.
(Sat, 21 Dec 2013 18:40:02 GMT)
Full text and
rfc822 format available.
Message #38 received at 16207 <at> debbugs.gnu.org (full text, mbox):
> Date: Sat, 21 Dec 2013 08:22:54 -0800 (PST)
> From: Drew Adams <drew.adams <at> oracle.com>
> Cc: 16207 <at> debbugs.gnu.org
>
> > > Backtrace:
> > > 011f90c2
> >
> > Where are my first 2 lines in the file, which show the exception and
> > its address? They come before the "Backtrace" part. Were they
> > absent, or did you omit them from your post?
>
> I posted the complete contents of the file, using `insert-file'.
Too bad. Thanks.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#16207; Package
emacs.
(Sat, 21 Dec 2013 18:46:01 GMT)
Full text and
rfc822 format available.
Message #41 received at 16207 <at> debbugs.gnu.org (full text, mbox):
> Date: Sat, 21 Dec 2013 18:15:14 +0100
> From: martin rudalics <rudalics <at> gmx.at>
> Cc: 16207 <at> debbugs.gnu.org
>
> > Breakpoint 1, terminate_due_to_signal (sig=22,
> > backtrace_limit=2147483647) at emacs.c:351
> > 351 signal (sig, SIG_DFL);
> > (gdb) bt
> > #0 terminate_due_to_signal (sig=22, backtrace_limit=2147483647) at emacs.c:351
> > #1 0x011615dc in die (msg=0x148b198 "BUFFERP (a)", file=0x148b10c
> > "lisp.h", line=874) at alloc.c:6742
> > #2 0x010eb7fb in XBUFFER (a=58132514) at lisp.h:874
> > #3 0x01089e14 in run_window_configuration_change_hook (f=0x3aa1a08
> > <__register_frame_info+61479432>) at window.c:3257
> ...
> > "set-window-configuration" (0x88db28)
>
> The selected window doesn't have a buffer. I have no idea how to track
> this down.
Maybe one way is to think how could this happen, ever. How can such
window even exist?
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#16207; Package
emacs.
(Sat, 21 Dec 2013 18:47:02 GMT)
Full text and
rfc822 format available.
Message #44 received at 16207 <at> debbugs.gnu.org (full text, mbox):
> From: Juanma Barranquero <lekktu <at> gmail.com>
> Date: Sat, 21 Dec 2013 17:53:29 +0100
> Cc: Eli Zaretskii <eliz <at> gnu.org>, 16207 <at> debbugs.gnu.org
>
> lisp.h:874: Emacs fatal error: assertion failed: BUFFERP (a)
>
> Breakpoint 1, terminate_due_to_signal (sig=22,
> backtrace_limit=2147483647) at emacs.c:351
> 351 signal (sig, SIG_DFL);
> (gdb) bt
> #0 terminate_due_to_signal (sig=22, backtrace_limit=2147483647) at emacs.c:351
> #1 0x011615dc in die (msg=0x148b198 "BUFFERP (a)", file=0x148b10c
> "lisp.h", line=874) at alloc.c:6742
Thanks. What does "xtype" say about this 'a' that was expected to be
a buffer?
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#16207; Package
emacs.
(Sat, 21 Dec 2013 18:52:02 GMT)
Full text and
rfc822 format available.
Message #47 received at 16207 <at> debbugs.gnu.org (full text, mbox):
On Sat, Dec 21, 2013 at 7:46 PM, Eli Zaretskii <eliz <at> gnu.org> wrote:
> What does "xtype" say about this 'a' that was expected to be a buffer?
(gdb) frame 2
#2 0x010eb7fb in XBUFFER (a=58132514) at lisp.h:874
874 eassert (BUFFERP (a));
(gdb) p a
$1 = 58132514
(gdb) xtype
Lisp_Symbol
(gdb)
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#16207; Package
emacs.
(Sat, 21 Dec 2013 18:53:01 GMT)
Full text and
rfc822 format available.
Message #50 received at 16207 <at> debbugs.gnu.org (full text, mbox):
On Sat, Dec 21, 2013 at 7:50 PM, Juanma Barranquero <lekktu <at> gmail.com> wrote:
> Lisp_Symbol
nil, BTW
J
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#16207; Package
emacs.
(Sat, 21 Dec 2013 18:59:01 GMT)
Full text and
rfc822 format available.
Message #53 received at 16207 <at> debbugs.gnu.org (full text, mbox):
> Date: Sat, 21 Dec 2013 19:31:47 +0100
> From: martin rudalics <rudalics <at> gmx.at>
> Cc: 16207 <at> debbugs.gnu.org
>
> > > Breakpoint 1, terminate_due_to_signal (sig=22,
> > > backtrace_limit=2147483647) at emacs.c:351
> > > 351 signal (sig, SIG_DFL);
> > > (gdb) bt
> > > #0 terminate_due_to_signal (sig=22, backtrace_limit=2147483647) at
> > emacs.c:351
> > > #1 0x011615dc in die (msg=0x148b198 "BUFFERP (a)", file=0x148b10c
> > > "lisp.h", line=874) at alloc.c:6742
> > > #2 0x010eb7fb in XBUFFER (a=58132514) at lisp.h:874
> > > #3 0x01089e14 in run_window_configuration_change_hook (f=0x3aa1a08
> > > <__register_frame_info+61479432>) at window.c:3257
> > ...
> > > "set-window-configuration" (0x88db28)
>
> Which is obviously bug#16051 which I've been now able to reproduce for
> the first time. And it's definitively the toolbar-window which causes
> the crash.
But then the XBUFFER thing is bogus, because the tool-bar window never
has a buffer. Its 'contents' field is always nil.
But how did that window get to become the "selected" window?? It
should never be that, I think.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#16207; Package
emacs.
(Sat, 21 Dec 2013 19:00:03 GMT)
Full text and
rfc822 format available.
Message #56 received at 16207 <at> debbugs.gnu.org (full text, mbox):
> Date: Sat, 21 Dec 2013 20:46:25 +0200
> From: Eli Zaretskii <eliz <at> gnu.org>
> Cc: 16207 <at> debbugs.gnu.org
>
> > #1 0x011615dc in die (msg=0x148b198 "BUFFERP (a)", file=0x148b10c
> > "lisp.h", line=874) at alloc.c:6742
>
> Thanks. What does "xtype" say about this 'a' that was expected to be
> a buffer?
I'm guessing it's a symbol nil.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#16207; Package
emacs.
(Sat, 21 Dec 2013 19:41:03 GMT)
Full text and
rfc822 format available.
Message #59 received at 16207 <at> debbugs.gnu.org (full text, mbox):
>> Which is obviously bug#16051 which I've been now able to reproduce for
>> the first time. And it's definitively the toolbar-window which causes
>> the crash.
Too silly - I sent my message to the 16207 thread and meant to send it
to the 16051 one where you already remarked my missing insight.
So please disregard the remarks Eli cited on top of this mail in the
current thread: The toolbar window is by no means involved and neither
is this bug related to bug#16051.
> But then the XBUFFER thing is bogus, because the tool-bar window never
> has a buffer. Its 'contents' field is always nil.
If the toolbar window ended up here, something crazy would have happened
indeed.
martin
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#16207; Package
emacs.
(Sat, 21 Dec 2013 19:59:01 GMT)
Full text and
rfc822 format available.
Message #62 received at 16207 <at> debbugs.gnu.org (full text, mbox):
> Maybe one way is to think how could this happen, ever. How can such
> window even exist?
I think I know what's causing it. But I have to do some testing
before checking in a fix.
In any case, don't bother about this until you hear from me.
martin
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#16207; Package
emacs.
(Sat, 21 Dec 2013 20:12:02 GMT)
Full text and
rfc822 format available.
Message #65 received at 16207 <at> debbugs.gnu.org (full text, mbox):
> Date: Sat, 21 Dec 2013 20:58:49 +0100
> From: martin rudalics <rudalics <at> gmx.at>
> CC: lekktu <at> gmail.com, 16207 <at> debbugs.gnu.org
>
> > Maybe one way is to think how could this happen, ever. How can such
> > window even exist?
>
> I think I know what's causing it. But I have to do some testing
> before checking in a fix.
Great, thanks.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#16207; Package
emacs.
(Sun, 22 Dec 2013 15:38:02 GMT)
Full text and
rfc822 format available.
Message #68 received at 16207 <at> debbugs.gnu.org (full text, mbox):
> I think I know what's causing it. But I have to do some testing
> before checking in a fix.
Rather than spending hours to test this I checked in a fix. This way we
should find out soon enough whether it breaks anything else.
In this context I wonder what the variable inhibit_lisp_code stands for.
Initially, it was called inhibit_window_configuration_change_hook and
did exactly what its name said. Then it moved to eval.c, got its new
name, but still does what it did before. So if we want this to really
inihibit running Lisp code we should obey it in each and every hook
(although I fail to understand why we can't bind Vrun_hooks instead).
Otherwise, we should probably give it back its initial name to avoid
confusions. WDYT?
martin
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#16207; Package
emacs.
(Sun, 22 Dec 2013 15:41:01 GMT)
Full text and
rfc822 format available.
Message #71 received at 16207 <at> debbugs.gnu.org (full text, mbox):
On Sun, Dec 22, 2013 at 4:37 PM, martin rudalics <rudalics <at> gmx.at> wrote:
> Rather than spending hours to test this I checked in a fix. This way we
> should find out soon enough whether it breaks anything else.
I'm bootstrapping a new binary for Drew to try, it'll be up ASAP.
J
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#16207; Package
emacs.
(Mon, 23 Dec 2013 05:38:03 GMT)
Full text and
rfc822 format available.
Message #74 received at 16207 <at> debbugs.gnu.org (full text, mbox):
> Rather than spending hours to test this I checked in a fix. This way we
> should find out soon enough whether it breaks anything else.
>
> In this context I wonder what the variable inhibit_lisp_code stands for.
> Initially, it was called inhibit_window_configuration_change_hook and
> did exactly what its name said. Then it moved to eval.c, got its new
> name, but still does what it did before. So if we want this to really
> inihibit running Lisp code we should obey it in each and every hook
> (although I fail to understand why we can't bind Vrun_hooks instead).
> Otherwise, we should probably give it back its initial name to avoid
> confusions. WDYT?
I tested with this version, and it seems to be fixed. Thx.
In GNU Emacs 24.3.50.1 (i686-pc-mingw32)
of 2013-12-22 on ODIEONE
Bzr revision: 115700 xfq.free <at> gmail.com-20131222231942-q8ftfeg3ft2a1t83
Windowing system distributor `Microsoft Corp.', version 6.1.7601
Configured using:
`configure --prefix=/c/Devel/emacs/binary --enable-checking=yes,glyphs
'CFLAGS=-O0 -g3' CPPFLAGS=-Ic:/Devel/emacs/include
LDFLAGS=-Lc:/Devel/emacs/lib'
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#16207; Package
emacs.
(Mon, 23 Dec 2013 16:25:02 GMT)
Full text and
rfc822 format available.
Message #77 received at 16207 <at> debbugs.gnu.org (full text, mbox):
> Date: Sun, 22 Dec 2013 16:37:36 +0100
> From: martin rudalics <rudalics <at> gmx.at>
> CC: lekktu <at> gmail.com, 16207 <at> debbugs.gnu.org, Chong Yidong <cyd <at> gnu.org>
>
> > I think I know what's causing it. But I have to do some testing
> > before checking in a fix.
>
> Rather than spending hours to test this I checked in a fix. This way we
> should find out soon enough whether it breaks anything else.
Thanks!
> In this context I wonder what the variable inhibit_lisp_code stands for.
> Initially, it was called inhibit_window_configuration_change_hook and
> did exactly what its name said. Then it moved to eval.c, got its new
> name, but still does what it did before. So if we want this to really
> inihibit running Lisp code we should obey it in each and every hook
> (although I fail to understand why we can't bind Vrun_hooks instead).
> Otherwise, we should probably give it back its initial name to avoid
> confusions. WDYT?
If you are asking me, then there's nothing intelligent I can say about
this issue: I didn't rename the variable and didn't even notice it got
renamed.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#16207; Package
emacs.
(Mon, 23 Dec 2013 18:45:03 GMT)
Full text and
rfc822 format available.
Message #80 received at 16207 <at> debbugs.gnu.org (full text, mbox):
> I'm bootstrapping a new binary for Drew to try, it'll be up ASAP.
Belated thanks.
martin
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#16207; Package
emacs.
(Mon, 23 Dec 2013 18:45:03 GMT)
Full text and
rfc822 format available.
Message #83 received at 16207 <at> debbugs.gnu.org (full text, mbox):
> If you are asking me, then there's nothing intelligent I can say about
> this issue: I didn't rename the variable and didn't even notice it got
> renamed.
IIUC Chong invented the variable and renamed it. That's why I was
CC-ing him.
martin
Reply sent
to
martin rudalics <rudalics <at> gmx.at>:
You have taken responsibility.
(Sat, 04 Jan 2014 14:13:04 GMT)
Full text and
rfc822 format available.
Notification sent
to
Drew Adams <drew.adams <at> oracle.com>:
bug acknowledged by developer.
(Sat, 04 Jan 2014 14:13:05 GMT)
Full text and
rfc822 format available.
Message #88 received at 16207-done <at> debbugs.gnu.org (full text, mbox):
> I tested with this version, and it seems to be fixed. Thx.
Bug closed.
Thanks, martin
bug archived.
Request was from
Debbugs Internal Request <help-debbugs <at> gnu.org>
to
internal_control <at> debbugs.gnu.org.
(Sun, 02 Feb 2014 12:24:04 GMT)
Full text and
rfc822 format available.
This bug report was last modified 11 years and 142 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.