* bug#16207: 24.3.50; emacs_backtrace.txt
@ 2013-12-20 21:38 Drew Adams
2013-12-20 21:53 ` Drew Adams
` (2 more replies)
0 siblings, 3 replies; 28+ messages in thread
From: Drew Adams @ 2013-12-20 21:38 UTC (permalink / raw)
To: 16207
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@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'
^ permalink raw reply [flat|nested] 28+ messages in thread* bug#16207: 24.3.50; emacs_backtrace.txt 2013-12-20 21:38 bug#16207: 24.3.50; emacs_backtrace.txt Drew Adams @ 2013-12-20 21:53 ` Drew Adams 2013-12-21 9:46 ` Eli Zaretskii 2013-12-20 22:41 ` Juanma Barranquero 2013-12-21 9:38 ` Eli Zaretskii 2 siblings, 1 reply; 28+ messages in thread From: Drew Adams @ 2013-12-20 21:53 UTC (permalink / raw) To: 16207 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. ^ permalink raw reply [flat|nested] 28+ messages in thread
* bug#16207: 24.3.50; emacs_backtrace.txt 2013-12-20 21:53 ` Drew Adams @ 2013-12-21 9:46 ` Eli Zaretskii 0 siblings, 0 replies; 28+ messages in thread From: Eli Zaretskii @ 2013-12-21 9:46 UTC (permalink / raw) To: Drew Adams; +Cc: 16207 > Date: Fri, 20 Dec 2013 13:53:53 -0800 (PST) > From: Drew Adams <drew.adams@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. ^ permalink raw reply [flat|nested] 28+ messages in thread
* bug#16207: 24.3.50; emacs_backtrace.txt 2013-12-20 21:38 bug#16207: 24.3.50; emacs_backtrace.txt Drew Adams 2013-12-20 21:53 ` Drew Adams @ 2013-12-20 22:41 ` Juanma Barranquero 2013-12-21 9:38 ` Eli Zaretskii 2 siblings, 0 replies; 28+ messages in thread From: Juanma Barranquero @ 2013-12-20 22:41 UTC (permalink / raw) To: Drew Adams; +Cc: 16207 ?? ??: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 ^ permalink raw reply [flat|nested] 28+ messages in thread
* bug#16207: 24.3.50; emacs_backtrace.txt 2013-12-20 21:38 bug#16207: 24.3.50; emacs_backtrace.txt Drew Adams 2013-12-20 21:53 ` Drew Adams 2013-12-20 22:41 ` Juanma Barranquero @ 2013-12-21 9:38 ` Eli Zaretskii 2 siblings, 0 replies; 28+ messages in thread From: Eli Zaretskii @ 2013-12-21 9:38 UTC (permalink / raw) To: Drew Adams; +Cc: 16207 > Date: Fri, 20 Dec 2013 13:38:47 -0800 (PST) > From: Drew Adams <drew.adams@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? ^ permalink raw reply [flat|nested] 28+ messages in thread
[parent not found: <<efed9c40-3985-45be-81fd-22e7f8912725@default>]
[parent not found: <<83fvpma6ie.fsf@gnu.org>]
* bug#16207: 24.3.50; emacs_backtrace.txt [not found] ` <<83fvpma6ie.fsf@gnu.org> @ 2013-12-21 16:22 ` Drew Adams 2013-12-21 18:38 ` Eli Zaretskii 0 siblings, 1 reply; 28+ messages in thread From: Drew Adams @ 2013-12-21 16:22 UTC (permalink / raw) To: Eli Zaretskii; +Cc: 16207 > > 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'. ^ permalink raw reply [flat|nested] 28+ messages in thread
* bug#16207: 24.3.50; emacs_backtrace.txt 2013-12-21 16:22 ` Drew Adams @ 2013-12-21 18:38 ` Eli Zaretskii 0 siblings, 0 replies; 28+ messages in thread From: Eli Zaretskii @ 2013-12-21 18:38 UTC (permalink / raw) To: Drew Adams; +Cc: 16207 > Date: Sat, 21 Dec 2013 08:22:54 -0800 (PST) > From: Drew Adams <drew.adams@oracle.com> > Cc: 16207@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. ^ permalink raw reply [flat|nested] 28+ messages in thread
[parent not found: <<fce2b6f2-11f6-400f-8ac6-382ab9a9d9bb@default>]
[parent not found: <<83eh56a64m.fsf@gnu.org>]
* bug#16207: 24.3.50; emacs_backtrace.txt [not found] ` <<83eh56a64m.fsf@gnu.org> @ 2013-12-21 16:27 ` Drew Adams 2013-12-21 16:53 ` Juanma Barranquero 2013-12-21 16:56 ` Drew Adams 0 siblings, 2 replies; 28+ messages in thread From: Drew Adams @ 2013-12-21 16:27 UTC (permalink / raw) To: Eli Zaretskii, Drew Adams; +Cc: 16207 > 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. ^ permalink raw reply [flat|nested] 28+ messages in thread
* bug#16207: 24.3.50; emacs_backtrace.txt 2013-12-21 16:27 ` Drew Adams @ 2013-12-21 16:53 ` Juanma Barranquero 2013-12-21 17:15 ` martin rudalics 2013-12-21 18:46 ` Eli Zaretskii 2013-12-21 16:56 ` Drew Adams 1 sibling, 2 replies; 28+ messages in thread From: Juanma Barranquero @ 2013-12-21 16:53 UTC (permalink / raw) To: Drew Adams; +Cc: 16207 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) ^ permalink raw reply [flat|nested] 28+ messages in thread
* bug#16207: 24.3.50; emacs_backtrace.txt 2013-12-21 16:53 ` Juanma Barranquero @ 2013-12-21 17:15 ` martin rudalics 2013-12-21 18:31 ` martin rudalics 2013-12-21 18:45 ` Eli Zaretskii 2013-12-21 18:46 ` Eli Zaretskii 1 sibling, 2 replies; 28+ messages in thread From: martin rudalics @ 2013-12-21 17:15 UTC (permalink / raw) To: Juanma Barranquero; +Cc: 16207 > 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 ^ permalink raw reply [flat|nested] 28+ messages in thread
* bug#16207: 24.3.50; emacs_backtrace.txt 2013-12-21 17:15 ` martin rudalics @ 2013-12-21 18:31 ` martin rudalics 2013-12-21 18:58 ` Eli Zaretskii 2013-12-21 18:45 ` Eli Zaretskii 1 sibling, 1 reply; 28+ messages in thread From: martin rudalics @ 2013-12-21 18:31 UTC (permalink / raw) To: Juanma Barranquero; +Cc: 16207 > > 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 ^ permalink raw reply [flat|nested] 28+ messages in thread
* bug#16207: 24.3.50; emacs_backtrace.txt 2013-12-21 18:31 ` martin rudalics @ 2013-12-21 18:58 ` Eli Zaretskii 2013-12-21 19:40 ` martin rudalics 0 siblings, 1 reply; 28+ messages in thread From: Eli Zaretskii @ 2013-12-21 18:58 UTC (permalink / raw) To: martin rudalics; +Cc: lekktu, 16207 > Date: Sat, 21 Dec 2013 19:31:47 +0100 > From: martin rudalics <rudalics@gmx.at> > Cc: 16207@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. ^ permalink raw reply [flat|nested] 28+ messages in thread
* bug#16207: 24.3.50; emacs_backtrace.txt 2013-12-21 18:58 ` Eli Zaretskii @ 2013-12-21 19:40 ` martin rudalics 0 siblings, 0 replies; 28+ messages in thread From: martin rudalics @ 2013-12-21 19:40 UTC (permalink / raw) To: Eli Zaretskii; +Cc: lekktu, 16207 >> 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 ^ permalink raw reply [flat|nested] 28+ messages in thread
* bug#16207: 24.3.50; emacs_backtrace.txt 2013-12-21 17:15 ` martin rudalics 2013-12-21 18:31 ` martin rudalics @ 2013-12-21 18:45 ` Eli Zaretskii 2013-12-21 19:58 ` martin rudalics 1 sibling, 1 reply; 28+ messages in thread From: Eli Zaretskii @ 2013-12-21 18:45 UTC (permalink / raw) To: martin rudalics; +Cc: lekktu, 16207 > Date: Sat, 21 Dec 2013 18:15:14 +0100 > From: martin rudalics <rudalics@gmx.at> > Cc: 16207@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? ^ permalink raw reply [flat|nested] 28+ messages in thread
* bug#16207: 24.3.50; emacs_backtrace.txt 2013-12-21 18:45 ` Eli Zaretskii @ 2013-12-21 19:58 ` martin rudalics 2013-12-21 20:10 ` Eli Zaretskii 2013-12-22 15:37 ` martin rudalics 0 siblings, 2 replies; 28+ messages in thread From: martin rudalics @ 2013-12-21 19:58 UTC (permalink / raw) To: Eli Zaretskii; +Cc: lekktu, 16207 > 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 ^ permalink raw reply [flat|nested] 28+ messages in thread
* bug#16207: 24.3.50; emacs_backtrace.txt 2013-12-21 19:58 ` martin rudalics @ 2013-12-21 20:10 ` Eli Zaretskii 2013-12-22 15:37 ` martin rudalics 1 sibling, 0 replies; 28+ messages in thread From: Eli Zaretskii @ 2013-12-21 20:10 UTC (permalink / raw) To: martin rudalics; +Cc: lekktu, 16207 > Date: Sat, 21 Dec 2013 20:58:49 +0100 > From: martin rudalics <rudalics@gmx.at> > CC: lekktu@gmail.com, 16207@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. ^ permalink raw reply [flat|nested] 28+ messages in thread
* bug#16207: 24.3.50; emacs_backtrace.txt 2013-12-21 19:58 ` martin rudalics 2013-12-21 20:10 ` Eli Zaretskii @ 2013-12-22 15:37 ` martin rudalics 2013-12-22 15:39 ` Juanma Barranquero ` (2 more replies) 1 sibling, 3 replies; 28+ messages in thread From: martin rudalics @ 2013-12-22 15:37 UTC (permalink / raw) To: Eli Zaretskii; +Cc: lekktu, Chong Yidong, 16207 > 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 ^ permalink raw reply [flat|nested] 28+ messages in thread
* bug#16207: 24.3.50; emacs_backtrace.txt 2013-12-22 15:37 ` martin rudalics @ 2013-12-22 15:39 ` Juanma Barranquero 2013-12-23 18:44 ` martin rudalics 2013-12-23 5:37 ` Drew Adams 2013-12-23 16:24 ` Eli Zaretskii 2 siblings, 1 reply; 28+ messages in thread From: Juanma Barranquero @ 2013-12-22 15:39 UTC (permalink / raw) To: martin rudalics; +Cc: 16207 On Sun, Dec 22, 2013 at 4:37 PM, martin rudalics <rudalics@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 ^ permalink raw reply [flat|nested] 28+ messages in thread
* bug#16207: 24.3.50; emacs_backtrace.txt 2013-12-22 15:39 ` Juanma Barranquero @ 2013-12-23 18:44 ` martin rudalics 0 siblings, 0 replies; 28+ messages in thread From: martin rudalics @ 2013-12-23 18:44 UTC (permalink / raw) To: Juanma Barranquero; +Cc: 16207 > I'm bootstrapping a new binary for Drew to try, it'll be up ASAP. Belated thanks. martin ^ permalink raw reply [flat|nested] 28+ messages in thread
* bug#16207: 24.3.50; emacs_backtrace.txt 2013-12-22 15:37 ` martin rudalics 2013-12-22 15:39 ` Juanma Barranquero @ 2013-12-23 5:37 ` Drew Adams 2014-01-04 14:12 ` martin rudalics 2013-12-23 16:24 ` Eli Zaretskii 2 siblings, 1 reply; 28+ messages in thread From: Drew Adams @ 2013-12-23 5:37 UTC (permalink / raw) To: martin rudalics, Eli Zaretskii; +Cc: lekktu, Chong Yidong, 16207 > 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@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' ^ permalink raw reply [flat|nested] 28+ messages in thread
* bug#16207: 24.3.50; emacs_backtrace.txt 2013-12-23 5:37 ` Drew Adams @ 2014-01-04 14:12 ` martin rudalics 0 siblings, 0 replies; 28+ messages in thread From: martin rudalics @ 2014-01-04 14:12 UTC (permalink / raw) To: Drew Adams; +Cc: lekktu, Chong Yidong, 16207-done > I tested with this version, and it seems to be fixed. Thx. Bug closed. Thanks, martin ^ permalink raw reply [flat|nested] 28+ messages in thread
* bug#16207: 24.3.50; emacs_backtrace.txt 2013-12-22 15:37 ` martin rudalics 2013-12-22 15:39 ` Juanma Barranquero 2013-12-23 5:37 ` Drew Adams @ 2013-12-23 16:24 ` Eli Zaretskii 2013-12-23 18:44 ` martin rudalics 2 siblings, 1 reply; 28+ messages in thread From: Eli Zaretskii @ 2013-12-23 16:24 UTC (permalink / raw) To: martin rudalics; +Cc: lekktu, cyd, 16207 > Date: Sun, 22 Dec 2013 16:37:36 +0100 > From: martin rudalics <rudalics@gmx.at> > CC: lekktu@gmail.com, 16207@debbugs.gnu.org, Chong Yidong <cyd@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. ^ permalink raw reply [flat|nested] 28+ messages in thread
* bug#16207: 24.3.50; emacs_backtrace.txt 2013-12-23 16:24 ` Eli Zaretskii @ 2013-12-23 18:44 ` martin rudalics 0 siblings, 0 replies; 28+ messages in thread From: martin rudalics @ 2013-12-23 18:44 UTC (permalink / raw) To: Eli Zaretskii; +Cc: lekktu, cyd, 16207 > 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 ^ permalink raw reply [flat|nested] 28+ messages in thread
* bug#16207: 24.3.50; emacs_backtrace.txt 2013-12-21 16:53 ` Juanma Barranquero 2013-12-21 17:15 ` martin rudalics @ 2013-12-21 18:46 ` Eli Zaretskii 2013-12-21 18:50 ` Juanma Barranquero 2013-12-21 18:59 ` Eli Zaretskii 1 sibling, 2 replies; 28+ messages in thread From: Eli Zaretskii @ 2013-12-21 18:46 UTC (permalink / raw) To: Juanma Barranquero; +Cc: 16207 > From: Juanma Barranquero <lekktu@gmail.com> > Date: Sat, 21 Dec 2013 17:53:29 +0100 > Cc: Eli Zaretskii <eliz@gnu.org>, 16207@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? ^ permalink raw reply [flat|nested] 28+ messages in thread
* bug#16207: 24.3.50; emacs_backtrace.txt 2013-12-21 18:46 ` Eli Zaretskii @ 2013-12-21 18:50 ` Juanma Barranquero 2013-12-21 18:52 ` Juanma Barranquero 2013-12-21 18:59 ` Eli Zaretskii 1 sibling, 1 reply; 28+ messages in thread From: Juanma Barranquero @ 2013-12-21 18:50 UTC (permalink / raw) To: Eli Zaretskii; +Cc: 16207 On Sat, Dec 21, 2013 at 7:46 PM, Eli Zaretskii <eliz@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) ^ permalink raw reply [flat|nested] 28+ messages in thread
* bug#16207: 24.3.50; emacs_backtrace.txt 2013-12-21 18:50 ` Juanma Barranquero @ 2013-12-21 18:52 ` Juanma Barranquero 0 siblings, 0 replies; 28+ messages in thread From: Juanma Barranquero @ 2013-12-21 18:52 UTC (permalink / raw) To: Eli Zaretskii; +Cc: 16207 On Sat, Dec 21, 2013 at 7:50 PM, Juanma Barranquero <lekktu@gmail.com> wrote: > Lisp_Symbol nil, BTW J ^ permalink raw reply [flat|nested] 28+ messages in thread
* bug#16207: 24.3.50; emacs_backtrace.txt 2013-12-21 18:46 ` Eli Zaretskii 2013-12-21 18:50 ` Juanma Barranquero @ 2013-12-21 18:59 ` Eli Zaretskii 1 sibling, 0 replies; 28+ messages in thread From: Eli Zaretskii @ 2013-12-21 18:59 UTC (permalink / raw) To: Eli Zaretskii; +Cc: lekktu, 16207 > Date: Sat, 21 Dec 2013 20:46:25 +0200 > From: Eli Zaretskii <eliz@gnu.org> > Cc: 16207@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. ^ permalink raw reply [flat|nested] 28+ messages in thread
* bug#16207: 24.3.50; emacs_backtrace.txt 2013-12-21 16:27 ` Drew Adams 2013-12-21 16:53 ` Juanma Barranquero @ 2013-12-21 16:56 ` Drew Adams 1 sibling, 0 replies; 28+ messages in thread From: Drew Adams @ 2013-12-21 16:56 UTC (permalink / raw) To: Eli Zaretskii; +Cc: 16207 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 ^ permalink raw reply [flat|nested] 28+ messages in thread
end of thread, other threads:[~2014-01-04 14:12 UTC | newest]
Thread overview: 28+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2013-12-20 21:38 bug#16207: 24.3.50; emacs_backtrace.txt Drew Adams
2013-12-20 21:53 ` Drew Adams
2013-12-21 9:46 ` Eli Zaretskii
2013-12-20 22:41 ` Juanma Barranquero
2013-12-21 9:38 ` Eli Zaretskii
[not found] <<efed9c40-3985-45be-81fd-22e7f8912725@default>
[not found] ` <<83fvpma6ie.fsf@gnu.org>
2013-12-21 16:22 ` Drew Adams
2013-12-21 18:38 ` Eli Zaretskii
[not found] ` <<fce2b6f2-11f6-400f-8ac6-382ab9a9d9bb@default>
[not found] ` <<83eh56a64m.fsf@gnu.org>
2013-12-21 16:27 ` Drew Adams
2013-12-21 16:53 ` Juanma Barranquero
2013-12-21 17:15 ` martin rudalics
2013-12-21 18:31 ` martin rudalics
2013-12-21 18:58 ` Eli Zaretskii
2013-12-21 19:40 ` martin rudalics
2013-12-21 18:45 ` Eli Zaretskii
2013-12-21 19:58 ` martin rudalics
2013-12-21 20:10 ` Eli Zaretskii
2013-12-22 15:37 ` martin rudalics
2013-12-22 15:39 ` Juanma Barranquero
2013-12-23 18:44 ` martin rudalics
2013-12-23 5:37 ` Drew Adams
2014-01-04 14:12 ` martin rudalics
2013-12-23 16:24 ` Eli Zaretskii
2013-12-23 18:44 ` martin rudalics
2013-12-21 18:46 ` Eli Zaretskii
2013-12-21 18:50 ` Juanma Barranquero
2013-12-21 18:52 ` Juanma Barranquero
2013-12-21 18:59 ` Eli Zaretskii
2013-12-21 16:56 ` Drew Adams
Code repositories for project(s) associated with this public inbox https://git.savannah.gnu.org/cgit/emacs.git This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).