* 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-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-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-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-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
* 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
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).