* bug#10169: a simple interrupt evokes abort?! (but only with (require 'saveplace)) @ 2011-11-30 12:24 Jim Meyering 2011-12-01 16:03 ` Paul Eggert ` (2 more replies) 0 siblings, 3 replies; 21+ messages in thread From: Jim Meyering @ 2011-11-30 12:24 UTC (permalink / raw) To: 10169 When I edit any file and interrupt emacs, I get an abort, in src/eval.c: if (gc_in_progress || waiting_for_input) abort (); waiting_for_input is 1. However, that happens only when using my .emacs file. When I use -q, e.g., "touch /tmp/x; emacs -q /tmp/x" there is no abort. Bisecting ~/.emacs, I found the culprit: (require 'saveplace) without that line, there is no problem. So anyone can reproduce it by running this and then hitting ^C: $ touch /tmp/k; emacs -q --eval "(require 'saveplace)" /tmp/k ^CFatal error (6)zsh: abort (core dumped) emacs -q --eval "(require\ 'saveplace)" /tmp/k [Exit 134 (ABRT)] ^ permalink raw reply [flat|nested] 21+ messages in thread
* bug#10169: a simple interrupt evokes abort?! (but only with (require 'saveplace)) 2011-11-30 12:24 bug#10169: a simple interrupt evokes abort?! (but only with (require 'saveplace)) Jim Meyering @ 2011-12-01 16:03 ` Paul Eggert 2011-12-01 16:13 ` Jim Meyering 2011-12-01 19:25 ` Stefan Monnier 2011-12-03 20:21 ` Glenn Morris 2 siblings, 1 reply; 21+ messages in thread From: Paul Eggert @ 2011-12-01 16:03 UTC (permalink / raw) To: Jim Meyering; +Cc: 10169 > So anyone can reproduce it by running this and then hitting ^C: > $ touch /tmp/k; emacs -q --eval "(require 'saveplace)" /tmp/k > ^CFatal error (6)zsh: abort (core dumped) emacs -q --eval "(require\ > 'saveplace)" /tmp/k > [Exit 134 (ABRT)] Unfortunately I can't reproduce this problem, with either Fedora 15 Emacs or with the latest trunk (built with GCC 4.6.2, x86-64). Which version of Emacs and which platform are you using? Can you send a GDB backtrace? Assuming it's the trunk, it's helpful to compile without optimization when getting a backtrace. ^ permalink raw reply [flat|nested] 21+ messages in thread
* bug#10169: a simple interrupt evokes abort?! (but only with (require 'saveplace)) 2011-12-01 16:03 ` Paul Eggert @ 2011-12-01 16:13 ` Jim Meyering 2011-12-01 18:09 ` Glenn Morris 0 siblings, 1 reply; 21+ messages in thread From: Jim Meyering @ 2011-12-01 16:13 UTC (permalink / raw) To: Paul Eggert; +Cc: 10169 Paul Eggert wrote: >> So anyone can reproduce it by running this and then hitting ^C: >> $ touch /tmp/k; emacs -q --eval "(require 'saveplace)" /tmp/k >> ^CFatal error (6)zsh: abort (core dumped) emacs -q --eval "(require\ >> 'saveplace)" /tmp/k >> [Exit 134 (ABRT)] > > Unfortunately I can't reproduce this problem, with either Fedora 15 Emacs > or with the latest trunk (built with GCC 4.6.2, x86-64). Which version of > Emacs and which platform are you using? Can you send a GDB backtrace? > Assuming it's the trunk, it's helpful to compile without optimization > when getting a backtrace. Hi Paul, It was with the latest emacs from bzr (some time yesterday), built on Fedora 16 using gcc-4.7.0 20111124. If I find time today, I'll narrow it down or post a backtrace. ^ permalink raw reply [flat|nested] 21+ messages in thread
* bug#10169: a simple interrupt evokes abort?! (but only with (require 'saveplace)) 2011-12-01 16:13 ` Jim Meyering @ 2011-12-01 18:09 ` Glenn Morris 2011-12-01 18:42 ` Andreas Schwab 2011-12-02 0:34 ` Dan Nicolaescu 0 siblings, 2 replies; 21+ messages in thread From: Glenn Morris @ 2011-12-01 18:09 UTC (permalink / raw) To: Jim Meyering; +Cc: Paul Eggert, 10169 I can reproduce it on Scientific Linux 6.1, x86_64, with gcc 4.4.5 20110214 (Red Hat 4.4.5-6). Backtrace: #0 abort () at emacs.c:386 No locals. #1 0x00000000005f7e51 in Fsignal (error_symbol=12961906, data=19014854) at eval.c:1662 conditions = 15231761 string = 19738512 real_error_symbol = 12961906 clause = 12777890 h = 0x12224b6 bp = 0xe86b11 #2 0x00000000005f81ba in xsignal (error_symbol=12961906, data=19014854) at eval.c:1758 No locals. #3 0x00000000005f8289 in xsignal3 (error_symbol=12961906, arg1=15231761, arg2= 208, arg3=212) at eval.c:1785 No locals. #4 0x000000000063ad86 in scan_lists (from=15231761, count=1, depth=-2, sexpflag=0) at syntax.c:2607 comstart_first = 0 prefix = 0 syntax = 5 other_syntax = 0 val = 12 stop = 212 c = 208 c1 = 208 stringterm = 34 quoted = 112 mathexit = 0 ---Type <return> to continue, or q <return> to quit--- code = Sclose temp_code = 208 min_depth = -1 comstyle = 0 comnested = 0 temp_pos = 3 last_good = 52 found = 0 from_byte = 53 out_bytepos = 140737488295520 out_charpos = 47 temp = 2 dummy = 0 multibyte_symbol_p = 0 #5 0x000000000063e831 in Fscan_lists (from=12, count=4, depth=-4) at syntax.c:2865 No locals. #6 0x00000000005fad2a in Ffuncall (nargs=4, args=0x7fffffff19b0) at eval.c:2981 fun = 12160837 original_fun = 12963634 funcar = 4 numargs = 3 lisp_numargs = 13226320 val = 12777890 backtrace = { next = 0x7fffffff1e00, function = 0x7fffffff19b0, args = 0x7fffffff19b8, ---Type <return> to continue, or q <return> to quit--- nargs = 3, debug_on_exit = 0 } internal_args = 0x7fffffff19b8 i = 140737488296352 #7 0x0000000000647ae4 in exec_byte_code (bytestr=10875017, vector=10875053, maxdepth=20, args_template=12777890, nargs=0, args=0x0) at bytecode.c:785 count = 14 op = 3 vectorp = 0xa5f0b8 stack = { pc = 0xb21096 "\206$", byte_string = 10875017, byte_string_start = 0xb21078 "\b\204\006", constants = 10875053, next = 0x7fffffff1ef0 } top = 0x7fffffff19b0 result = 12777890 #8 0x00000000005fb742 in funcall_lambda (fun=10874957, nargs=1, arg_vector= 0xa5f0ad) at eval.c:3205 val = 12777890 syms_left = 12777890 next = 13184898 lexenv = 12777890 count = 13 i = 1 optional = 1 rest = 0 ---Type <return> to continue, or q <return> to quit--- #9 0x00000000005faee6 in Ffuncall (nargs=2, args=0x7fffffff1e98) at eval.c:3023 fun = 10874957 original_fun = 13178802 funcar = 1 numargs = 1 lisp_numargs = 4294967295 val = 12777890 backtrace = { next = 0x7fffffff2330, function = 0x7fffffff1e98, args = 0x7fffffff1ea0, nargs = 1, debug_on_exit = 0 } internal_args = 0xfec0f5 i = 140737488297424 #10 0x0000000000647ae4 in exec_byte_code (bytestr=17578657, vector=16695541, maxdepth=12, args_template=12777890, nargs=0, args=0x0) at bytecode.c:785 count = 13 op = 1 vectorp = 0xfec100 stack = { pc = 0x12d1f04 "\210\207", byte_string = 17578657, byte_string_start = 0x12d1f00 "ÀÁÂ!\210\207", constants = 16695541, next = 0x7fffffff25d0 } ---Type <return> to continue, or q <return> to quit--- top = 0x7fffffff1e98 result = 12777938 #11 0x0000000000646f63 in Fbyte_code (bytestr=17578657, vector=16695541, maxdepth=12) at bytecode.c:423 No locals. #12 0x00000000005f9670 in eval_sub (form=18964262) at eval.c:2328 numargs = 12 args_left = 12777890 i = 6582052 maxargs = 3 argvals = {17578657, 16695541, 12, 44, 0, 6266547, 140737488298864, 1} fun = 12161029 val = 3 original_fun = 12917730 original_args = 18964278 funcar = 3 backtrace = { next = 0x7fffffff29b0, function = 0x7fffffff2360, args = 0x7fffffff2290, nargs = 3, debug_on_exit = 0 ---Type <return> to continue, or q <return> to quit--- } gcpro1 = { next = 0xd, var = 0xe86ab1, nvars = 140737488299072 } gcpro2 = { next = 0x7fffffff2440, var = 0x600bc1, nvars = 48 } gcpro3 = { next = 0xd, var = 0x7fffffff2290, nvars = 3 } #13 0x00000000005f77c2 in internal_lisp_condition_case (var=16146594, bodyform= 18964262, handlers=18964358) at eval.c:1453 val = 12777890 c = { tag = 12777890, val = 12777890, next = 0x7fffffff52f0, gcpro = 0x0, jmp = {{ __jmpbuf = {448, -8826069716758269337, 0, 140737488312912, ---Type <return> to continue, or q <return> to quit--- 0, 0, -8826069716840058265, 8826069120708014695}, __mask_was_saved = 0, __saved_mask = { __val = {12777890, 12777890, 5853900, 140737488299360, 6274425, 12777890, 55851513923, 12777890, 19014806, 6190615, 0, 2, 2, 15226369, 15226368, 15226368} } }}, backlist = 0x7fffffff29b0, handlerlist = 0x7fffffff52c0, lisp_eval_depth = 5, pdlcount = 13, poll_suppress_count = 1, ---Type <return> to continue, or q <return> to quit--- interrupt_input_blocked = 0, byte_stack = 0x7fffffff25d0 } h = { handler = 18964358, var = 16146594, chosen_clause = 140737488299200, tag = 0x7fffffff2440, next = 0x7fffffff52c0 } #14 0x0000000000648862 in exec_byte_code (bytestr=17578561, vector=16797397, maxdepth=12, args_template=12777890, nargs=0, args=0x0) at bytecode.c:981 handlers = 18964358 body = 18964262 count = 13 op = 143 vectorp = 0x1004ee0 stack = { pc = 0x12d1e7b "\203\061", byte_string = 17578561, byte_string_start = 0x12d1e70 "eb\210m\204X", constants = 16797397, next = 0x7fffffff2aa0 } top = 0x7fffffff2570 result = 18960278 #15 0x00000000005fb742 in funcall_lambda (fun=16797749, nargs=0, arg_vector= 0x1004ed5) at eval.c:3205 val = 12777890 ---Type <return> to continue, or q <return> to quit--- syms_left = 12777890 next = 480 lexenv = 12777890 count = 13 i = 0 optional = 0 rest = 0 #16 0x00000000005faee6 in Ffuncall (nargs=1, args=0x7fffffff2a40) at eval.c:3023 fun = 16797749 original_fun = 14562050 funcar = 12777938 numargs = 0 lisp_numargs = 12897104 val = 12777890 backtrace = { next = 0x7fffffff2e80, function = 0x7fffffff2a40, args = 0x7fffffff2a48, nargs = 0, debug_on_exit = 0 } internal_args = 0x1e0 i = 140737488300592 #17 0x0000000000647ae4 in exec_byte_code (bytestr=17581121, vector=18085877, maxdepth=12, args_template=12777890, nargs=0, args=0x0) at bytecode.c:785 count = 11 op = 0 vectorp = 0x113f800 ---Type <return> to continue, or q <return> to quit--- stack = { pc = 0x12d1c74 "\210Î *\207", byte_string = 17581121, byte_string_start = 0x12d1c58 "rÅÆ!q\210Ç\216ÈÉ!\210Ê\b!\210\tË\032\033Ì\fp\"\210*Í \210Î *\207", constants = 18085877, next = 0x7fffffff2f70 } top = 0x7fffffff2a40 result = 13489890 #18 0x00000000005fb742 in funcall_lambda (fun=17184725, nargs=1, arg_vector= 0x113f7f5) at eval.c:3205 val = 42962450898 syms_left = 12777890 next = 13006258 lexenv = 12777890 count = 10 i = 1 optional = 0 rest = 0 #19 0x00000000005faee6 in Ffuncall (nargs=2, args=0x7fffffff2f18) at eval.c:3023 fun = 17184725 original_fun = 14562002 funcar = 12777890 numargs = 1 lisp_numargs = 1 val = 0 ---Type <return> to continue, or q <return> to quit--- backtrace = { next = 0x7fffffff3350, function = 0x7fffffff2f18, args = 0x7fffffff2f20, nargs = 1, debug_on_exit = 0 } internal_args = 0x10050b5 i = 140737488301840 #20 0x0000000000647ae4 in exec_byte_code (bytestr=16796577, vector=16797877, maxdepth=12, args_template=12777890, nargs=0, args=0x0) at bytecode.c:785 count = 10 op = 1 vectorp = 0x10050c0 stack = { pc = 0x12d2084 "\t\206\t", byte_string = 16796577, byte_string_start = 0x12d2080 "ÃÄ\b!\t\206\t", constants = 16797877, next = 0x7fffffff3440 } top = 0x7fffffff2f18 result = 6267955 #21 0x00000000005fb742 in funcall_lambda (fun=18065669, nargs=2, arg_vector= 0x10050b5) at eval.c:3205 val = 0 syms_left = 12777890 next = 16146642 lexenv = 12777890 ---Type <return> to continue, or q <return> to quit--- count = 8 i = 2 optional = 1 rest = 0 #22 0x00000000005faee6 in Ffuncall (nargs=3, args=0x7fffffff33e0) at eval.c:3023 fun = 18065669 original_fun = 14562098 funcar = 12898242 numargs = 2 lisp_numargs = 12897008 val = 14176790 backtrace = { next = 0x7fffffff3820, function = 0x7fffffff33e0, args = 0x7fffffff33e8, nargs = 2, debug_on_exit = 0 } internal_args = 0x10337c5 i = 140737488303056 #23 0x0000000000647ae4 in exec_byte_code (bytestr=17434609, vector=16988101, maxdepth=16, args_template=12777890, nargs=0, args=0x0) at bytecode.c:785 count = 3 op = 2 vectorp = 0x10337d0 stack = { pc = 0x1029aab "\210*\016\030\204\066", byte_string = 17434609, ---Type <return> to continue, or q <return> to quit--- byte_string_start = 0x1029a80 "Æ\b!Ç\031\032rÈÉ!q\210ed|\210\v\203\027", constants = 16988101, next = 0x7fffffff3900 } top = 0x7fffffff33e0 result = 12777890 #24 0x00000000005fb742 in funcall_lambda (fun=14360165, nargs=0, arg_vector= 0x10337c5) at eval.c:3205 val = 12777890 syms_left = 12777890 next = 19269826 lexenv = 12777890 count = 3 i = 0 optional = 0 rest = 0 #25 0x00000000005faee6 in Ffuncall (nargs=1, args=0x7fffffff38b0) at eval.c:3023 fun = 14360165 original_fun = 16146258 funcar = 10783013 numargs = 0 lisp_numargs = 12026631 val = 12777890 backtrace = { next = 0x7fffffff3ce0, function = 0x7fffffff38b0, args = 0x7fffffff38b8, ---Type <return> to continue, or q <return> to quit--- nargs = 0, debug_on_exit = 0 } internal_args = 0x102daf5 i = 12026624 #26 0x0000000000647ae4 in exec_byte_code (bytestr=16765873, vector=16964341, maxdepth=4, args_template=12777890, nargs=0, args=0x0) at bytecode.c:785 count = 3 op = 0 vectorp = 0x102db00 stack = { pc = 0x102a319 "\207", byte_string = 16765873, byte_string_start = 0x102a310 "Á \210\b\205\t", constants = 16964341, next = 0x0 } top = 0x7fffffff38b0 result = 12777938 #27 0x00000000005fb742 in funcall_lambda (fun=16693349, nargs=0, arg_vector= 0x102daf5) at eval.c:3205 val = 140737488305640 syms_left = 12777890 next = 140737340148088 lexenv = 12777890 count = 3 i = 0 optional = 0 rest = 0 ---Type <return> to continue, or q <return> to quit--- #28 0x00000000005faee6 in Ffuncall (nargs=1, args=0x7fffffff3e50) at eval.c:3023 fun = 16693349 original_fun = 16146450 funcar = 0 numargs = 0 lisp_numargs = 12777890 val = 20 backtrace = { next = 0x0, function = 0x7fffffff3e50, args = 0x7fffffff3e58, nargs = 0, debug_on_exit = 0 } internal_args = 0x7ffff70a09a0 i = 10784509 #29 0x00000000005f9ed6 in funcall_nil (nargs=1, args=0x7fffffff3e50) at eval.c:2491 No locals. #30 0x00000000005fa2e7 in run_hook_with_args (nargs=1, args=0x7fffffff3e50, funcall=0x5f9eb3 <funcall_nil>) at eval.c:2680 global_vals = 12777890 sym = 12940338 val = 13947622 ret = 12777890 gcpro1 = { next = 0x126c852, var = 0x7ffff70a09a0, ---Type <return> to continue, or q <return> to quit--- nvars = 7032063 } gcpro2 = { next = 0xf, var = 0xc2c9e5, nvars = 820 } gcpro3 = { next = 0x7fffffff3e10, var = 0x62aeb8, nvars = 0 } #31 0x00000000005f9f22 in Frun_hooks (nargs=1, args=0x7fffffff3e88) at eval.c:2518 hook = {16146450} i = 0 #32 0x00000000005573f1 in Fkill_emacs (arg=12777890) at emacs.c:2005 gcpro1 = { next = 0xa48fd6, var = 0x6b6f2d, nvars = 4294917824 } hook = 12940338 exit_code = 0 #33 0x000000000056d52a in interrupt_signal (signalnum=2) at keyboard.c:10862 old_errno = 11 terminal = 0x0 #34 <signal handler called> No symbol table info available. ---Type <return> to continue, or q <return> to quit--- #35 0x000000366b8de363 in __select_nocancel () from /lib64/libc.so.6 No symbol table info available. #36 0x0000000000652a14 in select_wrapper (n=8, rfd=0x7fffffff4660, wfd= 0x7fffffff45e0, xfd=0x0, tmo=0x7fffffff45c0) at process.c:4245 No locals. #37 0x0000000000653b1e in wait_reading_process_output (time_limit=0, microsecs= 0, read_kbd=-1, do_display=1, wait_for_cell=12777890, wait_proc=0x0, just_wait_proc=0) at process.c:4611 timeout_reduced_for_timers = 1 channel = -47520 nfds = 0 Available = { fds_bits = {128, 0 <repeats 15 times>} } Writeok = { fds_bits = {0 <repeats 16 times>} } check_write = 1 check_delay = 0 no_avail = 0 xerrno = 11 proc = 0 timeout = { tv_sec = 0, tv_usec = 473112 } end_time = { tv_sec = 0, ---Type <return> to continue, or q <return> to quit--- tv_usec = 0 } wait_channel = -1 got_some_input = 1 count = 2 #38 0x000000000055eac0 in kbd_buffer_get_event (kbp=0x7fffffff4990, used_mouse_menu=0x7fffffff4ec4, end_time=0x0) at keyboard.c:3850 c = 2 obj = 4294967296 #39 0x000000000055c67b in read_char (commandflag=1, nmaps=2, maps= 0x7fffffff4ce0, prev_event=12777890, used_mouse_menu=0x7fffffff4ec4, end_time=0x0) at keyboard.c:2796 kb = 0x0 c = 12777890 jmpcount = 2 local_getcjmp = {{ __jmpbuf = {2, -8826069719702670745, 4261152, 140737488312912, 0, 0, -8826069719851568537, 8826069075804582503}, __mask_was_saved = 0, __saved_mask = { __val = {66, 18446744073709551615, 4294967294, ---Type <return> to continue, or q <return> to quit--- 0, 0, 0, 0, 0, 0, 46, 0, 12777890, 12777890, 12777890, 12777890, 12777890} } }} save_jump = {{ __jmpbuf = {0, 0, 0, 0, 0, 0, 0, 0}, __mask_was_saved = 0, __saved_mask = { __val = {0 <repeats 16 times>} } }} ---Type <return> to continue, or q <return> to quit--- key_already_recorded = 0 tem = 12811970 save = 140737488309296 previous_echo_area_message = 12777890 also_record = 12777890 reread = 0 gcpro1 = { next = 0x7fffffff4bf0, var = 0x7fffffff4bf8, nvars = 140737488308752 } gcpro2 = { next = 0x0, var = 0x7fffffff4a18, nvars = 12777890 } polling_stopped_here = 1 orig_kboard = 0x12b0150 #40 0x0000000000569c32 in read_key_sequence (keybuf=0x7fffffff5130, bufsize= 30, prompt=12777890, dont_downcase_last=0, can_return_switch_frame=1, fix_current_buffer=1) at keyboard.c:9290 interrupted_kboard = 0x12b0150 interrupted_frame = 0xff3700 key = 16908133 used_mouse_menu = 0 echo_local_start = 0 last_real_key_start = 0 keys_local_start = 0 local_first_binding = 1 ---Type <return> to continue, or q <return> to quit--- from_string = 12777890 count = 2 t = 0 echo_start = 0 keys_start = 0 nmaps = 2 nmaps_allocated = 2 defs = 0x7fffffff4cc0 submaps = 0x7fffffff4ce0 orig_local_map = 12777890 orig_keymap = 12777890 localized_local_map = 0 first_binding = 1 first_unbound = 31 mock_input = 0 fkey = { parent = 18294934, map = 18294934, start = 0, end = 0 } keytran = { parent = 12757414, map = 12757414, start = 0, end = 0 } indec = { parent = 18294950, ---Type <return> to continue, or q <return> to quit--- map = 18294950, start = 0, end = 0 } shift_translated = 0 delayed_switch_frame = 12777890 original_uppercase = 12777938 original_uppercase_position = -1 dummyflag = 0 starting_buffer = 0xf5f2e0 fake_prefixed_keys = 12777890 gcpro1 = { next = 0x7fffffff4f00, var = 0x5ddf17, nvars = 0 } #41 0x00000000005599d2 in command_loop_1 () at keyboard.c:1447 cmd = 12899282 keybuf = {4261152, 140737488312912, 140737488310640, 6152116, 2822930839, 12777890, 0, 5, 140737488310720, 6154447, 12777890, ---Type <return> to continue, or q <return> to quit--- 12899282, 140737488310800, 12899280, 7, 12627840, 0, 140737488310752, 140737488310880, 6274735, 13356918, 8602712482, 12899282, 12777890, 0, 0, 4261152, 140737488312912, 140737488310880, 6274155} i = 12899280 prev_modiff = 0 prev_buffer = 0x0 already_adjusted = 0 #42 0x00000000005f792a in internal_condition_case (bfun= 0x5595e9 <command_loop_1>, handlers=12830082, hfun=0x558ed8 <cmd_error>) at eval.c:1499 val = 0 c = { tag = 12777890, ---Type <return> to continue, or q <return> to quit--- val = 12777890, next = 0x7fffffff5470, gcpro = 0x0, jmp = {{ __jmpbuf = {5, -8826069720493297049, 4261152, 140737488312912, 0, 0, -8826069720575085977, 8826069120765948519}, __mask_was_saved = 0, __saved_mask = { __val = {8826069120765948519, 0, 4294967295, 13307238, 1, 9389376, 0, 0, 0, 0, 233723453152, 1, 0, 16110896, 233731823104, ---Type <return> to continue, or q <return> to quit--- 16110896} } }}, backlist = 0x0, handlerlist = 0x0, lisp_eval_depth = 0, pdlcount = 2, poll_suppress_count = 1, interrupt_input_blocked = 0, byte_stack = 0x0 } h = { handler = 12830082, var = 12777890, chosen_clause = 12830082, tag = 0x7fffffff52f0, next = 0x0 } #43 0x00000000005592d8 in command_loop_2 (ignore=12777890) at keyboard.c:1158 val = 5 #44 0x00000000005f72b4 in internal_catch (tag=12825874, func= 0x5592b2 <command_loop_2>, arg=12777890) at eval.c:1256 c = { tag = 12825874, val = 12777890, next = 0x0, gcpro = 0x0, jmp = {{ __jmpbuf = {5, ---Type <return> to continue, or q <return> to quit--- -8826069720545725849, 4261152, 140737488312912, 0, 0, -8826069720484908441, 8826069120562786919}, __mask_was_saved = 0, __saved_mask = { __val = {6153416, 0, 4301645564, 0, 12777890, 13003840, 140737488311736, 14, 12805936, 12183296, 6151995, 140737488311696, 12777890, 4261152, 140737488312912, 140737488311712} } }}, backlist = 0x0, handlerlist = 0x0, ---Type <return> to continue, or q <return> to quit--- lisp_eval_depth = 0, pdlcount = 2, poll_suppress_count = 1, interrupt_input_blocked = 0, byte_stack = 0x0 } #45 0x000000000055928b in command_loop () at keyboard.c:1137 No locals. #46 0x0000000000558a1c in recursive_edit_1 () at keyboard.c:757 count = 1 val = 5606357 #47 0x0000000000558bbf in Frecursive_edit () at keyboard.c:821 count = 0 buffer = 12777890 #48 0x0000000000556d37 in main (argc=5, argv=0x7fffffff5a58) at emacs.c:1707 dummy = 233731852096 stack_bottom_variable = 0 '\000' do_initial_setlocale = 1 skip_args = 0 rlim = { rlim_cur = 33554432, rlim_max = 18446744073709551615 } no_loadup = 0 junk = 0x0 dname_arg = 0x0 ch_to_dir = 0x7ffff7526cf0 "@\024\"k6" Lisp Backtrace: "scan-lists" (0xffff19b8) "down-list" (0xffff1ea0) "byte-code" (0xffff2290) "pp-buffer" (0xffff2a48) "pp-to-string" (0xffff2f20) "pp" (0xffff33e8) "save-place-alist-to-file" (0xffff38b8) "save-place-kill-emacs-hook" (0xffff3e58) ^ permalink raw reply [flat|nested] 21+ messages in thread
* bug#10169: a simple interrupt evokes abort?! (but only with (require 'saveplace)) 2011-12-01 18:09 ` Glenn Morris @ 2011-12-01 18:42 ` Andreas Schwab 2011-12-01 19:00 ` Glenn Morris 2011-12-02 0:34 ` Dan Nicolaescu 1 sibling, 1 reply; 21+ messages in thread From: Andreas Schwab @ 2011-12-01 18:42 UTC (permalink / raw) To: Glenn Morris; +Cc: Paul Eggert, 10169-done, Jim Meyering Should be fixed now. Andreas. -- Andreas Schwab, schwab@linux-m68k.org GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different." ^ permalink raw reply [flat|nested] 21+ messages in thread
* bug#10169: a simple interrupt evokes abort?! (but only with (require 'saveplace)) 2011-12-01 18:42 ` Andreas Schwab @ 2011-12-01 19:00 ` Glenn Morris 2011-12-01 19:02 ` Glenn Morris 0 siblings, 1 reply; 21+ messages in thread From: Glenn Morris @ 2011-12-01 19:00 UTC (permalink / raw) To: Andreas Schwab; +Cc: Paul Eggert, 10169, Jim Meyering Now interrupts are silently ignored: bash> ./emacs -Q ctrl-C # in the shell just prints ^C. ^ permalink raw reply [flat|nested] 21+ messages in thread
* bug#10169: a simple interrupt evokes abort?! (but only with (require 'saveplace)) 2011-12-01 19:00 ` Glenn Morris @ 2011-12-01 19:02 ` Glenn Morris 2011-12-03 8:54 ` Andreas Schwab 0 siblings, 1 reply; 21+ messages in thread From: Glenn Morris @ 2011-12-01 19:02 UTC (permalink / raw) To: Andreas Schwab; +Cc: Paul Eggert, 10169, Jim Meyering Glenn Morris wrote: > Now interrupts are silently ignored: > > bash> ./emacs -Q > ctrl-C # in the shell > > just prints ^C. Correction, not silently ignored: Emacs prints "Quit" but is otherwise unaffected. ^ permalink raw reply [flat|nested] 21+ messages in thread
* bug#10169: a simple interrupt evokes abort?! (but only with (require 'saveplace)) 2011-12-01 19:02 ` Glenn Morris @ 2011-12-03 8:54 ` Andreas Schwab 2011-12-03 21:04 ` Dan Nicolaescu 0 siblings, 1 reply; 21+ messages in thread From: Andreas Schwab @ 2011-12-03 8:54 UTC (permalink / raw) To: Glenn Morris; +Cc: Paul Eggert, 10169, Jim Meyering Glenn Morris <rgm@gnu.org> writes: > Glenn Morris wrote: > >> Now interrupts are silently ignored: >> >> bash> ./emacs -Q >> ctrl-C # in the shell >> >> just prints ^C. > > Correction, not silently ignored: Emacs prints "Quit" but is otherwise > unaffected. IMHO this is the correct behaviour for an interactive programm. Andreas. -- Andreas Schwab, schwab@linux-m68k.org GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different." ^ permalink raw reply [flat|nested] 21+ messages in thread
* bug#10169: a simple interrupt evokes abort?! (but only with (require 'saveplace)) 2011-12-03 8:54 ` Andreas Schwab @ 2011-12-03 21:04 ` Dan Nicolaescu 2011-12-03 21:26 ` Andreas Schwab 0 siblings, 1 reply; 21+ messages in thread From: Dan Nicolaescu @ 2011-12-03 21:04 UTC (permalink / raw) To: Andreas Schwab; +Cc: Paul Eggert, 10169, Jim Meyering Andreas Schwab <schwab@linux-m68k.org> writes: > Glenn Morris <rgm@gnu.org> writes: > >> Glenn Morris wrote: >> >>> Now interrupts are silently ignored: >>> >>> bash> ./emacs -Q >>> ctrl-C # in the shell >>> >>> just prints ^C. >> >> Correction, not silently ignored: Emacs prints "Quit" but is otherwise >> unaffected. > > IMHO this is the correct behaviour for an interactive programm. Why do you think that and what other widely use programs can you name that have the same behavior? Why do you think that pretest is the right time to do such a change to a long available behavior, and why is it OK to do it with zero discussion? ^ permalink raw reply [flat|nested] 21+ messages in thread
* bug#10169: a simple interrupt evokes abort?! (but only with (require 'saveplace)) 2011-12-03 21:04 ` Dan Nicolaescu @ 2011-12-03 21:26 ` Andreas Schwab 2011-12-03 22:07 ` Dan Nicolaescu 0 siblings, 1 reply; 21+ messages in thread From: Andreas Schwab @ 2011-12-03 21:26 UTC (permalink / raw) To: Dan Nicolaescu; +Cc: Paul Eggert, 10169, Jim Meyering Dan Nicolaescu <dann@gnu.org> writes: > Why do you think that pretest is the right time to do such a change to a > long available behavior, and why is it OK to do it with zero discussion? It fixes a severe bug: it is fatal to run Lisp code in a signal handler. Andreas. -- Andreas Schwab, schwab@linux-m68k.org GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different." ^ permalink raw reply [flat|nested] 21+ messages in thread
* bug#10169: a simple interrupt evokes abort?! (but only with (require 'saveplace)) 2011-12-03 21:26 ` Andreas Schwab @ 2011-12-03 22:07 ` Dan Nicolaescu 2011-12-03 22:23 ` Andreas Schwab 0 siblings, 1 reply; 21+ messages in thread From: Dan Nicolaescu @ 2011-12-03 22:07 UTC (permalink / raw) To: Andreas Schwab; +Cc: Paul Eggert, 10169, Jim Meyering Andreas Schwab <schwab@linux-m68k.org> writes: > Dan Nicolaescu <dann@gnu.org> writes: > >> Why do you think that pretest is the right time to do such a change to a >> long available behavior, and why is it OK to do it with zero discussion? > > It fixes a severe bug: it is fatal to run Lisp code in a signal handler. How does that that justify introducing another severe bug: can't kill emacs using C-c (as it has always been possible ? ^ permalink raw reply [flat|nested] 21+ messages in thread
* bug#10169: a simple interrupt evokes abort?! (but only with (require 'saveplace)) 2011-12-03 22:07 ` Dan Nicolaescu @ 2011-12-03 22:23 ` Andreas Schwab 2011-12-03 22:46 ` Dan Nicolaescu 2011-12-04 2:08 ` Chong Yidong 0 siblings, 2 replies; 21+ messages in thread From: Andreas Schwab @ 2011-12-03 22:23 UTC (permalink / raw) To: Dan Nicolaescu; +Cc: Paul Eggert, 10169, Jim Meyering Dan Nicolaescu <dann@gnu.org> writes: > How does that that justify introducing another severe bug: can't kill > emacs using C-c (as it has always been possible ? C-c in an interactive shell doesn't kill it either. Andreas. -- Andreas Schwab, schwab@linux-m68k.org GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different." ^ permalink raw reply [flat|nested] 21+ messages in thread
* bug#10169: a simple interrupt evokes abort?! (but only with (require 'saveplace)) 2011-12-03 22:23 ` Andreas Schwab @ 2011-12-03 22:46 ` Dan Nicolaescu 2011-12-03 22:53 ` Daniel Colascione 2011-12-04 2:08 ` Chong Yidong 1 sibling, 1 reply; 21+ messages in thread From: Dan Nicolaescu @ 2011-12-03 22:46 UTC (permalink / raw) To: Andreas Schwab; +Cc: Paul Eggert, 10169, Jim Meyering Andreas Schwab <schwab@linux-m68k.org> writes: > Dan Nicolaescu <dann@gnu.org> writes: > >> How does that that justify introducing another severe bug: can't kill >> emacs using C-c (as it has always been possible ? > > C-c in an interactive shell doesn't kill it either. What's the similarity between emacs as an X11 application and an interactive shell? And again, how do you justify changing a long time behavior? ^ permalink raw reply [flat|nested] 21+ messages in thread
* bug#10169: a simple interrupt evokes abort?! (but only with (require 'saveplace)) 2011-12-03 22:46 ` Dan Nicolaescu @ 2011-12-03 22:53 ` Daniel Colascione 0 siblings, 0 replies; 21+ messages in thread From: Daniel Colascione @ 2011-12-03 22:53 UTC (permalink / raw) To: Dan Nicolaescu; +Cc: Andreas Schwab, Paul Eggert, 10169, Jim Meyering [-- Attachment #1: Type: text/plain, Size: 763 bytes --] On 12/3/11 2:46 PM, Dan Nicolaescu wrote: > Andreas Schwab <schwab@linux-m68k.org> writes: > >> Dan Nicolaescu <dann@gnu.org> writes: >> >>> How does that that justify introducing another severe bug: can't kill >>> emacs using C-c (as it has always been possible ? >> >> C-c in an interactive shell doesn't kill it either. > > What's the similarity between emacs as an X11 application and an > interactive shell? > And again, how do you justify changing a long time behavior? I agree: a SIGINT sent to an Emacs running as a deamon or as a GUI application should kill it dead, without running any Lisp code at all. It's only when Emacs is actually interesting with the user over a terminal that Emacs should process control-c specially. [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 235 bytes --] ^ permalink raw reply [flat|nested] 21+ messages in thread
* bug#10169: a simple interrupt evokes abort?! (but only with (require 'saveplace)) 2011-12-03 22:23 ` Andreas Schwab 2011-12-03 22:46 ` Dan Nicolaescu @ 2011-12-04 2:08 ` Chong Yidong 2011-12-04 9:37 ` Andreas Schwab 2011-12-04 15:05 ` Richard Stallman 1 sibling, 2 replies; 21+ messages in thread From: Chong Yidong @ 2011-12-04 2:08 UTC (permalink / raw) To: Andreas Schwab; +Cc: Dan Nicolaescu, Paul Eggert, 10169, Jim Meyering Andreas Schwab <schwab@linux-m68k.org> writes: > Dan Nicolaescu <dann@gnu.org> writes: > >> How does that that justify introducing another severe bug: can't kill >> emacs using C-c (as it has always been possible ? > > C-c in an interactive shell doesn't kill it either. The argument is invalid: here, Emacs is not using C-c as keyboard input. This change is worse than the bug it is trying to fix. Please revert. ^ permalink raw reply [flat|nested] 21+ messages in thread
* bug#10169: a simple interrupt evokes abort?! (but only with (require 'saveplace)) 2011-12-04 2:08 ` Chong Yidong @ 2011-12-04 9:37 ` Andreas Schwab 2011-12-04 15:05 ` Richard Stallman 1 sibling, 0 replies; 21+ messages in thread From: Andreas Schwab @ 2011-12-04 9:37 UTC (permalink / raw) To: Chong Yidong; +Cc: Dan Nicolaescu, Paul Eggert, 10169, Jim Meyering Chong Yidong <cyd@gnu.org> writes: > The argument is invalid: here, Emacs is not using C-c as keyboard input. > This change is worse than the bug it is trying to fix. Please revert. It is an absolute no-go to call Lisp in a signal handler. So I have installed a different solution. Andreas. -- Andreas Schwab, schwab@linux-m68k.org GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different." ^ permalink raw reply [flat|nested] 21+ messages in thread
* bug#10169: a simple interrupt evokes abort?! (but only with (require 'saveplace)) 2011-12-04 2:08 ` Chong Yidong 2011-12-04 9:37 ` Andreas Schwab @ 2011-12-04 15:05 ` Richard Stallman 1 sibling, 0 replies; 21+ messages in thread From: Richard Stallman @ 2011-12-04 15:05 UTC (permalink / raw) To: Chong Yidong; +Cc: dann, eggert, schwab, jim, 10169 > C-c in an interactive shell doesn't kill it either. The argument is invalid: here, Emacs is not using C-c as keyboard input. This change is worse than the bug it is trying to fix. Please revert. I agree. -- Dr Richard Stallman President, Free Software Foundation 51 Franklin St Boston MA 02110 USA www.fsf.org www.gnu.org Skype: No way! That's nonfree (freedom-denying) software. Use free telephony http://directory.fsf.org/category/tel/ ^ permalink raw reply [flat|nested] 21+ messages in thread
* bug#10169: a simple interrupt evokes abort?! (but only with (require 'saveplace)) 2011-12-01 18:09 ` Glenn Morris 2011-12-01 18:42 ` Andreas Schwab @ 2011-12-02 0:34 ` Dan Nicolaescu 1 sibling, 0 replies; 21+ messages in thread From: Dan Nicolaescu @ 2011-12-02 0:34 UTC (permalink / raw) To: Glenn Morris; +Cc: Paul Eggert, 10169, Jim Meyering Glenn Morris <rgm@gnu.org> writes: > I can reproduce it on Scientific Linux 6.1, x86_64, with gcc 4.4.5 > 20110214 (Red Hat 4.4.5-6). Backtrace: > > Lisp Backtrace: > "scan-lists" (0xffff19b8) > "down-list" (0xffff1ea0) > "byte-code" (0xffff2290) > "pp-buffer" (0xffff2a48) > "pp-to-string" (0xffff2f20) > "pp" (0xffff33e8) > "save-place-alist-to-file" (0xffff38b8) > "save-place-kill-emacs-hook" (0xffff3e58) A quick hack: put a `when' around the `pp' call in `save-place-alist-to-file' (when save-place-alist (pp (sort save-place-alist and it does not crash anymore. Sounds strange, but unfortunately I don't have time at the moment to investigate further what's really going on. ^ permalink raw reply [flat|nested] 21+ messages in thread
* bug#10169: a simple interrupt evokes abort?! (but only with (require 'saveplace)) 2011-11-30 12:24 bug#10169: a simple interrupt evokes abort?! (but only with (require 'saveplace)) Jim Meyering 2011-12-01 16:03 ` Paul Eggert @ 2011-12-01 19:25 ` Stefan Monnier 2011-12-01 19:38 ` Dan Nicolaescu 2011-12-03 20:21 ` Glenn Morris 2 siblings, 1 reply; 21+ messages in thread From: Stefan Monnier @ 2011-12-01 19:25 UTC (permalink / raw) To: Jim Meyering; +Cc: 10169 > So anyone can reproduce it by running this and then hitting ^C: > $ touch /tmp/k; emacs -q --eval "(require 'saveplace)" /tmp/k > ^CFatal error (6)zsh: abort (core dumped) emacs -q --eval "(require\ > 'saveplace)" /tmp/k > [Exit 134 (ABRT)] I can reproduce it indeed with Debian testing's emacs23 as well as with the current trunk. I have to be careful to hit C-c before Emacs actually opens the frame (i.e. interrupt it during startup), otherwise it exits cleanly. Can't investigate further right now, so if anyone wants to pick up from here, he's welcome. Stefan ^ permalink raw reply [flat|nested] 21+ messages in thread
* bug#10169: a simple interrupt evokes abort?! (but only with (require 'saveplace)) 2011-12-01 19:25 ` Stefan Monnier @ 2011-12-01 19:38 ` Dan Nicolaescu 0 siblings, 0 replies; 21+ messages in thread From: Dan Nicolaescu @ 2011-12-01 19:38 UTC (permalink / raw) To: Stefan Monnier; +Cc: 10169, Jim Meyering Stefan Monnier <monnier@iro.umontreal.ca> writes: >> So anyone can reproduce it by running this and then hitting ^C: > >> $ touch /tmp/k; emacs -q --eval "(require 'saveplace)" /tmp/k >> ^CFatal error (6)zsh: abort (core dumped) emacs -q --eval "(require\ >> 'saveplace)" /tmp/k >> [Exit 134 (ABRT)] > > I can reproduce it indeed with Debian testing's emacs23 as well as with > the current trunk. > > I have to be careful to hit C-c before Emacs actually opens the frame > (i.e. interrupt it during startup), otherwise it exits cleanly. I cannot reproduce it with emacs-23.3 on Fedora 16... I can reproduce it on yesterday's trunk. I vaguely remember there was some problem with saveplace.el and emacs --daemon, something about saveplace.el wanting to chat when shutting down. No idea if that's related, and I can't find the discussion at the moment... ^ permalink raw reply [flat|nested] 21+ messages in thread
* bug#10169: a simple interrupt evokes abort?! (but only with (require 'saveplace)) 2011-11-30 12:24 bug#10169: a simple interrupt evokes abort?! (but only with (require 'saveplace)) Jim Meyering 2011-12-01 16:03 ` Paul Eggert 2011-12-01 19:25 ` Stefan Monnier @ 2011-12-03 20:21 ` Glenn Morris 2 siblings, 0 replies; 21+ messages in thread From: Glenn Morris @ 2011-12-03 20:21 UTC (permalink / raw) To: Andreas Schwab; +Cc: Paul Eggert, 10169, Jim Meyering Andreas Schwab wrote: > IMHO this is the correct behaviour for an interactive programm. It seems weird to me, but I'm not qualified to argue with you. None of xterm, gedit, firefox, librefoffice behave as you describe. gnome-terminal and gvim "detach" themselves, or whatever the term is (ie, act like you had used '&' even if you had not; this also seems weird to me), but Emacs does not. gvim -f behaves like Emacs does now. I guess this means you fixed your own report, so I will merge it: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=5743 ^ permalink raw reply [flat|nested] 21+ messages in thread
end of thread, other threads:[~2011-12-04 15:05 UTC | newest] Thread overview: 21+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2011-11-30 12:24 bug#10169: a simple interrupt evokes abort?! (but only with (require 'saveplace)) Jim Meyering 2011-12-01 16:03 ` Paul Eggert 2011-12-01 16:13 ` Jim Meyering 2011-12-01 18:09 ` Glenn Morris 2011-12-01 18:42 ` Andreas Schwab 2011-12-01 19:00 ` Glenn Morris 2011-12-01 19:02 ` Glenn Morris 2011-12-03 8:54 ` Andreas Schwab 2011-12-03 21:04 ` Dan Nicolaescu 2011-12-03 21:26 ` Andreas Schwab 2011-12-03 22:07 ` Dan Nicolaescu 2011-12-03 22:23 ` Andreas Schwab 2011-12-03 22:46 ` Dan Nicolaescu 2011-12-03 22:53 ` Daniel Colascione 2011-12-04 2:08 ` Chong Yidong 2011-12-04 9:37 ` Andreas Schwab 2011-12-04 15:05 ` Richard Stallman 2011-12-02 0:34 ` Dan Nicolaescu 2011-12-01 19:25 ` Stefan Monnier 2011-12-01 19:38 ` Dan Nicolaescu 2011-12-03 20:21 ` Glenn Morris
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).