* bug#13743: 24.2.93; Segmentation fault when trying to [s]teal a file opened elsewhere
@ 2013-02-18 6:41 Dmitry Gutov
2013-02-18 16:11 ` Eli Zaretskii
` (2 more replies)
0 siblings, 3 replies; 34+ messages in thread
From: Dmitry Gutov @ 2013-02-18 6:41 UTC (permalink / raw)
To: 13743
Emacs reliably crashes when [s]tealing a file that's opened in another
instance. I can only reproduce this when the buffer opens in mmm-mode
(so the bug may be related to indirect buffers), and apparently mmm-mode
modifies the buffer in some way automatically, so the prompt to
steal/proceed/quit is shown as soon as I open the file.
I think this is the first situation I've seen Emacs crash, in quite a
while.
(gdb) xbacktrace
"put-text-property" (0xffff9a20)
"jit-lock-refontify" (0xffff9c00)
"jit-lock-mode" (0xffff9e00)
"jit-lock-register" (0xffff9fd0)
"font-lock-turn-on-thing-lock" (0xffffa1b0)
"font-lock-mode-internal" (0xffffa380)
"font-lock-default-function" (0xffffa550)
"font-lock-mode" (0xffffa720)
"turn-on-font-lock" (0xffffa8d0)
"turn-on-font-lock-if-desired" (0xffffaa90)
"global-font-lock-mode-enable-in-buffers" (0xffffaca8)
"run-hooks" (0xffffad68)
"apply" (0xffffaec0)
"run-mode-hooks" (0xffffaff0)
"html-erb-mode" (0xffffb2a8)
"funcall" (0xffffb2a0)
"save-current-buffer" (0xffffb418)
"unwind-protect" (0xffffb538)
"let" (0xffffb6d8)
"if" (0xffffb7e8)
"let" (0xffffb9a8)
"mmm-update-mode-info" (0xffffbaf0)
"if" (0xffffbcc8)
---Type <return> to continue, or q <return> to quit---
"if" (0xffffbdd8)
"mmm-mode-on" (0xffffbf20)
"cond" (0xffffc0e8)
"mmm-mode-on-maybe" (0xffffc2d8)
"funcall" (0xffffc2d0)
"progn" (0xffffc428)
"condition-case" (0xffffc6a8)
"while" (0xffffc7d8)
"let" (0xffffc978)
"progn" (0xffffca88)
"mmm-run-major-mode-hook" (0xffffcbd0)
"save-current-buffer" (0xffffcdb8)
"progn" (0xffffcec8)
"if" (0xffffcfc8)
"while" (0xffffd0f8)
"let" (0xffffd298)
"progn" (0xffffd3a8)
"mmm-check-changed-buffers" (0xffffd590)
(gdb)
===
bt full is too long for my terminal, so here's the top. Let me know if
it's not enough, I'll try to increase the history limit or whatever.
(gdb) bt full
#0 add_properties (plist=plist@entry=31577430, i=i@entry=0x0,
object=object@entry=12438597) at textprop.c:378
tail1 = 31577430
tail2 = <optimized out>
sym1 = 12306530
val1 = 12067362
changed = <optimized out>
found = 0
#1 0x00000000005a4fb3 in Fadd_text_properties (start=start@entry=4,
end=end@entry=3068, properties=31577430, object=12438597,
object@entry=12067362) at textprop.c:1212
i = 0x0
unchanged = <optimized out>
s = <optimized out>
len = 558
modified = 19
#2 0x00000000005a52bf in Fput_text_property (start=4, end=3068,
property=12306530, value=<optimized out>, object=12067362)
at textprop.c:1229
No locals.
#3 0x000000000055490f in Ffuncall (nargs=<optimized out>,
args=<optimized out>) at eval.c:2794
fun = 11445941
---Type <return> to continue, or q <return> to quit---
original_fun = <optimized out>
funcar = <optimized out>
numargs = <optimized out>
lisp_numargs = <optimized out>
val = <optimized out>
backtrace = {
next = 0x7fffffff9b80,
function = 12254514,
args = 0x7fffffff9a20,
nargs = 4,
debug_on_exit = 0
}
internal_args = 0x7fffffff9950
i = <optimized out>
#4 0x000000000058a1e3 in exec_byte_code (bytestr=31577446, vector=37,
maxdepth=5, args_template=4611686018695757824, nargs=4611686018430533632,
args=0x7fffffff9568, args@entry=0x0) at bytecode.c:900
targets = {0x58a2f8 <exec_byte_code+1032>,
0x58c311 <exec_byte_code+9249>, 0x58c3b3 <exec_byte_code+9411>,
0x58bf7a <exec_byte_code+8330>, 0x58a24a <exec_byte_code+858>,
0x58a24a <exec_byte_code+858>, 0x58bf7f <exec_byte_code+8335>,
0x58bfc0 <exec_byte_code+8400>, 0x58bf35 <exec_byte_code+8261>,
0x58bf3a <exec_byte_code+8266>, 0x58bf3f <exec_byte_code+8271>,
---Type <return> to continue, or q <return> to quit---
0x58bf45 <exec_byte_code+8277>, 0x58a0d2 <exec_byte_code+482>,
0x58a0d8 <exec_byte_code+488>, 0x58a332 <exec_byte_code+1090>,
0x58bf55 <exec_byte_code+8293>, 0x58a4b0 <exec_byte_code+1472>,
0x58a4b5 <exec_byte_code+1477>, 0x58a4ba <exec_byte_code+1482>,
0x58a4c5 <exec_byte_code+1493>, 0x58a126 <exec_byte_code+566>,
0x58a130 <exec_byte_code+576>, 0x58a4fa <exec_byte_code+1546>,
0x58a4d5 <exec_byte_code+1509>, 0x58a570 <exec_byte_code+1664>,
0x58a575 <exec_byte_code+1669>, 0x58a57a <exec_byte_code+1674>,
0x58a585 <exec_byte_code+1685>, 0x58a18a <exec_byte_code+666>,
0x58a190 <exec_byte_code+672>, 0x58a537 <exec_byte_code+1607>,
0x58a54b <exec_byte_code+1627>, 0x58a5ce <exec_byte_code+1758>,
0x58a5d3 <exec_byte_code+1763>, 0x58a5d8 <exec_byte_code+1768>,
0x58a5e5 <exec_byte_code+1781>, 0x58a1c3 <exec_byte_code+723>,
0x58a1c8 <exec_byte_code+728>, 0x58a595 <exec_byte_code+1701>,
0x58a5a9 <exec_byte_code+1721>, 0x58a62e <exec_byte_code+1854>,
0x58a633 <exec_byte_code+1859>, 0x58a638 <exec_byte_code+1864>,
0x58a645 <exec_byte_code+1877>, 0x58a203 <exec_byte_code+787>,
0x58a208 <exec_byte_code+792>, 0x58a5f5 <exec_byte_code+1797>,
0x58a609 <exec_byte_code+1817>, 0x58a2f8 <exec_byte_code+1032>,
0x58a2f8 <exec_byte_code+1032>, 0x58a2f8 <exec_byte_code+1032>,
0x58a2f8 <exec_byte_code+1032>, 0x58a2f8 <exec_byte_code+1032>,
0x58a2f8 <exec_byte_code+1032>, 0x58a2f8 <exec_byte_code+1032>,
0x58a2f8 <exec_byte_code+1032>, 0x58ae64 <exec_byte_code+3956>,
---Type <return> to continue, or q <return> to quit---
0x58aef0 <exec_byte_code+4096>, 0x58af29 <exec_byte_code+4153>,
0x58af62 <exec_byte_code+4210>, 0x58af9b <exec_byte_code+4267>,
0x58a400 <exec_byte_code+1296>, 0x58a43d <exec_byte_code+1357>,
0x58afde <exec_byte_code+4334>, 0x58a3c4 <exec_byte_code+1236>,
0x58a474 <exec_byte_code+1412>, 0x58b011 <exec_byte_code+4385>,
0x58b048 <exec_byte_code+4440>, 0x58b078 <exec_byte_code+4488>,
0x58b0be <exec_byte_code+4558>, 0x58b0f4 <exec_byte_code+4612>,
0x58b16c <exec_byte_code+4732>, 0x58b195 <exec_byte_code+4773>,
0x58b1cc <exec_byte_code+4828>, 0x58b208 <exec_byte_code+4888>,
0x58b231 <exec_byte_code+4929>, 0x58b25a <exec_byte_code+4970>,
0x58b291 <exec_byte_code+5025>, 0x58b2c8 <exec_byte_code+5080>,
0x58b2ff <exec_byte_code+5135>, 0x58b33b <exec_byte_code+5195>,
0x58b371 <exec_byte_code+5249>, 0x58b3a7 <exec_byte_code+5303>,
0x58b41f <exec_byte_code+5423>, 0x58b459 <exec_byte_code+5481>,
0x58b493 <exec_byte_code+5539>, 0x58b51f <exec_byte_code+5679>,
0x58b556 <exec_byte_code+5734>, 0x58b58d <exec_byte_code+5789>,
0x58b5c4 <exec_byte_code+5844>, 0x58b5fb <exec_byte_code+5899>,
0x58b631 <exec_byte_code+5953>, 0x58b664 <exec_byte_code+6004>,
0x58b69a <exec_byte_code+6058>, 0x58b6d0 <exec_byte_code+6112>,
0x58b706 <exec_byte_code+6166>, 0x58b7a9 <exec_byte_code+6329>,
0x58a304 <exec_byte_code+1044>, 0x58b7e0 <exec_byte_code+6384>,
0x58b809 <exec_byte_code+6425>, 0x58b878 <exec_byte_code+6536>,
0x58b8af <exec_byte_code+6591>, 0x58b8e6 <exec_byte_code+6646>,
---Type <return> to continue, or q <return> to quit---
0x58b90f <exec_byte_code+6687>, 0x58b939 <exec_byte_code+6729>,
0x58b963 <exec_byte_code+6771>, 0x58b991 <exec_byte_code+6817>,
0x58a2f8 <exec_byte_code+1032>, 0x58b9c1 <exec_byte_code+6865>,
0x58b9ef <exec_byte_code+6911>, 0x58ba1d <exec_byte_code+6957>,
0x58ba4b <exec_byte_code+7003>, 0x58ba79 <exec_byte_code+7049>,
0x58baa7 <exec_byte_code+7095>, 0x58a304 <exec_byte_code+1044>,
0x58a2f8 <exec_byte_code+1032>, 0x58bad0 <exec_byte_code+7136>,
0x58bafe <exec_byte_code+7182>, 0x58bb27 <exec_byte_code+7223>,
0x58bb50 <exec_byte_code+7264>, 0x58bb87 <exec_byte_code+7319>,
0x58bbbe <exec_byte_code+7374>, 0x58bbe7 <exec_byte_code+7415>,
0x58bcb4 <exec_byte_code+7620>, 0x58be70 <exec_byte_code+8064>,
0x58bea7 <exec_byte_code+8119>, 0x58bede <exec_byte_code+8174>,
0x58bf0c <exec_byte_code+8220>, 0x58a2f8 <exec_byte_code+1032>,
0x58a84e <exec_byte_code+2398>, 0x58a681 <exec_byte_code+1937>,
0x58a346 <exec_byte_code+1110>, 0x58a71d <exec_byte_code+2093>,
0x58a7d3 <exec_byte_code+2275>, 0x58a9bc <exec_byte_code+2764>,
0x58ad13 <exec_byte_code+3619>, 0x58ad67 <exec_byte_code+3703>,
0x58a50e <exec_byte_code+1566>, 0x58a897 <exec_byte_code+2471>,
0x58a8c5 <exec_byte_code+2517>, 0x58a924 <exec_byte_code+2612>,
0x58a952 <exec_byte_code+2658>, 0x58a98e <exec_byte_code+2718>,
0x58ad87 <exec_byte_code+3735>, 0x58adc3 <exec_byte_code+3795>,
0x58ae06 <exec_byte_code+3862>, 0x58a655 <exec_byte_code+1893>,
0x58bceb <exec_byte_code+7675>, 0x58bd27 <exec_byte_code+7735>,
---Type <return> to continue, or q <return> to quit---
0x58bd50 <exec_byte_code+7776>, 0x58bd79 <exec_byte_code+7817>,
0x58bda2 <exec_byte_code+7858>, 0x58bdcb <exec_byte_code+7899>,
0x58be02 <exec_byte_code+7954>, 0x58be39 <exec_byte_code+8009>,
0x58c11b <exec_byte_code+8747>, 0x58c152 <exec_byte_code+8802>,
0x58c198 <exec_byte_code+8872>, 0x58c1cf <exec_byte_code+8927>,
0x58c206 <exec_byte_code+8982>, 0x58c22f <exec_byte_code+9023>,
0x58c266 <exec_byte_code+9078>, 0x58c29d <exec_byte_code+9133>,
0x58c2d7 <exec_byte_code+9191>, 0x58c37d <exec_byte_code+9357>,
0x58b73c <exec_byte_code+6220>, 0x58b772 <exec_byte_code+6274>,
0x58c316 <exec_byte_code+9254>, 0x58c349 <exec_byte_code+9305>,
0x58a2f8 <exec_byte_code+1032>, 0x58aa6f <exec_byte_code+2943>,
0x58aaf8 <exec_byte_code+3080>, 0x58ab67 <exec_byte_code+3191>,
0x58ac06 <exec_byte_code+3350>, 0x58ac76 <exec_byte_code+3462>,
0x58b12a <exec_byte_code+4666>, 0x58b3dd <exec_byte_code+5357>,
0x58b836 <exec_byte_code+6470>, 0x58c014 <exec_byte_code+8484>,
0x58c054 <exec_byte_code+8548>, 0x58a2f8 <exec_byte_code+1032>,
0x58a2f8 <exec_byte_code+1032>, 0x58c0a7 <exec_byte_code+8631>,
0x58a2f8 <exec_byte_code+1032>, 0x58a2f8 <exec_byte_code+1032>,
0x58a2f8 <exec_byte_code+1032>, 0x58a2f8 <exec_byte_code+1032>,
0x58a2f8 <exec_byte_code+1032>, 0x58a2f8 <exec_byte_code+1032>,
0x58a2f8 <exec_byte_code+1032>, 0x58a2f8 <exec_byte_code+1032>,
0x58a2f8 <exec_byte_code+1032>,
0x58c0ee <exec_byte_code+8702> <repeats 64 times>}
---Type <return> to continue, or q <return> to quit---
stack = {
pc = 0xa6e13b <pure+2363995> ".\n\207",
byte_string = 9883225,
byte_string_start = 0xa6e113 <pure+2363955> "\306\030\307 \031\032\033\306\034\035\036\f\310\036\r\214~\210\312\016\016\206\037",
constants = 9883261,
next = 0x7fffffff9c80
}
result = 12067362
#5 0x0000000000554491 in funcall_lambda (fun=9883173, nargs=nargs@entry=0,
arg_vector=arg_vector@entry=0x7fffffff9c00) at eval.c:3010
val = <optimized out>
syms_left = 12067362
next = <optimized out>
lexenv = 12067362
count = 32
i = <optimized out>
optional = <optimized out>
rest = <optimized out>
#6 0x00000000005547bb in Ffuncall (nargs=1, args=0x7fffffff9bf8)
at eval.c:2839
fun = <optimized out>
original_fun = 19797250
---Type <return> to continue, or q <return> to quit---
funcar = <optimized out>
numargs = 0
lisp_numargs = <optimized out>
val = <optimized out>
backtrace = {
next = 0x7fffffff9d80,
function = 19797250,
args = 0x7fffffff9c00,
nargs = 0,
debug_on_exit = 0
}
internal_args = <optimized out>
i = <optimized out>
#7 0x000000000058a1e3 in exec_byte_code (bytestr=31577446, vector=106,
maxdepth=5, args_template=4611686018695757824, nargs=4611686018430533632,
args=0x7fffffff9568, args@entry=0x0) at bytecode.c:900
targets = {0x58a2f8 <exec_byte_code+1032>,
0x58c311 <exec_byte_code+9249>, 0x58c3b3 <exec_byte_code+9411>,
0x58bf7a <exec_byte_code+8330>, 0x58a24a <exec_byte_code+858>,
0x58a24a <exec_byte_code+858>, 0x58bf7f <exec_byte_code+8335>,
0x58bfc0 <exec_byte_code+8400>, 0x58bf35 <exec_byte_code+8261>,
0x58bf3a <exec_byte_code+8266>, 0x58bf3f <exec_byte_code+8271>,
0x58bf45 <exec_byte_code+8277>, 0x58a0d2 <exec_byte_code+482>,
---Type <return> to continue, or q <return> to quit---
0x58a0d8 <exec_byte_code+488>, 0x58a332 <exec_byte_code+1090>,
0x58bf55 <exec_byte_code+8293>, 0x58a4b0 <exec_byte_code+1472>,
0x58a4b5 <exec_byte_code+1477>, 0x58a4ba <exec_byte_code+1482>,
0x58a4c5 <exec_byte_code+1493>, 0x58a126 <exec_byte_code+566>,
0x58a130 <exec_byte_code+576>, 0x58a4fa <exec_byte_code+1546>,
0x58a4d5 <exec_byte_code+1509>, 0x58a570 <exec_byte_code+1664>,
0x58a575 <exec_byte_code+1669>, 0x58a57a <exec_byte_code+1674>,
0x58a585 <exec_byte_code+1685>, 0x58a18a <exec_byte_code+666>,
0x58a190 <exec_byte_code+672>, 0x58a537 <exec_byte_code+1607>,
0x58a54b <exec_byte_code+1627>, 0x58a5ce <exec_byte_code+1758>,
0x58a5d3 <exec_byte_code+1763>, 0x58a5d8 <exec_byte_code+1768>,
0x58a5e5 <exec_byte_code+1781>, 0x58a1c3 <exec_byte_code+723>,
0x58a1c8 <exec_byte_code+728>, 0x58a595 <exec_byte_code+1701>,
0x58a5a9 <exec_byte_code+1721>, 0x58a62e <exec_byte_code+1854>,
0x58a633 <exec_byte_code+1859>, 0x58a638 <exec_byte_code+1864>,
0x58a645 <exec_byte_code+1877>, 0x58a203 <exec_byte_code+787>,
0x58a208 <exec_byte_code+792>, 0x58a5f5 <exec_byte_code+1797>,
0x58a609 <exec_byte_code+1817>, 0x58a2f8 <exec_byte_code+1032>,
0x58a2f8 <exec_byte_code+1032>, 0x58a2f8 <exec_byte_code+1032>,
0x58a2f8 <exec_byte_code+1032>, 0x58a2f8 <exec_byte_code+1032>,
0x58a2f8 <exec_byte_code+1032>, 0x58a2f8 <exec_byte_code+1032>,
0x58a2f8 <exec_byte_code+1032>, 0x58ae64 <exec_byte_code+3956>,
0x58aef0 <exec_byte_code+4096>, 0x58af29 <exec_byte_code+4153>,
---Type <return> to continue, or q <return> to quit---
0x58af62 <exec_byte_code+4210>, 0x58af9b <exec_byte_code+4267>,
0x58a400 <exec_byte_code+1296>, 0x58a43d <exec_byte_code+1357>,
0x58afde <exec_byte_code+4334>, 0x58a3c4 <exec_byte_code+1236>,
0x58a474 <exec_byte_code+1412>, 0x58b011 <exec_byte_code+4385>,
0x58b048 <exec_byte_code+4440>, 0x58b078 <exec_byte_code+4488>,
0x58b0be <exec_byte_code+4558>, 0x58b0f4 <exec_byte_code+4612>,
0x58b16c <exec_byte_code+4732>, 0x58b195 <exec_byte_code+4773>,
0x58b1cc <exec_byte_code+4828>, 0x58b208 <exec_byte_code+4888>,
0x58b231 <exec_byte_code+4929>, 0x58b25a <exec_byte_code+4970>,
0x58b291 <exec_byte_code+5025>, 0x58b2c8 <exec_byte_code+5080>,
0x58b2ff <exec_byte_code+5135>, 0x58b33b <exec_byte_code+5195>,
0x58b371 <exec_byte_code+5249>, 0x58b3a7 <exec_byte_code+5303>,
0x58b41f <exec_byte_code+5423>, 0x58b459 <exec_byte_code+5481>,
0x58b493 <exec_byte_code+5539>, 0x58b51f <exec_byte_code+5679>,
0x58b556 <exec_byte_code+5734>, 0x58b58d <exec_byte_code+5789>,
0x58b5c4 <exec_byte_code+5844>, 0x58b5fb <exec_byte_code+5899>,
0x58b631 <exec_byte_code+5953>, 0x58b664 <exec_byte_code+6004>,
0x58b69a <exec_byte_code+6058>, 0x58b6d0 <exec_byte_code+6112>,
0x58b706 <exec_byte_code+6166>, 0x58b7a9 <exec_byte_code+6329>,
0x58a304 <exec_byte_code+1044>, 0x58b7e0 <exec_byte_code+6384>,
0x58b809 <exec_byte_code+6425>, 0x58b878 <exec_byte_code+6536>,
0x58b8af <exec_byte_code+6591>, 0x58b8e6 <exec_byte_code+6646>,
0x58b90f <exec_byte_code+6687>, 0x58b939 <exec_byte_code+6729>,
---Type <return> to continue, or q <return> to quit---
0x58b963 <exec_byte_code+6771>, 0x58b991 <exec_byte_code+6817>,
0x58a2f8 <exec_byte_code+1032>, 0x58b9c1 <exec_byte_code+6865>,
0x58b9ef <exec_byte_code+6911>, 0x58ba1d <exec_byte_code+6957>,
0x58ba4b <exec_byte_code+7003>, 0x58ba79 <exec_byte_code+7049>,
0x58baa7 <exec_byte_code+7095>, 0x58a304 <exec_byte_code+1044>,
0x58a2f8 <exec_byte_code+1032>, 0x58bad0 <exec_byte_code+7136>,
0x58bafe <exec_byte_code+7182>, 0x58bb27 <exec_byte_code+7223>,
0x58bb50 <exec_byte_code+7264>, 0x58bb87 <exec_byte_code+7319>,
0x58bbbe <exec_byte_code+7374>, 0x58bbe7 <exec_byte_code+7415>,
0x58bcb4 <exec_byte_code+7620>, 0x58be70 <exec_byte_code+8064>,
0x58bea7 <exec_byte_code+8119>, 0x58bede <exec_byte_code+8174>,
0x58bf0c <exec_byte_code+8220>, 0x58a2f8 <exec_byte_code+1032>,
0x58a84e <exec_byte_code+2398>, 0x58a681 <exec_byte_code+1937>,
0x58a346 <exec_byte_code+1110>, 0x58a71d <exec_byte_code+2093>,
0x58a7d3 <exec_byte_code+2275>, 0x58a9bc <exec_byte_code+2764>,
0x58ad13 <exec_byte_code+3619>, 0x58ad67 <exec_byte_code+3703>,
0x58a50e <exec_byte_code+1566>, 0x58a897 <exec_byte_code+2471>,
0x58a8c5 <exec_byte_code+2517>, 0x58a924 <exec_byte_code+2612>,
0x58a952 <exec_byte_code+2658>, 0x58a98e <exec_byte_code+2718>,
0x58ad87 <exec_byte_code+3735>, 0x58adc3 <exec_byte_code+3795>,
0x58ae06 <exec_byte_code+3862>, 0x58a655 <exec_byte_code+1893>,
0x58bceb <exec_byte_code+7675>, 0x58bd27 <exec_byte_code+7735>,
0x58bd50 <exec_byte_code+7776>, 0x58bd79 <exec_byte_code+7817>,
---Type <return> to continue, or q <return> to quit---
0x58bda2 <exec_byte_code+7858>, 0x58bdcb <exec_byte_code+7899>,
0x58be02 <exec_byte_code+7954>, 0x58be39 <exec_byte_code+8009>,
0x58c11b <exec_byte_code+8747>, 0x58c152 <exec_byte_code+8802>,
0x58c198 <exec_byte_code+8872>, 0x58c1cf <exec_byte_code+8927>,
0x58c206 <exec_byte_code+8982>, 0x58c22f <exec_byte_code+9023>,
0x58c266 <exec_byte_code+9078>, 0x58c29d <exec_byte_code+9133>,
0x58c2d7 <exec_byte_code+9191>, 0x58c37d <exec_byte_code+9357>,
0x58b73c <exec_byte_code+6220>, 0x58b772 <exec_byte_code+6274>,
0x58c316 <exec_byte_code+9254>, 0x58c349 <exec_byte_code+9305>,
0x58a2f8 <exec_byte_code+1032>, 0x58aa6f <exec_byte_code+2943>,
0x58aaf8 <exec_byte_code+3080>, 0x58ab67 <exec_byte_code+3191>,
0x58ac06 <exec_byte_code+3350>, 0x58ac76 <exec_byte_code+3462>,
0x58b12a <exec_byte_code+4666>, 0x58b3dd <exec_byte_code+5357>,
0x58b836 <exec_byte_code+6470>, 0x58c014 <exec_byte_code+8484>,
0x58c054 <exec_byte_code+8548>, 0x58a2f8 <exec_byte_code+1032>,
0x58a2f8 <exec_byte_code+1032>, 0x58c0a7 <exec_byte_code+8631>,
0x58a2f8 <exec_byte_code+1032>, 0x58a2f8 <exec_byte_code+1032>,
0x58a2f8 <exec_byte_code+1032>, 0x58a2f8 <exec_byte_code+1032>,
0x58a2f8 <exec_byte_code+1032>, 0x58a2f8 <exec_byte_code+1032>,
0x58a2f8 <exec_byte_code+1032>, 0x58a2f8 <exec_byte_code+1032>,
0x58a2f8 <exec_byte_code+1032>,
0x58c0ee <exec_byte_code+8702> <repeats 64 times>}
stack = {
---Type <return> to continue, or q <return> to quit---
pc = 0xa6e1a1 <pure+2364097> "\210\n\203\027",
byte_string = 9882281,
byte_string_start = 0xa6e199 <pure+2364089> "\b\211\021\203j",
constants = 9882317,
next = 0x7fffffff9e50
}
result = 12067362
#8 0x0000000000554491 in funcall_lambda (fun=9882229, nargs=nargs@entry=1,
arg_vector=arg_vector@entry=0x7fffffff9e00) at eval.c:3010
val = <optimized out>
syms_left = 12067362
next = <optimized out>
lexenv = 12067362
count = 31
i = <optimized out>
optional = <optimized out>
rest = <optimized out>
#9 0x00000000005547bb in Ffuncall (nargs=2, args=0x7fffffff9df8)
at eval.c:2839
fun = <optimized out>
original_fun = 19797058
funcar = <optimized out>
numargs = 1
---Type <return> to continue, or q <return> to quit---
lisp_numargs = <optimized out>
val = <optimized out>
backtrace = {
next = 0x7fffffff9f50,
function = 19797058,
args = 0x7fffffff9e00,
nargs = 1,
debug_on_exit = 0
}
internal_args = <optimized out>
i = <optimized out>
#10 0x000000000058a1e3 in exec_byte_code (bytestr=31577446, vector=21,
maxdepth=5, args_template=4611686018695757824, nargs=4611686018430533632,
args=0x7fffffff9568, args@entry=0x0) at bytecode.c:900
targets = {0x58a2f8 <exec_byte_code+1032>,
0x58c311 <exec_byte_code+9249>, 0x58c3b3 <exec_byte_code+9411>,
0x58bf7a <exec_byte_code+8330>, 0x58a24a <exec_byte_code+858>,
0x58a24a <exec_byte_code+858>, 0x58bf7f <exec_byte_code+8335>,
0x58bfc0 <exec_byte_code+8400>, 0x58bf35 <exec_byte_code+8261>,
0x58bf3a <exec_byte_code+8266>, 0x58bf3f <exec_byte_code+8271>,
0x58bf45 <exec_byte_code+8277>, 0x58a0d2 <exec_byte_code+482>,
0x58a0d8 <exec_byte_code+488>, 0x58a332 <exec_byte_code+1090>,
0x58bf55 <exec_byte_code+8293>, 0x58a4b0 <exec_byte_code+1472>,
---Type <return> to continue, or q <return> to quit---
0x58a4b5 <exec_byte_code+1477>, 0x58a4ba <exec_byte_code+1482>,
0x58a4c5 <exec_byte_code+1493>, 0x58a126 <exec_byte_code+566>,
0x58a130 <exec_byte_code+576>, 0x58a4fa <exec_byte_code+1546>,
0x58a4d5 <exec_byte_code+1509>, 0x58a570 <exec_byte_code+1664>,
0x58a575 <exec_byte_code+1669>, 0x58a57a <exec_byte_code+1674>,
0x58a585 <exec_byte_code+1685>, 0x58a18a <exec_byte_code+666>,
0x58a190 <exec_byte_code+672>, 0x58a537 <exec_byte_code+1607>,
0x58a54b <exec_byte_code+1627>, 0x58a5ce <exec_byte_code+1758>,
0x58a5d3 <exec_byte_code+1763>, 0x58a5d8 <exec_byte_code+1768>,
0x58a5e5 <exec_byte_code+1781>, 0x58a1c3 <exec_byte_code+723>,
0x58a1c8 <exec_byte_code+728>, 0x58a595 <exec_byte_code+1701>,
0x58a5a9 <exec_byte_code+1721>, 0x58a62e <exec_byte_code+1854>,
0x58a633 <exec_byte_code+1859>, 0x58a638 <exec_byte_code+1864>,
0x58a645 <exec_byte_code+1877>, 0x58a203 <exec_byte_code+787>,
0x58a208 <exec_byte_code+792>, 0x58a5f5 <exec_byte_code+1797>,
0x58a609 <exec_byte_code+1817>, 0x58a2f8 <exec_byte_code+1032>,
0x58a2f8 <exec_byte_code+1032>, 0x58a2f8 <exec_byte_code+1032>,
0x58a2f8 <exec_byte_code+1032>, 0x58a2f8 <exec_byte_code+1032>,
0x58a2f8 <exec_byte_code+1032>, 0x58a2f8 <exec_byte_code+1032>,
0x58a2f8 <exec_byte_code+1032>, 0x58ae64 <exec_byte_code+3956>,
0x58aef0 <exec_byte_code+4096>, 0x58af29 <exec_byte_code+4153>,
0x58af62 <exec_byte_code+4210>, 0x58af9b <exec_byte_code+4267>,
0x58a400 <exec_byte_code+1296>, 0x58a43d <exec_byte_code+1357>,
---Type <return> to continue, or q <return> to quit---
0x58afde <exec_byte_code+4334>, 0x58a3c4 <exec_byte_code+1236>,
0x58a474 <exec_byte_code+1412>, 0x58b011 <exec_byte_code+4385>,
0x58b048 <exec_byte_code+4440>, 0x58b078 <exec_byte_code+4488>,
0x58b0be <exec_byte_code+4558>, 0x58b0f4 <exec_byte_code+4612>,
0x58b16c <exec_byte_code+4732>, 0x58b195 <exec_byte_code+4773>,
0x58b1cc <exec_byte_code+4828>, 0x58b208 <exec_byte_code+4888>,
0x58b231 <exec_byte_code+4929>, 0x58b25a <exec_byte_code+4970>,
0x58b291 <exec_byte_code+5025>, 0x58b2c8 <exec_byte_code+5080>,
0x58b2ff <exec_byte_code+5135>, 0x58b33b <exec_byte_code+5195>,
0x58b371 <exec_byte_code+5249>, 0x58b3a7 <exec_byte_code+5303>,
0x58b41f <exec_byte_code+5423>, 0x58b459 <exec_byte_code+5481>,
0x58b493 <exec_byte_code+5539>, 0x58b51f <exec_byte_code+5679>,
0x58b556 <exec_byte_code+5734>, 0x58b58d <exec_byte_code+5789>,
0x58b5c4 <exec_byte_code+5844>, 0x58b5fb <exec_byte_code+5899>,
0x58b631 <exec_byte_code+5953>, 0x58b664 <exec_byte_code+6004>,
0x58b69a <exec_byte_code+6058>, 0x58b6d0 <exec_byte_code+6112>,
0x58b706 <exec_byte_code+6166>, 0x58b7a9 <exec_byte_code+6329>,
0x58a304 <exec_byte_code+1044>, 0x58b7e0 <exec_byte_code+6384>,
0x58b809 <exec_byte_code+6425>, 0x58b878 <exec_byte_code+6536>,
0x58b8af <exec_byte_code+6591>, 0x58b8e6 <exec_byte_code+6646>,
0x58b90f <exec_byte_code+6687>, 0x58b939 <exec_byte_code+6729>,
0x58b963 <exec_byte_code+6771>, 0x58b991 <exec_byte_code+6817>,
0x58a2f8 <exec_byte_code+1032>, 0x58b9c1 <exec_byte_code+6865>,
---Type <return> to continue, or q <return> to quit---
0x58b9ef <exec_byte_code+6911>, 0x58ba1d <exec_byte_code+6957>,
0x58ba4b <exec_byte_code+7003>, 0x58ba79 <exec_byte_code+7049>,
0x58baa7 <exec_byte_code+7095>, 0x58a304 <exec_byte_code+1044>,
0x58a2f8 <exec_byte_code+1032>, 0x58bad0 <exec_byte_code+7136>,
0x58bafe <exec_byte_code+7182>, 0x58bb27 <exec_byte_code+7223>,
0x58bb50 <exec_byte_code+7264>, 0x58bb87 <exec_byte_code+7319>,
0x58bbbe <exec_byte_code+7374>, 0x58bbe7 <exec_byte_code+7415>,
0x58bcb4 <exec_byte_code+7620>, 0x58be70 <exec_byte_code+8064>,
0x58bea7 <exec_byte_code+8119>, 0x58bede <exec_byte_code+8174>,
0x58bf0c <exec_byte_code+8220>, 0x58a2f8 <exec_byte_code+1032>,
0x58a84e <exec_byte_code+2398>, 0x58a681 <exec_byte_code+1937>,
0x58a346 <exec_byte_code+1110>, 0x58a71d <exec_byte_code+2093>,
0x58a7d3 <exec_byte_code+2275>, 0x58a9bc <exec_byte_code+2764>,
0x58ad13 <exec_byte_code+3619>, 0x58ad67 <exec_byte_code+3703>,
0x58a50e <exec_byte_code+1566>, 0x58a897 <exec_byte_code+2471>,
0x58a8c5 <exec_byte_code+2517>, 0x58a924 <exec_byte_code+2612>,
0x58a952 <exec_byte_code+2658>, 0x58a98e <exec_byte_code+2718>,
0x58ad87 <exec_byte_code+3735>, 0x58adc3 <exec_byte_code+3795>,
0x58ae06 <exec_byte_code+3862>, 0x58a655 <exec_byte_code+1893>,
0x58bceb <exec_byte_code+7675>, 0x58bd27 <exec_byte_code+7735>,
0x58bd50 <exec_byte_code+7776>, 0x58bd79 <exec_byte_code+7817>,
0x58bda2 <exec_byte_code+7858>, 0x58bdcb <exec_byte_code+7899>,
0x58be02 <exec_byte_code+7954>, 0x58be39 <exec_byte_code+8009>,
---Type <return> to continue, or q <return> to quit---
0x58c11b <exec_byte_code+8747>, 0x58c152 <exec_byte_code+8802>,
0x58c198 <exec_byte_code+8872>, 0x58c1cf <exec_byte_code+8927>,
0x58c206 <exec_byte_code+8982>, 0x58c22f <exec_byte_code+9023>,
0x58c266 <exec_byte_code+9078>, 0x58c29d <exec_byte_code+9133>,
0x58c2d7 <exec_byte_code+9191>, 0x58c37d <exec_byte_code+9357>,
0x58b73c <exec_byte_code+6220>, 0x58b772 <exec_byte_code+6274>,
0x58c316 <exec_byte_code+9254>, 0x58c349 <exec_byte_code+9305>,
0x58a2f8 <exec_byte_code+1032>, 0x58aa6f <exec_byte_code+2943>,
0x58aaf8 <exec_byte_code+3080>, 0x58ab67 <exec_byte_code+3191>,
0x58ac06 <exec_byte_code+3350>, 0x58ac76 <exec_byte_code+3462>,
0x58b12a <exec_byte_code+4666>, 0x58b3dd <exec_byte_code+5357>,
0x58b836 <exec_byte_code+6470>, 0x58c014 <exec_byte_code+8484>,
0x58c054 <exec_byte_code+8548>, 0x58a2f8 <exec_byte_code+1032>,
0x58a2f8 <exec_byte_code+1032>, 0x58c0a7 <exec_byte_code+8631>,
0x58a2f8 <exec_byte_code+1032>, 0x58a2f8 <exec_byte_code+1032>,
0x58a2f8 <exec_byte_code+1032>, 0x58a2f8 <exec_byte_code+1032>,
0x58a2f8 <exec_byte_code+1032>, 0x58a2f8 <exec_byte_code+1032>,
0x58a2f8 <exec_byte_code+1032>, 0x58a2f8 <exec_byte_code+1032>,
0x58a2f8 <exec_byte_code+1032>,
0x58c0ee <exec_byte_code+8702> <repeats 64 times>}
stack = {
pc = 0xa6e167 <pure+2364039> "\207",
byte_string = 9882865,
---Type <return> to continue, or q <return> to quit---
byte_string_start = 0xa6e14f <pure+2364015> "\303\304\b\305\306$\210\t\203\025",
constants = 9882901,
next = 0x7fffffffa030
}
result = 12067362
#11 0x0000000000554491 in funcall_lambda (fun=9882765, nargs=nargs@entry=2,
arg_vector=arg_vector@entry=0x7fffffff9fd0) at eval.c:3010
val = <optimized out>
syms_left = 12067362
next = <optimized out>
lexenv = 12067362
count = 29
i = <optimized out>
optional = <optimized out>
rest = <optimized out>
#12 0x00000000005547bb in Ffuncall (nargs=3, args=0x7fffffff9fc8)
at eval.c:2839
fun = <optimized out>
original_fun = 15482034
funcar = <optimized out>
numargs = 2
lisp_numargs = <optimized out>
...
In GNU Emacs 24.2.93.1 (x86_64-unknown-linux-gnu, GTK+ Version 3.6.0)
of 2013-02-18 on vbx
Bzr revision: 111274 eliz@gnu.org-20130217181734-8yalkg5ebeud6hkx
Windowing system distributor `The X.Org Foundation', version 11.0.11300000
System Description: Ubuntu 12.10
^ permalink raw reply [flat|nested] 34+ messages in thread
* bug#13743: 24.2.93; Segmentation fault when trying to [s]teal a file opened elsewhere
2013-02-18 6:41 bug#13743: 24.2.93; Segmentation fault when trying to [s]teal a file opened elsewhere Dmitry Gutov
@ 2013-02-18 16:11 ` Eli Zaretskii
2013-02-19 0:52 ` Dmitry Gutov
2013-02-18 19:35 ` Glenn Morris
2013-02-21 5:16 ` Paul Eggert
2 siblings, 1 reply; 34+ messages in thread
From: Eli Zaretskii @ 2013-02-18 16:11 UTC (permalink / raw)
To: Dmitry Gutov; +Cc: 13743
> From: Dmitry Gutov <dgutov@yandex.ru>
> Date: Mon, 18 Feb 2013 10:41:31 +0400
>
> Emacs reliably crashes when [s]tealing a file that's opened in another
> instance. I can only reproduce this when the buffer opens in mmm-mode
> (so the bug may be related to indirect buffers), and apparently mmm-mode
> modifies the buffer in some way automatically, so the prompt to
> steal/proceed/quit is shown as soon as I open the file.
>
> I think this is the first situation I've seen Emacs crash, in quite a
> while.
>
>
> (gdb) xbacktrace
> "put-text-property" (0xffff9a20)
> "jit-lock-refontify" (0xffff9c00)
> "jit-lock-mode" (0xffff9e00)
> "jit-lock-register" (0xffff9fd0)
> "font-lock-turn-on-thing-lock" (0xffffa1b0)
> "font-lock-mode-internal" (0xffffa380)
> "font-lock-default-function" (0xffffa550)
> "font-lock-mode" (0xffffa720)
> "turn-on-font-lock" (0xffffa8d0)
> "turn-on-font-lock-if-desired" (0xffffaa90)
> "global-font-lock-mode-enable-in-buffers" (0xffffaca8)
> "run-hooks" (0xffffad68)
> "apply" (0xffffaec0)
> "run-mode-hooks" (0xffffaff0)
> "html-erb-mode" (0xffffb2a8)
> "funcall" (0xffffb2a0)
> "save-current-buffer" (0xffffb418)
> "unwind-protect" (0xffffb538)
> "let" (0xffffb6d8)
> "if" (0xffffb7e8)
> "let" (0xffffb9a8)
> "mmm-update-mode-info" (0xffffbaf0)
> "if" (0xffffbcc8)
> ---Type <return> to continue, or q <return> to quit---
> "if" (0xffffbdd8)
> "mmm-mode-on" (0xffffbf20)
> "cond" (0xffffc0e8)
> "mmm-mode-on-maybe" (0xffffc2d8)
> "funcall" (0xffffc2d0)
> "progn" (0xffffc428)
> "condition-case" (0xffffc6a8)
> "while" (0xffffc7d8)
> "let" (0xffffc978)
> "progn" (0xffffca88)
> "mmm-run-major-mode-hook" (0xffffcbd0)
> "save-current-buffer" (0xffffcdb8)
> "progn" (0xffffcec8)
> "if" (0xffffcfc8)
> "while" (0xffffd0f8)
> "let" (0xffffd298)
> "progn" (0xffffd3a8)
> "mmm-check-changed-buffers" (0xffffd590)
> (gdb)
>
> ===
>
> bt full is too long for my terminal, so here's the top. Let me know if
> it's not enough, I'll try to increase the history limit or whatever.
>
> (gdb) bt full
> #0 add_properties (plist=plist@entry=31577430, i=i@entry=0x0,
> object=object@entry=12438597) at textprop.c:378
> tail1 = 31577430
> tail2 = <optimized out>
> sym1 = 12306530
> val1 = 12067362
> changed = <optimized out>
> found = 0
Can you recompile without optimizations, and show the backtrace from
that build? Thanks.
^ permalink raw reply [flat|nested] 34+ messages in thread
* bug#13743: 24.2.93; Segmentation fault when trying to [s]teal a file opened elsewhere
2013-02-18 6:41 bug#13743: 24.2.93; Segmentation fault when trying to [s]teal a file opened elsewhere Dmitry Gutov
2013-02-18 16:11 ` Eli Zaretskii
@ 2013-02-18 19:35 ` Glenn Morris
2013-02-19 0:55 ` Dmitry Gutov
2013-02-21 5:16 ` Paul Eggert
2 siblings, 1 reply; 34+ messages in thread
From: Glenn Morris @ 2013-02-18 19:35 UTC (permalink / raw)
To: Dmitry Gutov; +Cc: 13743
Dmitry Gutov wrote:
> Emacs reliably crashes when [s]tealing a file that's opened in another
> instance.
The inevitable question: does this happen with older Emacs versions too?
In particular pre 24.1?
> In GNU Emacs 24.2.93.1 (x86_64-unknown-linux-gnu, GTK+ Version 3.6.0)
> of 2013-02-18 on vbx
^ permalink raw reply [flat|nested] 34+ messages in thread
* bug#13743: 24.2.93; Segmentation fault when trying to [s]teal a file opened elsewhere
2013-02-18 16:11 ` Eli Zaretskii
@ 2013-02-19 0:52 ` Dmitry Gutov
2013-02-20 19:31 ` Eli Zaretskii
0 siblings, 1 reply; 34+ messages in thread
From: Dmitry Gutov @ 2013-02-19 0:52 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: 13743
On 18.02.2013 20:11, Eli Zaretskii wrote:
> Can you recompile without optimizations, and show the backtrace from
> that build? Thanks.
Here you go:
Program received signal SIGSEGV, Segmentation fault.
0x0000000000653481 in add_properties (plist=32025878, i=0x0,
object=31976325)
at textprop.c:378
378 for (tail2 = i->plist; CONSP (tail2); tail2 = Fcdr (XCDR (tail2)))
(gdb) bt full
#0 0x0000000000653481 in add_properties (plist=32025878, i=0x0,
object=31976325) at textprop.c:378
tail1 = 32025878
tail2 = 31873526
sym1 = 13125730
val1 = 12886562
changed = 0
found = 0
gcpro1 = {
next = 0x7fffffff6180,
var = 0x57dc19 <modify_region+481>,
nvars = 4295010134
}
gcpro2 = {
next = 0x7fffffff6180,
var = 0x57dc19 <modify_region+481>,
nvars = 4295010134
}
gcpro3 = {
next = 0x7fffffff6180,
var = 0x57dc19 <modify_region+481>,
nvars = 4295010134
}
---Type <return> to continue, or q <return> to quit---
#1 0x0000000000655963 in Fadd_text_properties (start=4, end=3068,
properties=32025878, object=31976325) at textprop.c:1212
i = 0x0
unchanged = 0x7fffffffa568
s = 1
len = 558
modified = 19
gcpro1 = {
next = 0xa31e4d <pure+1297709>,
var = 0xa31e29 <pure+1297673>,
nvars = 579820584989
}
#2 0x00000000006559e0 in Fput_text_property (start=4, end=3068,
property=13125730, value=12886562, object=12886562) at textprop.c:1229
No locals.
#3 0x00000000005e6cc9 in Ffuncall (nargs=5, args=0x7fffffff6368)
at eval.c:2794
fun = 12265781
original_fun = 13073714
funcar = 12706944
numargs = 4
lisp_numargs = 31976320
val = -4294966896
---Type <return> to continue, or q <return> to quit---
backtrace = {
next = 0x7fffffff6820,
function = 13073714,
args = 0x7fffffff6370,
nargs = 4,
debug_on_exit = 0
}
internal_args = 0x7fffffff6270
i = 5
#4 0x000000000062fd90 in exec_byte_code (bytestr=10703001,
vector=10703037,
maxdepth=24, args_template=12886562, nargs=0, args=0x0) at
bytecode.c:900
targets = {0x633680 <exec_byte_code+17815>,
0x63368f <exec_byte_code+17830>, 0x633691
<exec_byte_code+17832>,
0x633693 <exec_byte_code+17834>, 0x633695
<exec_byte_code+17836>,
0x633695 <exec_byte_code+17836>, 0x6336ff
<exec_byte_code+17942>,
0x633773 <exec_byte_code+18058>, 0x62f608 <exec_byte_code+1311>,
0x62f60a <exec_byte_code+1313>, 0x62f60c <exec_byte_code+1315>,
0x62f60e <exec_byte_code+1317>, 0x62f610 <exec_byte_code+1319>,
0x62f610 <exec_byte_code+1319>, 0x62f619 <exec_byte_code+1328>,
0x62f5d3 <exec_byte_code+1258>, 0x62fa8c <exec_byte_code+2467>,
0x62fa8e <exec_byte_code+2469>, 0x62fa90 <exec_byte_code+2471>,
0x62fa92 <exec_byte_code+2473>, 0x62fa94 <exec_byte_code+2475>,
0x62fa94 <exec_byte_code+2475>, 0x62fad2 <exec_byte_code+2537>,
---Type <return> to continue, or q <return> to quit---
0x62fa9d <exec_byte_code+2484>, 0x62fc85 <exec_byte_code+2972>,
0x62fc87 <exec_byte_code+2974>, 0x62fc89 <exec_byte_code+2976>,
0x62fc8b <exec_byte_code+2978>, 0x62fc8d <exec_byte_code+2980>,
0x62fc8d <exec_byte_code+2980>, 0x62fc36 <exec_byte_code+2893>,
0x62fc50 <exec_byte_code+2919>, 0x62fd4e <exec_byte_code+3173>,
0x62fd50 <exec_byte_code+3175>, 0x62fd52 <exec_byte_code+3177>,
0x62fd54 <exec_byte_code+3179>, 0x62fd56 <exec_byte_code+3181>,
0x62fd56 <exec_byte_code+3181>, 0x62fcff <exec_byte_code+3094>,
0x62fd19 <exec_byte_code+3120>, 0x62fe1a <exec_byte_code+3377>,
0x62fe1c <exec_byte_code+3379>, 0x62fe1e <exec_byte_code+3381>,
0x62fe20 <exec_byte_code+3383>, 0x62fe22 <exec_byte_code+3385>,
0x62fe22 <exec_byte_code+3385>, 0x62fdcb <exec_byte_code+3298>,
0x62fde5 <exec_byte_code+3324>, 0x633680 <exec_byte_code+17815>,
0x633680 <exec_byte_code+17815>, 0x633680
<exec_byte_code+17815>,
0x633680 <exec_byte_code+17815>, 0x633680
<exec_byte_code+17815>,
0x633680 <exec_byte_code+17815>, 0x633680
<exec_byte_code+17815>,
0x633680 <exec_byte_code+17815>, 0x630e06 <exec_byte_code+7453>,
0x630f3a <exec_byte_code+7761>, 0x630f97 <exec_byte_code+7854>,
0x630ff4 <exec_byte_code+7947>, 0x631051 <exec_byte_code+8040>,
0x62f8fd <exec_byte_code+2068>, 0x62f974 <exec_byte_code+2187>,
0x6310c4 <exec_byte_code+8155>, 0x62f856 <exec_byte_code+1901>,
0x62f9e4 <exec_byte_code+2299>, 0x631125 <exec_byte_code+8252>,
0x631195 <exec_byte_code+8364>, 0x6311ec <exec_byte_code+8451>,
---Type <return> to continue, or q <return> to quit---
0x631271 <exec_byte_code+8584>, 0x6312c8 <exec_byte_code+8671>,
0x6313ac <exec_byte_code+8899>, 0x6313f9 <exec_byte_code+8976>,
0x631469 <exec_byte_code+9088>, 0x6314f9 <exec_byte_code+9232>,
0x631546 <exec_byte_code+9309>, 0x631593 <exec_byte_code+9386>,
0x631603 <exec_byte_code+9498>, 0x631673 <exec_byte_code+9610>,
0x6316e3 <exec_byte_code+9722>, 0x631773 <exec_byte_code+9866>,
0x6317ca <exec_byte_code+9953>, 0x631821 <exec_byte_code+10040>,
0x631905 <exec_byte_code+10268>, 0x63199b
<exec_byte_code+10418>,
0x631a31 <exec_byte_code+10568>, 0x631c9a
<exec_byte_code+11185>,
0x631d0a <exec_byte_code+11297>, 0x631d7a
<exec_byte_code+11409>,
0x631dea <exec_byte_code+11521>, 0x631e5a
<exec_byte_code+11633>,
0x631eb1 <exec_byte_code+11720>, 0x631f4b
<exec_byte_code+11874>,
0x631fa2 <exec_byte_code+11961>, 0x631ff9
<exec_byte_code+12048>,
0x632050 <exec_byte_code+12135>, 0x63216e
<exec_byte_code+12421>,
0x630a71 <exec_byte_code+6536>, 0x6321d1 <exec_byte_code+12520>,
0x63221e <exec_byte_code+12597>, 0x6322fa
<exec_byte_code+12817>,
0x63235d <exec_byte_code+12916>, 0x6323c0
<exec_byte_code+13015>,
0x63240d <exec_byte_code+13092>, 0x632463
<exec_byte_code+13178>,
0x6324b9 <exec_byte_code+13264>, 0x632513
<exec_byte_code+13354>,
0x633680 <exec_byte_code+17815>, 0x63256a
<exec_byte_code+13441>,
0x6325b2 <exec_byte_code+13513>, 0x6325fa
<exec_byte_code+13585>,
0x632642 <exec_byte_code+13657>, 0x63268a
<exec_byte_code+13729>,
0x6326d2 <exec_byte_code+13801>, 0x630a71 <exec_byte_code+6536>,
---Type <return> to continue, or q <return> to quit---
0x633680 <exec_byte_code+17815>, 0x63271f
<exec_byte_code+13878>,
0x632767 <exec_byte_code+13950>, 0x6327b4
<exec_byte_code+14027>,
0x632801 <exec_byte_code+14104>, 0x632871
<exec_byte_code+14216>,
0x6328e1 <exec_byte_code+14328>, 0x63292e
<exec_byte_code+14405>,
0x632b91 <exec_byte_code+15016>, 0x632c01
<exec_byte_code+15128>,
0x632c71 <exec_byte_code+15240>, 0x632ce1
<exec_byte_code+15352>,
0x632d29 <exec_byte_code+15424>, 0x633680
<exec_byte_code+17815>,
0x63099c <exec_byte_code+6323>, 0x62fee9 <exec_byte_code+3584>,
0x62f717 <exec_byte_code+1582>, 0x62fffb <exec_byte_code+3858>,
0x63013a <exec_byte_code+4177>, 0x630270 <exec_byte_code+4487>,
0x630907 <exec_byte_code+6174>, 0x630963 <exec_byte_code+6266>,
0x62fbdb <exec_byte_code+2802>, 0x630a2e <exec_byte_code+6469>,
0x630aa7 <exec_byte_code+6590>, 0x630b46 <exec_byte_code+6749>,
0x630b89 <exec_byte_code+6816>, 0x630bfb <exec_byte_code+6930>,
0x630c4b <exec_byte_code+7010>, 0x630cdb <exec_byte_code+7154>,
0x630d65 <exec_byte_code+7292>, 0x62fe9f <exec_byte_code+3510>,
0x632d76 <exec_byte_code+15501>, 0x632e06
<exec_byte_code+15645>,
0x632e53 <exec_byte_code+15722>, 0x632ea0
<exec_byte_code+15799>,
0x632eed <exec_byte_code+15876>, 0x632f3a
<exec_byte_code+15953>,
0x632faa <exec_byte_code+16065>, 0x63301a
<exec_byte_code+16177>,
0x63308a <exec_byte_code+16289>, 0x6330fa
<exec_byte_code+16401>,
0x633285 <exec_byte_code+16796>, 0x6332f5
<exec_byte_code+16908>,
0x633365 <exec_byte_code+17020>, 0x6333b2
<exec_byte_code+17097>,
---Type <return> to continue, or q <return> to quit---
0x633422 <exec_byte_code+17209>, 0x63348c
<exec_byte_code+17315>,
0x6334f5 <exec_byte_code+17420>, 0x63355f
<exec_byte_code+17526>,
0x6320a7 <exec_byte_code+12222>, 0x6320fe
<exec_byte_code+12309>,
0x6335b6 <exec_byte_code+17613>, 0x633624
<exec_byte_code+17723>,
0x633680 <exec_byte_code+17815>, 0x6303a6 <exec_byte_code+4797>,
0x63048b <exec_byte_code+5026>, 0x6305a9 <exec_byte_code+5312>,
0x6306c7 <exec_byte_code+5598>, 0x6307e7 <exec_byte_code+5886>,
0x63131f <exec_byte_code+8758>, 0x631878 <exec_byte_code+10127>,
0x63226d <exec_byte_code+12676>, 0x63380f
<exec_byte_code+18214>,
0x633883 <exec_byte_code+18330>, 0x633680
<exec_byte_code+17815>,
0x633680 <exec_byte_code+17815>, 0x63391f
<exec_byte_code+18486>,
0x633680 <exec_byte_code+17815>, 0x633680
<exec_byte_code+17815>,
0x633680 <exec_byte_code+17815>, 0x633680
<exec_byte_code+17815>,
0x633680 <exec_byte_code+17815>, 0x633680
<exec_byte_code+17815>,
0x633680 <exec_byte_code+17815>, 0x633680
<exec_byte_code+17815>,
0x633680 <exec_byte_code+17815>,
0x6339bd <exec_byte_code+18644> <repeats 64 times>}
count = 34
op = 4
vectorp = 0xa350c8 <pure+1310632>
stack = {
pc = 0xb3637b <pure+2363995> ".\n\207",
byte_string = 10703001,
---Type <return> to continue, or q <return> to quit---
byte_string_start = 0xb36353 <pure+2363955> "\306\030\307
\031\032\033\306\034\035\036\f\310\036\r\214~\210\312\016\016\206\037",
constants = 10703037,
next = 0x7fffffff6c20
}
top = 0x7fffffff6368
result = 140737488315744
#5 0x00000000005e7609 in funcall_lambda (fun=10702949, nargs=0,
arg_vector=0x7fffffff6880) at eval.c:3010
val = 17086304
syms_left = 12886562
next = 16218994
lexenv = 12886562
count = 32
i = 0
optional = true
rest = false
#6 0x00000000005e6e09 in Ffuncall (nargs=1, args=0x7fffffff6878)
at eval.c:2827
fun = 10702949
original_fun = 20632738
funcar = 20632546
numargs = 0
---Type <return> to continue, or q <return> to quit---
lisp_numargs = 12886610
val = 140737488316512
backtrace = {
next = 0x7fffffff6d50,
function = 20632738,
args = 0x7fffffff6880,
nargs = 0,
debug_on_exit = 0
}
internal_args = 0x7fffffff6db0
i = 6072020
#7 0x000000000062fd90 in exec_byte_code (bytestr=10702057,
vector=10702093,
maxdepth=44, args_template=12886562, nargs=0, args=0x0) at
bytecode.c:900
targets = {0x633680 <exec_byte_code+17815>,
0x63368f <exec_byte_code+17830>, 0x633691
<exec_byte_code+17832>,
0x633693 <exec_byte_code+17834>, 0x633695
<exec_byte_code+17836>,
0x633695 <exec_byte_code+17836>, 0x6336ff
<exec_byte_code+17942>,
0x633773 <exec_byte_code+18058>, 0x62f608 <exec_byte_code+1311>,
0x62f60a <exec_byte_code+1313>, 0x62f60c <exec_byte_code+1315>,
0x62f60e <exec_byte_code+1317>, 0x62f610 <exec_byte_code+1319>,
0x62f610 <exec_byte_code+1319>, 0x62f619 <exec_byte_code+1328>,
0x62f5d3 <exec_byte_code+1258>, 0x62fa8c <exec_byte_code+2467>,
0x62fa8e <exec_byte_code+2469>, 0x62fa90 <exec_byte_code+2471>,
---Type <return> to continue, or q <return> to quit---
0x62fa92 <exec_byte_code+2473>, 0x62fa94 <exec_byte_code+2475>,
0x62fa94 <exec_byte_code+2475>, 0x62fad2 <exec_byte_code+2537>,
0x62fa9d <exec_byte_code+2484>, 0x62fc85 <exec_byte_code+2972>,
0x62fc87 <exec_byte_code+2974>, 0x62fc89 <exec_byte_code+2976>,
0x62fc8b <exec_byte_code+2978>, 0x62fc8d <exec_byte_code+2980>,
0x62fc8d <exec_byte_code+2980>, 0x62fc36 <exec_byte_code+2893>,
0x62fc50 <exec_byte_code+2919>, 0x62fd4e <exec_byte_code+3173>,
0x62fd50 <exec_byte_code+3175>, 0x62fd52 <exec_byte_code+3177>,
0x62fd54 <exec_byte_code+3179>, 0x62fd56 <exec_byte_code+3181>,
0x62fd56 <exec_byte_code+3181>, 0x62fcff <exec_byte_code+3094>,
0x62fd19 <exec_byte_code+3120>, 0x62fe1a <exec_byte_code+3377>,
0x62fe1c <exec_byte_code+3379>, 0x62fe1e <exec_byte_code+3381>,
0x62fe20 <exec_byte_code+3383>, 0x62fe22 <exec_byte_code+3385>,
0x62fe22 <exec_byte_code+3385>, 0x62fdcb <exec_byte_code+3298>,
0x62fde5 <exec_byte_code+3324>, 0x633680 <exec_byte_code+17815>,
0x633680 <exec_byte_code+17815>, 0x633680
<exec_byte_code+17815>,
0x633680 <exec_byte_code+17815>, 0x633680
<exec_byte_code+17815>,
0x633680 <exec_byte_code+17815>, 0x633680
<exec_byte_code+17815>,
0x633680 <exec_byte_code+17815>, 0x630e06 <exec_byte_code+7453>,
0x630f3a <exec_byte_code+7761>, 0x630f97 <exec_byte_code+7854>,
0x630ff4 <exec_byte_code+7947>, 0x631051 <exec_byte_code+8040>,
0x62f8fd <exec_byte_code+2068>, 0x62f974 <exec_byte_code+2187>,
0x6310c4 <exec_byte_code+8155>, 0x62f856 <exec_byte_code+1901>,
---Type <return> to continue, or q <return> to quit---
0x62f9e4 <exec_byte_code+2299>, 0x631125 <exec_byte_code+8252>,
0x631195 <exec_byte_code+8364>, 0x6311ec <exec_byte_code+8451>,
0x631271 <exec_byte_code+8584>, 0x6312c8 <exec_byte_code+8671>,
0x6313ac <exec_byte_code+8899>, 0x6313f9 <exec_byte_code+8976>,
0x631469 <exec_byte_code+9088>, 0x6314f9 <exec_byte_code+9232>,
0x631546 <exec_byte_code+9309>, 0x631593 <exec_byte_code+9386>,
0x631603 <exec_byte_code+9498>, 0x631673 <exec_byte_code+9610>,
0x6316e3 <exec_byte_code+9722>, 0x631773 <exec_byte_code+9866>,
0x6317ca <exec_byte_code+9953>, 0x631821 <exec_byte_code+10040>,
0x631905 <exec_byte_code+10268>, 0x63199b
<exec_byte_code+10418>,
0x631a31 <exec_byte_code+10568>, 0x631c9a
<exec_byte_code+11185>,
0x631d0a <exec_byte_code+11297>, 0x631d7a
<exec_byte_code+11409>,
0x631dea <exec_byte_code+11521>, 0x631e5a
<exec_byte_code+11633>,
0x631eb1 <exec_byte_code+11720>, 0x631f4b
<exec_byte_code+11874>,
0x631fa2 <exec_byte_code+11961>, 0x631ff9
<exec_byte_code+12048>,
0x632050 <exec_byte_code+12135>, 0x63216e
<exec_byte_code+12421>,
0x630a71 <exec_byte_code+6536>, 0x6321d1 <exec_byte_code+12520>,
0x63221e <exec_byte_code+12597>, 0x6322fa
<exec_byte_code+12817>,
0x63235d <exec_byte_code+12916>, 0x6323c0
<exec_byte_code+13015>,
0x63240d <exec_byte_code+13092>, 0x632463
<exec_byte_code+13178>,
0x6324b9 <exec_byte_code+13264>, 0x632513
<exec_byte_code+13354>,
0x633680 <exec_byte_code+17815>, 0x63256a
<exec_byte_code+13441>,
0x6325b2 <exec_byte_code+13513>, 0x6325fa
<exec_byte_code+13585>,
---Type <return> to continue, or q <return> to quit---
0x632642 <exec_byte_code+13657>, 0x63268a
<exec_byte_code+13729>,
0x6326d2 <exec_byte_code+13801>, 0x630a71 <exec_byte_code+6536>,
0x633680 <exec_byte_code+17815>, 0x63271f
<exec_byte_code+13878>,
0x632767 <exec_byte_code+13950>, 0x6327b4
<exec_byte_code+14027>,
0x632801 <exec_byte_code+14104>, 0x632871
<exec_byte_code+14216>,
0x6328e1 <exec_byte_code+14328>, 0x63292e
<exec_byte_code+14405>,
0x632b91 <exec_byte_code+15016>, 0x632c01
<exec_byte_code+15128>,
0x632c71 <exec_byte_code+15240>, 0x632ce1
<exec_byte_code+15352>,
0x632d29 <exec_byte_code+15424>, 0x633680
<exec_byte_code+17815>,
0x63099c <exec_byte_code+6323>, 0x62fee9 <exec_byte_code+3584>,
0x62f717 <exec_byte_code+1582>, 0x62fffb <exec_byte_code+3858>,
0x63013a <exec_byte_code+4177>, 0x630270 <exec_byte_code+4487>,
0x630907 <exec_byte_code+6174>, 0x630963 <exec_byte_code+6266>,
0x62fbdb <exec_byte_code+2802>, 0x630a2e <exec_byte_code+6469>,
0x630aa7 <exec_byte_code+6590>, 0x630b46 <exec_byte_code+6749>,
0x630b89 <exec_byte_code+6816>, 0x630bfb <exec_byte_code+6930>,
0x630c4b <exec_byte_code+7010>, 0x630cdb <exec_byte_code+7154>,
0x630d65 <exec_byte_code+7292>, 0x62fe9f <exec_byte_code+3510>,
0x632d76 <exec_byte_code+15501>, 0x632e06
<exec_byte_code+15645>,
0x632e53 <exec_byte_code+15722>, 0x632ea0
<exec_byte_code+15799>,
0x632eed <exec_byte_code+15876>, 0x632f3a
<exec_byte_code+15953>,
0x632faa <exec_byte_code+16065>, 0x63301a
<exec_byte_code+16177>,
0x63308a <exec_byte_code+16289>, 0x6330fa
<exec_byte_code+16401>,
---Type <return> to continue, or q <return> to quit---
0x633285 <exec_byte_code+16796>, 0x6332f5
<exec_byte_code+16908>,
0x633365 <exec_byte_code+17020>, 0x6333b2
<exec_byte_code+17097>,
0x633422 <exec_byte_code+17209>, 0x63348c
<exec_byte_code+17315>,
0x6334f5 <exec_byte_code+17420>, 0x63355f
<exec_byte_code+17526>,
0x6320a7 <exec_byte_code+12222>, 0x6320fe
<exec_byte_code+12309>,
0x6335b6 <exec_byte_code+17613>, 0x633624
<exec_byte_code+17723>,
0x633680 <exec_byte_code+17815>, 0x6303a6 <exec_byte_code+4797>,
0x63048b <exec_byte_code+5026>, 0x6305a9 <exec_byte_code+5312>,
0x6306c7 <exec_byte_code+5598>, 0x6307e7 <exec_byte_code+5886>,
0x63131f <exec_byte_code+8758>, 0x631878 <exec_byte_code+10127>,
0x63226d <exec_byte_code+12676>, 0x63380f
<exec_byte_code+18214>,
0x633883 <exec_byte_code+18330>, 0x633680
<exec_byte_code+17815>,
0x633680 <exec_byte_code+17815>, 0x63391f
<exec_byte_code+18486>,
0x633680 <exec_byte_code+17815>, 0x633680
<exec_byte_code+17815>,
0x633680 <exec_byte_code+17815>, 0x633680
<exec_byte_code+17815>,
0x633680 <exec_byte_code+17815>, 0x633680
<exec_byte_code+17815>,
0x633680 <exec_byte_code+17815>, 0x633680
<exec_byte_code+17815>,
0x633680 <exec_byte_code+17815>,
0x6339bd <exec_byte_code+18644> <repeats 64 times>}
count = 32
op = 0
vectorp = 0xa34d18 <pure+1309688>
stack = {
---Type <return> to continue, or q <return> to quit---
pc = 0xb363e1 <pure+2364097> "\210\n\203\027",
byte_string = 10702057,
byte_string_start = 0xb363d9 <pure+2364089> "\b\211\021\203j",
constants = 10702093,
next = 0x7fffffff7120
}
top = 0x7fffffff6878
result = 32026406
#8 0x00000000005e7609 in funcall_lambda (fun=10702005, nargs=1,
arg_vector=0x7fffffff6db0) at eval.c:3010
val = 32026406
syms_left = 12886562
next = 16205330
lexenv = 12886562
count = 31
i = 1
optional = false
rest = false
#9 0x00000000005e6e09 in Ffuncall (nargs=2, args=0x7fffffff6da8)
at eval.c:2827
fun = 10702005
original_fun = 20632546
funcar = 20657074
---Type <return> to continue, or q <return> to quit---
numargs = 1
lisp_numargs = 12886610
val = 140737488317840
backtrace = {
next = 0x7fffffff7250,
function = 20632546,
args = 0x7fffffff6db0,
nargs = 1,
debug_on_exit = 0
}
internal_args = 0x7fffffff72b0
i = 6072020
#10 0x000000000062fd90 in exec_byte_code (bytestr=10702641,
vector=10702677,
maxdepth=20, args_template=12886562, nargs=0, args=0x0) at
bytecode.c:900
targets = {0x633680 <exec_byte_code+17815>,
0x63368f <exec_byte_code+17830>, 0x633691
<exec_byte_code+17832>,
0x633693 <exec_byte_code+17834>, 0x633695
<exec_byte_code+17836>,
0x633695 <exec_byte_code+17836>, 0x6336ff
<exec_byte_code+17942>,
0x633773 <exec_byte_code+18058>, 0x62f608 <exec_byte_code+1311>,
0x62f60a <exec_byte_code+1313>, 0x62f60c <exec_byte_code+1315>,
0x62f60e <exec_byte_code+1317>, 0x62f610 <exec_byte_code+1319>,
0x62f610 <exec_byte_code+1319>, 0x62f619 <exec_byte_code+1328>,
0x62f5d3 <exec_byte_code+1258>, 0x62fa8c <exec_byte_code+2467>,
---Type <return> to continue, or q <return> to quit---
0x62fa8e <exec_byte_code+2469>, 0x62fa90 <exec_byte_code+2471>,
0x62fa92 <exec_byte_code+2473>, 0x62fa94 <exec_byte_code+2475>,
0x62fa94 <exec_byte_code+2475>, 0x62fad2 <exec_byte_code+2537>,
0x62fa9d <exec_byte_code+2484>, 0x62fc85 <exec_byte_code+2972>,
0x62fc87 <exec_byte_code+2974>, 0x62fc89 <exec_byte_code+2976>,
0x62fc8b <exec_byte_code+2978>, 0x62fc8d <exec_byte_code+2980>,
0x62fc8d <exec_byte_code+2980>, 0x62fc36 <exec_byte_code+2893>,
0x62fc50 <exec_byte_code+2919>, 0x62fd4e <exec_byte_code+3173>,
0x62fd50 <exec_byte_code+3175>, 0x62fd52 <exec_byte_code+3177>,
0x62fd54 <exec_byte_code+3179>, 0x62fd56 <exec_byte_code+3181>,
0x62fd56 <exec_byte_code+3181>, 0x62fcff <exec_byte_code+3094>,
0x62fd19 <exec_byte_code+3120>, 0x62fe1a <exec_byte_code+3377>,
0x62fe1c <exec_byte_code+3379>, 0x62fe1e <exec_byte_code+3381>,
0x62fe20 <exec_byte_code+3383>, 0x62fe22 <exec_byte_code+3385>,
0x62fe22 <exec_byte_code+3385>, 0x62fdcb <exec_byte_code+3298>,
0x62fde5 <exec_byte_code+3324>, 0x633680 <exec_byte_code+17815>,
0x633680 <exec_byte_code+17815>, 0x633680
<exec_byte_code+17815>,
0x633680 <exec_byte_code+17815>, 0x633680
<exec_byte_code+17815>,
0x633680 <exec_byte_code+17815>, 0x633680
<exec_byte_code+17815>,
0x633680 <exec_byte_code+17815>, 0x630e06 <exec_byte_code+7453>,
0x630f3a <exec_byte_code+7761>, 0x630f97 <exec_byte_code+7854>,
0x630ff4 <exec_byte_code+7947>, 0x631051 <exec_byte_code+8040>,
0x62f8fd <exec_byte_code+2068>, 0x62f974 <exec_byte_code+2187>,
---Type <return> to continue, or q <return> to quit---
0x6310c4 <exec_byte_code+8155>, 0x62f856 <exec_byte_code+1901>,
0x62f9e4 <exec_byte_code+2299>, 0x631125 <exec_byte_code+8252>,
0x631195 <exec_byte_code+8364>, 0x6311ec <exec_byte_code+8451>,
0x631271 <exec_byte_code+8584>, 0x6312c8 <exec_byte_code+8671>,
0x6313ac <exec_byte_code+8899>, 0x6313f9 <exec_byte_code+8976>,
0x631469 <exec_byte_code+9088>, 0x6314f9 <exec_byte_code+9232>,
0x631546 <exec_byte_code+9309>, 0x631593 <exec_byte_code+9386>,
0x631603 <exec_byte_code+9498>, 0x631673 <exec_byte_code+9610>,
0x6316e3 <exec_byte_code+9722>, 0x631773 <exec_byte_code+9866>,
0x6317ca <exec_byte_code+9953>, 0x631821 <exec_byte_code+10040>,
0x631905 <exec_byte_code+10268>, 0x63199b
<exec_byte_code+10418>,
0x631a31 <exec_byte_code+10568>, 0x631c9a
<exec_byte_code+11185>,
0x631d0a <exec_byte_code+11297>, 0x631d7a
<exec_byte_code+11409>,
0x631dea <exec_byte_code+11521>, 0x631e5a
<exec_byte_code+11633>,
0x631eb1 <exec_byte_code+11720>, 0x631f4b
<exec_byte_code+11874>,
0x631fa2 <exec_byte_code+11961>, 0x631ff9
<exec_byte_code+12048>,
0x632050 <exec_byte_code+12135>, 0x63216e
<exec_byte_code+12421>,
0x630a71 <exec_byte_code+6536>, 0x6321d1 <exec_byte_code+12520>,
0x63221e <exec_byte_code+12597>, 0x6322fa
<exec_byte_code+12817>,
0x63235d <exec_byte_code+12916>, 0x6323c0
<exec_byte_code+13015>,
0x63240d <exec_byte_code+13092>, 0x632463
<exec_byte_code+13178>,
0x6324b9 <exec_byte_code+13264>, 0x632513
<exec_byte_code+13354>,
0x633680 <exec_byte_code+17815>, 0x63256a
<exec_byte_code+13441>,
---Type <return> to continue, or q <return> to quit---
0x6325b2 <exec_byte_code+13513>, 0x6325fa
<exec_byte_code+13585>,
0x632642 <exec_byte_code+13657>, 0x63268a
<exec_byte_code+13729>,
0x6326d2 <exec_byte_code+13801>, 0x630a71 <exec_byte_code+6536>,
0x633680 <exec_byte_code+17815>, 0x63271f
<exec_byte_code+13878>,
0x632767 <exec_byte_code+13950>, 0x6327b4
<exec_byte_code+14027>,
0x632801 <exec_byte_code+14104>, 0x632871
<exec_byte_code+14216>,
0x6328e1 <exec_byte_code+14328>, 0x63292e
<exec_byte_code+14405>,
0x632b91 <exec_byte_code+15016>, 0x632c01
<exec_byte_code+15128>,
0x632c71 <exec_byte_code+15240>, 0x632ce1
<exec_byte_code+15352>,
0x632d29 <exec_byte_code+15424>, 0x633680
<exec_byte_code+17815>,
0x63099c <exec_byte_code+6323>, 0x62fee9 <exec_byte_code+3584>,
0x62f717 <exec_byte_code+1582>, 0x62fffb <exec_byte_code+3858>,
0x63013a <exec_byte_code+4177>, 0x630270 <exec_byte_code+4487>,
0x630907 <exec_byte_code+6174>, 0x630963 <exec_byte_code+6266>,
0x62fbdb <exec_byte_code+2802>, 0x630a2e <exec_byte_code+6469>,
0x630aa7 <exec_byte_code+6590>, 0x630b46 <exec_byte_code+6749>,
0x630b89 <exec_byte_code+6816>, 0x630bfb <exec_byte_code+6930>,
0x630c4b <exec_byte_code+7010>, 0x630cdb <exec_byte_code+7154>,
0x630d65 <exec_byte_code+7292>, 0x62fe9f <exec_byte_code+3510>,
0x632d76 <exec_byte_code+15501>, 0x632e06
<exec_byte_code+15645>,
0x632e53 <exec_byte_code+15722>, 0x632ea0
<exec_byte_code+15799>,
0x632eed <exec_byte_code+15876>, 0x632f3a
<exec_byte_code+15953>,
0x632faa <exec_byte_code+16065>, 0x63301a
<exec_byte_code+16177>,
---Type <return> to continue, or q <return> to quit---
0x63308a <exec_byte_code+16289>, 0x6330fa
<exec_byte_code+16401>,
0x633285 <exec_byte_code+16796>, 0x6332f5
<exec_byte_code+16908>,
0x633365 <exec_byte_code+17020>, 0x6333b2
<exec_byte_code+17097>,
0x633422 <exec_byte_code+17209>, 0x63348c
<exec_byte_code+17315>,
0x6334f5 <exec_byte_code+17420>, 0x63355f
<exec_byte_code+17526>,
0x6320a7 <exec_byte_code+12222>, 0x6320fe
<exec_byte_code+12309>,
0x6335b6 <exec_byte_code+17613>, 0x633624
<exec_byte_code+17723>,
0x633680 <exec_byte_code+17815>, 0x6303a6 <exec_byte_code+4797>,
0x63048b <exec_byte_code+5026>, 0x6305a9 <exec_byte_code+5312>,
0x6306c7 <exec_byte_code+5598>, 0x6307e7 <exec_byte_code+5886>,
0x63131f <exec_byte_code+8758>, 0x631878 <exec_byte_code+10127>,
0x63226d <exec_byte_code+12676>, 0x63380f
<exec_byte_code+18214>,
0x633883 <exec_byte_code+18330>, 0x633680
<exec_byte_code+17815>,
0x633680 <exec_byte_code+17815>, 0x63391f
<exec_byte_code+18486>,
0x633680 <exec_byte_code+17815>, 0x633680
<exec_byte_code+17815>,
0x633680 <exec_byte_code+17815>, 0x633680
<exec_byte_code+17815>,
0x633680 <exec_byte_code+17815>, 0x633680
<exec_byte_code+17815>,
0x633680 <exec_byte_code+17815>, 0x633680
<exec_byte_code+17815>,
0x633680 <exec_byte_code+17815>,
0x6339bd <exec_byte_code+18644> <repeats 64 times>}
count = 31
op = 1
vectorp = 0xa34f60 <pure+1310272>
---Type <return> to continue, or q <return> to quit---
stack = {
pc = 0xb363a7 <pure+2364039> "\207",
byte_string = 10702641,
byte_string_start = 0xb3638f <pure+2364015>
"\303\304\b\305\306$\210\t\203\025",
constants = 10702677,
next = 0x7fffffff7630
}
top = 0x7fffffff6da8
result = 13014770
#11 0x00000000005e7609 in funcall_lambda (fun=10702541, nargs=2,
arg_vector=0x7fffffff72b0) at eval.c:3010
val = 13014770
syms_left = 12886562
next = 20635378
lexenv = 12886562
count = 29
i = 2
optional = true
rest = false
#12 0x00000000005e6e09 in Ffuncall (nargs=3, args=0x7fffffff72a8)
at eval.c:2827
fun = 10702541
---Type <return> to continue, or q <return> to quit---
original_fun = 16301234
funcar = 20631474
numargs = 2
lisp_numargs = 12886610
val = 140737488319120
backtrace = {
next = 0x7fffffff7760,
function = 16301234,
args = 0x7fffffff72b0,
nargs = 2,
debug_on_exit = 0
}
internal_args = 0x7fffffff77c0
i = 6072020
#13 0x000000000062fd90 in exec_byte_code (bytestr=10679993,
vector=10680029,
maxdepth=24, args_template=12886562, nargs=0, args=0x0) at
bytecode.c:900
targets = {0x633680 <exec_byte_code+17815>,
0x63368f <exec_byte_code+17830>, 0x633691
<exec_byte_code+17832>,
0x633693 <exec_byte_code+17834>, 0x633695
<exec_byte_code+17836>,
0x633695 <exec_byte_code+17836>, 0x6336ff
<exec_byte_code+17942>,
0x633773 <exec_byte_code+18058>, 0x62f608 <exec_byte_code+1311>,
0x62f60a <exec_byte_code+1313>, 0x62f60c <exec_byte_code+1315>,
0x62f60e <exec_byte_code+1317>, 0x62f610 <exec_byte_code+1319>,
---Type <return> to continue, or q <return> to quit---
...
By the way, is there an easier way to compile without optimizations than
assigning CFLAGS before running configure? I couldn't find it.
^ permalink raw reply [flat|nested] 34+ messages in thread
* bug#13743: 24.2.93; Segmentation fault when trying to [s]teal a file opened elsewhere
2013-02-18 19:35 ` Glenn Morris
@ 2013-02-19 0:55 ` Dmitry Gutov
0 siblings, 0 replies; 34+ messages in thread
From: Dmitry Gutov @ 2013-02-19 0:55 UTC (permalink / raw)
To: Glenn Morris; +Cc: 13743
On 18.02.2013 23:35, Glenn Morris wrote:
> Dmitry Gutov wrote:
>
>> Emacs reliably crashes when [s]tealing a file that's opened in another
>> instance.
>
> The inevitable question: does this happen with older Emacs versions too?
> In particular pre 24.1?
I checked 24.2 and 23.4, and both crash in this situation. So that's not
a recent regression.
^ permalink raw reply [flat|nested] 34+ messages in thread
* bug#13743: 24.2.93; Segmentation fault when trying to [s]teal a file opened elsewhere
2013-02-19 0:52 ` Dmitry Gutov
@ 2013-02-20 19:31 ` Eli Zaretskii
2013-02-21 8:30 ` Dmitry Gutov
0 siblings, 1 reply; 34+ messages in thread
From: Eli Zaretskii @ 2013-02-20 19:31 UTC (permalink / raw)
To: Dmitry Gutov; +Cc: 13743
> Date: Tue, 19 Feb 2013 04:52:59 +0400
> From: Dmitry Gutov <dgutov@yandex.ru>
> CC: 13743@debbugs.gnu.org
>
> On 18.02.2013 20:11, Eli Zaretskii wrote:
> > Can you recompile without optimizations, and show the backtrace from
> > that build? Thanks.
>
> Here you go:
>
> Program received signal SIGSEGV, Segmentation fault.
> 0x0000000000653481 in add_properties (plist=32025878, i=0x0,
> object=31976325)
> at textprop.c:378
> 378 for (tail2 = i->plist; CONSP (tail2); tail2 = Fcdr (XCDR (tail2)))
> (gdb) bt full
> #0 0x0000000000653481 in add_properties (plist=32025878, i=0x0,
> object=31976325) at textprop.c:378
> tail1 = 32025878
> tail2 = 31873526
> sym1 = 13125730
> val1 = 12886562
> changed = 0
> found = 0
> gcpro1 = {
> next = 0x7fffffff6180,
> var = 0x57dc19 <modify_region+481>,
> nvars = 4295010134
> }
> gcpro2 = {
> next = 0x7fffffff6180,
> var = 0x57dc19 <modify_region+481>,
> nvars = 4295010134
> }
> gcpro3 = {
> next = 0x7fffffff6180,
> var = 0x57dc19 <modify_region+481>,
> nvars = 4295010134
> }
> ---Type <return> to continue, or q <return> to quit---
> #1 0x0000000000655963 in Fadd_text_properties (start=4, end=3068,
> properties=32025878, object=31976325) at textprop.c:1212
> i = 0x0
> unchanged = 0x7fffffffa568
> s = 1
> len = 558
> modified = 19
> gcpro1 = {
> next = 0xa31e4d <pure+1297709>,
> var = 0xa31e29 <pure+1297673>,
> nvars = 579820584989
> }
> #2 0x00000000006559e0 in Fput_text_property (start=4, end=3068,
> property=13125730, value=12886562, object=12886562) at textprop.c:1229
> No locals.
Thanks. This shows quite a different story. But the backtrace alone
is not enough to figure out what goes wrong in this scenario and why,
at least not for me (and I don't see anyone else jumping in to dig
into this problem). And since reproducing this involves tricky
non-default setup and an external package, I wonder if you could
provide a recipe starting with "emacs -Q" or with a minimal .emacs
init file, and show every command you type to reproduce the crash?
> By the way, is there an easier way to compile without optimizations than
> assigning CFLAGS before running configure?
That's the canonical way, AFAIK.
^ permalink raw reply [flat|nested] 34+ messages in thread
* bug#13743: 24.2.93; Segmentation fault when trying to [s]teal a file opened elsewhere
2013-02-18 6:41 bug#13743: 24.2.93; Segmentation fault when trying to [s]teal a file opened elsewhere Dmitry Gutov
2013-02-18 16:11 ` Eli Zaretskii
2013-02-18 19:35 ` Glenn Morris
@ 2013-02-21 5:16 ` Paul Eggert
2013-02-21 7:03 ` Dmitry Gutov
2013-02-23 3:37 ` Dmitry Gutov
2 siblings, 2 replies; 34+ messages in thread
From: Paul Eggert @ 2013-02-21 5:16 UTC (permalink / raw)
To: Dmitry Gutov; +Cc: 13743
> is there an easier way to compile without optimizations than
> assigning CFLAGS before running configure?
Here's what I do:
make clean
make CFLAGS='-g3'
I suggest compiling with ENABLE_CHECKING, too, i.e.:
make clean
make CFLAGS='-g3 -DENABLE_CHECKING'
^ permalink raw reply [flat|nested] 34+ messages in thread
* bug#13743: 24.2.93; Segmentation fault when trying to [s]teal a file opened elsewhere
2013-02-21 5:16 ` Paul Eggert
@ 2013-02-21 7:03 ` Dmitry Gutov
2013-02-23 3:37 ` Dmitry Gutov
1 sibling, 0 replies; 34+ messages in thread
From: Dmitry Gutov @ 2013-02-21 7:03 UTC (permalink / raw)
To: Paul Eggert; +Cc: 13743
Paul Eggert <eggert@cs.ucla.edu> writes:
>> is there an easier way to compile without optimizations than
>> assigning CFLAGS before running configure?
>
> Here's what I do:
>
> make clean
> make CFLAGS='-g3'
>
> I suggest compiling with ENABLE_CHECKING, too, i.e.:
>
> make clean
> make CFLAGS='-g3 -DENABLE_CHECKING'
Thanks, I'll do that.
I think the documentation in this area is lacking, I'll make a separate
bug report for that.
^ permalink raw reply [flat|nested] 34+ messages in thread
* bug#13743: 24.2.93; Segmentation fault when trying to [s]teal a file opened elsewhere
2013-02-20 19:31 ` Eli Zaretskii
@ 2013-02-21 8:30 ` Dmitry Gutov
0 siblings, 0 replies; 34+ messages in thread
From: Dmitry Gutov @ 2013-02-21 8:30 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: 13743
[-- Attachment #1: Type: text/plain, Size: 1691 bytes --]
On 20.02.2013 23:31, Eli Zaretskii wrote:
> Thanks. This shows quite a different story. But the backtrace alone
> is not enough to figure out what goes wrong in this scenario and why,
> at least not for me (and I don't see anyone else jumping in to dig
> into this problem). And since reproducing this involves tricky
Thanks for looking into this, but I'd like to emphasize that so far I've
only seen this bug on GNU/Linux.
> non-default setup and an external package, I wonder if you could
> provide a recipe starting with "emacs -Q" or with a minimal .emacs
> init file, and show every command you type to reproduce the crash?
Here's the recipe:
1. Have case2.html.erb saved somewhere (attached). The contents of the
file are somewhat important, and also its length: if I delete the
"sparta" line - no bug.
2. Check out this repository: https://github.com/purcell/mmm-mode
2. Open the test file in some Emacs instance, make a modification
(prepend the first line with some spaces, for example). Don't save it.
3. Open a new Emacs instance (-Q). I'd recommend doing it with branch
emacs-24, since trunk currently has some problems with font-lock
(Bug#13751).
4. Paste the following into *scratch* and evaluate it:
(add-to-list 'load-path "path/to/mmm-mode")
(require 'mmm-auto)
(require 'mmm-erb)
(setq mmm-global-mode 'auto)
(mmm-add-mode-ext-class 'html-erb-mode "\\.html\\.erb\\'" 'erb)
(mmm-add-mode-ext-class 'html-erb-mode nil 'html-js)
(mmm-add-mode-ext-class 'html-erb-mode nil 'html-css)
(add-to-list 'auto-mode-alist '("\\.html\\.erb\\'" . html-erb-mode))
5. Open the test file, it will tell you that the file is locked.
6. Press `s' or `p'. See it crash.
[-- Attachment #2: case2.html.erb --]
[-- Type: text/html, Size: 513 bytes --]
^ permalink raw reply [flat|nested] 34+ messages in thread
* bug#13743: 24.2.93; Segmentation fault when trying to [s]teal a file opened elsewhere
2013-02-21 5:16 ` Paul Eggert
2013-02-21 7:03 ` Dmitry Gutov
@ 2013-02-23 3:37 ` Dmitry Gutov
2013-02-23 15:10 ` Eli Zaretskii
1 sibling, 1 reply; 34+ messages in thread
From: Dmitry Gutov @ 2013-02-23 3:37 UTC (permalink / raw)
To: Paul Eggert; +Cc: 13743
On 21.02.2013 9:16, Paul Eggert wrote:
>> is there an easier way to compile without optimizations than
>> assigning CFLAGS before running configure?
>
> Here's what I do:
>
> make clean
> make CFLAGS='-g3'
>
> I suggest compiling with ENABLE_CHECKING, too, i.e.:
>
> make clean
> make CFLAGS='-g3 -DENABLE_CHECKING'
So, I compiled it with checking and it crashes with a failed assertion
in the same place. Not sure how useful that is.
(gdb) xbacktrace
"put-text-property" (0xffff6af0)
"jit-lock-refontify" (0xffff7000)
"jit-lock-mode" (0xffff7530)
"jit-lock-register" (0xffff7a30)
"font-lock-turn-on-thing-lock" (0xffff7f40)
"font-lock-mode-internal" (0xffff8440)
"font-lock-default-function" (0xffff8940)
"font-lock-mode" (0xffff8e40)
"turn-on-font-lock" (0xffff9320)
"turn-on-font-lock-if-desired" (0xffff9810)
"global-font-lock-mode-enable-in-buffers" (0xffff9d98)
"run-hooks" (0xffff9e78)
"apply" (0xffffa020)
"run-mode-hooks" (0xffffa520)
"html-erb-mode" (0xffffaa30)
"mmm-update-mode-info" (0xffffaf30)
"mmm-mode-on" (0xffffb360)
"cond" (0xffffb620)
"mmm-mode-on-maybe" (0xffffb8d8)
"funcall" (0xffffb8d0)
"progn" (0xffffbab0)
"condition-case" (0xffffbdd0)
"while" (0xffffbfc0)
---Type <return> to continue, or q <return> to quit---
"let" (0xffffc230)
"progn" (0xffffc3d0)
"mmm-run-major-mode-hook" (0xffffc5b0)
"save-current-buffer" (0xffffc850)
"progn" (0xffffc9f0)
"if" (0xffffcb90)
"while" (0xffffcd80)
"let" (0xffffcff0)
"progn" (0xffffd190)
"mmm-check-changed-buffers" (0xffffd440)
(gdb) bt full
#0 terminate_due_to_signal (sig=6, backtrace_limit=2147483647) at
emacs.c:317
No locals.
#1 0x000000000069a6c2 in die (msg=0x8c9ac4 "assertion failed: i != 0",
file=0x8c8fa8 "textprop.c", line=1173) at alloc.c:6440
No locals.
#2 0x0000000000768f5b in Fadd_text_properties (start=4, end=3068,
properties=30489510, object=30971749) at textprop.c:1173
i = 0x0
unchanged = 0x7fffffffc130
s = 1
len = 558
modified = 19
gcpro1 = {
next = 0xcac4d5 <pure+1643381>,
var = 0xcac461 <pure+1643265>,
nvars = 579820584989
}
#3 0x00000000007692dd in Fput_text_property (start=4, end=3068,
property=15947874, value=15708706, object=15708706) at textprop.c:1229
No locals.
#4 0x00000000006c4bc4 in Ffuncall (nargs=5, args=0x7fffffff6ae8)
at eval.c:2794
fun = 15085301
---Type <return> to continue, or q <return> to quit---
original_fun = 15895858
funcar = 7103860
numargs = 4
lisp_numargs = 140737488317136
val = 19377766
backtrace = {
next = 0x7fffffff6fa0,
function = 15895858,
args = 0x7fffffff6af0,
nargs = 4,
debug_on_exit = 0
}
internal_args = 0x7fffffff69f0
i = 5
#5 0x00000000007360e5 in exec_byte_code (bytestr=13303329,
vector=13303509,
maxdepth=24, args_template=15708706, nargs=0, args=0x0) at
bytecode.c:900
targets = {0x739d87 <exec_byte_code+19583>,
0x739d96 <exec_byte_code+19598>, 0x739d98
<exec_byte_code+19600>,
0x739d9a <exec_byte_code+19602>, 0x739d9c
<exec_byte_code+19604>,
0x739d9c <exec_byte_code+19604>, 0x739e06
<exec_byte_code+19710>,
0x739e7a <exec_byte_code+19826>, 0x73571e <exec_byte_code+1558>,
0x735720 <exec_byte_code+1560>, 0x735722 <exec_byte_code+1562>,
0x735724 <exec_byte_code+1564>, 0x735726 <exec_byte_code+1566>,
---Type <return> to continue, or q <return> to quit---
0x735726 <exec_byte_code+1566>, 0x73572f <exec_byte_code+1575>,
0x7356e9 <exec_byte_code+1505>, 0x735cd6 <exec_byte_code+3022>,
0x735cd8 <exec_byte_code+3024>, 0x735cda <exec_byte_code+3026>,
0x735cdc <exec_byte_code+3028>, 0x735cde <exec_byte_code+3030>,
0x735cde <exec_byte_code+3030>, 0x735d1c <exec_byte_code+3092>,
0x735ce7 <exec_byte_code+3039>, 0x735fda <exec_byte_code+3794>,
0x735fdc <exec_byte_code+3796>, 0x735fde <exec_byte_code+3798>,
0x735fe0 <exec_byte_code+3800>, 0x735fe2 <exec_byte_code+3802>,
0x735fe2 <exec_byte_code+3802>, 0x735f8b <exec_byte_code+3715>,
0x735fa5 <exec_byte_code+3741>, 0x7360a3 <exec_byte_code+3995>,
0x7360a5 <exec_byte_code+3997>, 0x7360a7 <exec_byte_code+3999>,
0x7360a9 <exec_byte_code+4001>, 0x7360ab <exec_byte_code+4003>,
0x7360ab <exec_byte_code+4003>, 0x736054 <exec_byte_code+3916>,
0x73606e <exec_byte_code+3942>, 0x73616f <exec_byte_code+4199>,
0x736171 <exec_byte_code+4201>, 0x736173 <exec_byte_code+4203>,
0x736175 <exec_byte_code+4205>, 0x736177 <exec_byte_code+4207>,
0x736177 <exec_byte_code+4207>, 0x736120 <exec_byte_code+4120>,
0x73613a <exec_byte_code+4146>, 0x739d87 <exec_byte_code+19583>,
0x739d87 <exec_byte_code+19583>, 0x739d87
<exec_byte_code+19583>,
0x739d87 <exec_byte_code+19583>, 0x739d87
<exec_byte_code+19583>,
0x739d87 <exec_byte_code+19583>, 0x739d87
<exec_byte_code+19583>,
0x739d87 <exec_byte_code+19583>, 0x73718f <exec_byte_code+8327>,
0x737325 <exec_byte_code+8733>, 0x737382 <exec_byte_code+8826>,
---Type <return> to continue, or q <return> to quit---
0x7373df <exec_byte_code+8919>, 0x73743c <exec_byte_code+9012>,
0x735b16 <exec_byte_code+2574>, 0x735b8d <exec_byte_code+2693>,
0x7374af <exec_byte_code+9127>, 0x735a3e <exec_byte_code+2358>,
0x735bfd <exec_byte_code+2805>, 0x737510 <exec_byte_code+9224>,
0x737580 <exec_byte_code+9336>, 0x7375d7 <exec_byte_code+9423>,
0x73765c <exec_byte_code+9556>, 0x7376b3 <exec_byte_code+9643>,
0x737797 <exec_byte_code+9871>, 0x7377e4 <exec_byte_code+9948>,
0x737854 <exec_byte_code+10060>, 0x7378e4
<exec_byte_code+10204>,
0x737931 <exec_byte_code+10281>, 0x73797e
<exec_byte_code+10358>,
0x7379ee <exec_byte_code+10470>, 0x737a5e
<exec_byte_code+10582>,
0x737ace <exec_byte_code+10694>, 0x737b5e
<exec_byte_code+10838>,
0x737bb5 <exec_byte_code+10925>, 0x737c0c
<exec_byte_code+11012>,
0x737cf0 <exec_byte_code+11240>, 0x737d86
<exec_byte_code+11390>,
0x737e1c <exec_byte_code+11540>, 0x738149
<exec_byte_code+12353>,
0x7381b9 <exec_byte_code+12465>, 0x738229
<exec_byte_code+12577>,
0x738299 <exec_byte_code+12689>, 0x738309
<exec_byte_code+12801>,
0x738360 <exec_byte_code+12888>, 0x7383fa
<exec_byte_code+13042>,
0x738451 <exec_byte_code+13129>, 0x7384a8
<exec_byte_code+13216>,
0x7384ff <exec_byte_code+13303>, 0x73861d
<exec_byte_code+13589>,
0x736dc6 <exec_byte_code+7358>, 0x738680 <exec_byte_code+13688>,
0x7386cd <exec_byte_code+13765>, 0x7387a9
<exec_byte_code+13985>,
0x73880c <exec_byte_code+14084>, 0x73886f
<exec_byte_code+14183>,
0x7388bc <exec_byte_code+14260>, 0x738912
<exec_byte_code+14346>,
---Type <return> to continue, or q <return> to quit---
0x738968 <exec_byte_code+14432>, 0x7389c2
<exec_byte_code+14522>,
0x739d87 <exec_byte_code+19583>, 0x738a19
<exec_byte_code+14609>,
0x738a61 <exec_byte_code+14681>, 0x738aa9
<exec_byte_code+14753>,
0x738af1 <exec_byte_code+14825>, 0x738b39
<exec_byte_code+14897>,
0x738b81 <exec_byte_code+14969>, 0x736dc6 <exec_byte_code+7358>,
0x739d87 <exec_byte_code+19583>, 0x738bce
<exec_byte_code+15046>,
0x738c16 <exec_byte_code+15118>, 0x738c63
<exec_byte_code+15195>,
0x738cb0 <exec_byte_code+15272>, 0x738d20
<exec_byte_code+15384>,
0x738d90 <exec_byte_code+15496>, 0x738ddd
<exec_byte_code+15573>,
0x7391da <exec_byte_code+16594>, 0x73924a
<exec_byte_code+16706>,
0x7392ba <exec_byte_code+16818>, 0x73932a
<exec_byte_code+16930>,
0x739372 <exec_byte_code+17002>, 0x739d87
<exec_byte_code+19583>,
0x736cf1 <exec_byte_code+7145>, 0x73623e <exec_byte_code+4406>,
0x7358ff <exec_byte_code+2039>, 0x736350 <exec_byte_code+4680>,
0x73648f <exec_byte_code+4999>, 0x7365c5 <exec_byte_code+5309>,
0x736c5c <exec_byte_code+6996>, 0x736cb8 <exec_byte_code+7088>,
0x735f30 <exec_byte_code+3624>, 0x736d83 <exec_byte_code+7291>,
0x736dfc <exec_byte_code+7412>, 0x736e9b <exec_byte_code+7571>,
0x736ede <exec_byte_code+7638>, 0x736f50 <exec_byte_code+7752>,
0x736fa0 <exec_byte_code+7832>, 0x737030 <exec_byte_code+7976>,
0x7370ee <exec_byte_code+8166>, 0x7361f4 <exec_byte_code+4332>,
0x7393bf <exec_byte_code+17079>, 0x73944f
<exec_byte_code+17223>,
0x73949c <exec_byte_code+17300>, 0x7394e9
<exec_byte_code+17377>,
---Type <return> to continue, or q <return> to quit---
0x739536 <exec_byte_code+17454>, 0x739583
<exec_byte_code+17531>,
0x7395f3 <exec_byte_code+17643>, 0x739663
<exec_byte_code+17755>,
0x7396d3 <exec_byte_code+17867>, 0x739743
<exec_byte_code+17979>,
0x739930 <exec_byte_code+18472>, 0x7399a0
<exec_byte_code+18584>,
0x739a10 <exec_byte_code+18696>, 0x739a5d
<exec_byte_code+18773>,
0x739acd <exec_byte_code+18885>, 0x739b37
<exec_byte_code+18991>,
0x739bce <exec_byte_code+19142>, 0x739c66
<exec_byte_code+19294>,
0x738556 <exec_byte_code+13390>, 0x7385ad
<exec_byte_code+13477>,
0x739cbd <exec_byte_code+19381>, 0x739d2b
<exec_byte_code+19491>,
0x739d87 <exec_byte_code+19583>, 0x7366fb <exec_byte_code+5619>,
0x7367e0 <exec_byte_code+5848>, 0x7368fe <exec_byte_code+6134>,
0x736a1c <exec_byte_code+6420>, 0x736b3c <exec_byte_code+6708>,
0x73770a <exec_byte_code+9730>, 0x737c63 <exec_byte_code+11099>,
0x73871c <exec_byte_code+13844>, 0x739f16
<exec_byte_code+19982>,
0x739f8a <exec_byte_code+20098>, 0x739d87
<exec_byte_code+19583>,
0x739d87 <exec_byte_code+19583>, 0x73a026
<exec_byte_code+20254>,
0x739d87 <exec_byte_code+19583>, 0x739d87
<exec_byte_code+19583>,
0x739d87 <exec_byte_code+19583>, 0x739d87
<exec_byte_code+19583>,
0x739d87 <exec_byte_code+19583>, 0x739d87
<exec_byte_code+19583>,
0x739d87 <exec_byte_code+19583>, 0x739d87
<exec_byte_code+19583>,
0x739d87 <exec_byte_code+19583>,
0x73a0c4 <exec_byte_code+20412> <repeats 64 times>}
count = 34
---Type <return> to continue, or q <return> to quit---
op = 4
vectorp = 0xcafee0 <pure+1658240>
stack = {
pc = 0xde6949 <pure+2930665> ".\n\207",
byte_string = 13303329,
byte_string_start = 0xde6921 <pure+2930625> "\306\030\307
\031\032\033\306\034\035\036\f\310\036\r\214~\210\312\016\016\206\037",
constants = 13303509,
next = 0x7fffffff73a0
}
top = 0x7fffffff6ae8
result = 140737488317664
#6 0x00000000006c5a29 in funcall_lambda (fun=13303277, nargs=0,
arg_vector=0x7fffffff7000) at eval.c:3010
val = 19942912
syms_left = 15708706
next = 19040098
lexenv = 15708706
count = 32
i = 0
optional = true
rest = false
#7 0x00000000006c4e06 in Ffuncall (nargs=1, args=0x7fffffff6ff8)
---Type <return> to continue, or q <return> to quit---
at eval.c:2827
fun = 13303277
original_fun = 23441314
funcar = 23441122
numargs = 0
lisp_numargs = 15708754
val = 140737488318432
backtrace = {
next = 0x7fffffff74d0,
function = 23441314,
args = 0x7fffffff7000,
nargs = 0,
debug_on_exit = 0
}
internal_args = 0x7fffffff7530
i = 6940436
#8 0x00000000007360e5 in exec_byte_code (bytestr=13301729,
vector=13302021,
maxdepth=44, args_template=15708706, nargs=0, args=0x0) at
bytecode.c:900
targets = {0x739d87 <exec_byte_code+19583>,
0x739d96 <exec_byte_code+19598>, 0x739d98
<exec_byte_code+19600>,
0x739d9a <exec_byte_code+19602>, 0x739d9c
<exec_byte_code+19604>,
0x739d9c <exec_byte_code+19604>, 0x739e06
<exec_byte_code+19710>,
0x739e7a <exec_byte_code+19826>, 0x73571e <exec_byte_code+1558>,
---Type <return> to continue, or q <return> to quit---
0x735720 <exec_byte_code+1560>, 0x735722 <exec_byte_code+1562>,
0x735724 <exec_byte_code+1564>, 0x735726 <exec_byte_code+1566>,
0x735726 <exec_byte_code+1566>, 0x73572f <exec_byte_code+1575>,
0x7356e9 <exec_byte_code+1505>, 0x735cd6 <exec_byte_code+3022>,
0x735cd8 <exec_byte_code+3024>, 0x735cda <exec_byte_code+3026>,
0x735cdc <exec_byte_code+3028>, 0x735cde <exec_byte_code+3030>,
0x735cde <exec_byte_code+3030>, 0x735d1c <exec_byte_code+3092>,
0x735ce7 <exec_byte_code+3039>, 0x735fda <exec_byte_code+3794>,
0x735fdc <exec_byte_code+3796>, 0x735fde <exec_byte_code+3798>,
0x735fe0 <exec_byte_code+3800>, 0x735fe2 <exec_byte_code+3802>,
0x735fe2 <exec_byte_code+3802>, 0x735f8b <exec_byte_code+3715>,
0x735fa5 <exec_byte_code+3741>, 0x7360a3 <exec_byte_code+3995>,
0x7360a5 <exec_byte_code+3997>, 0x7360a7 <exec_byte_code+3999>,
0x7360a9 <exec_byte_code+4001>, 0x7360ab <exec_byte_code+4003>,
0x7360ab <exec_byte_code+4003>, 0x736054 <exec_byte_code+3916>,
0x73606e <exec_byte_code+3942>, 0x73616f <exec_byte_code+4199>,
0x736171 <exec_byte_code+4201>, 0x736173 <exec_byte_code+4203>,
0x736175 <exec_byte_code+4205>, 0x736177 <exec_byte_code+4207>,
0x736177 <exec_byte_code+4207>, 0x736120 <exec_byte_code+4120>,
0x73613a <exec_byte_code+4146>, 0x739d87 <exec_byte_code+19583>,
0x739d87 <exec_byte_code+19583>, 0x739d87
<exec_byte_code+19583>,
0x739d87 <exec_byte_code+19583>, 0x739d87
<exec_byte_code+19583>,
0x739d87 <exec_byte_code+19583>, 0x739d87
<exec_byte_code+19583>,
---Type <return> to continue, or q <return> to quit---
0x739d87 <exec_byte_code+19583>, 0x73718f <exec_byte_code+8327>,
0x737325 <exec_byte_code+8733>, 0x737382 <exec_byte_code+8826>,
0x7373df <exec_byte_code+8919>, 0x73743c <exec_byte_code+9012>,
0x735b16 <exec_byte_code+2574>, 0x735b8d <exec_byte_code+2693>,
0x7374af <exec_byte_code+9127>, 0x735a3e <exec_byte_code+2358>,
0x735bfd <exec_byte_code+2805>, 0x737510 <exec_byte_code+9224>,
0x737580 <exec_byte_code+9336>, 0x7375d7 <exec_byte_code+9423>,
0x73765c <exec_byte_code+9556>, 0x7376b3 <exec_byte_code+9643>,
0x737797 <exec_byte_code+9871>, 0x7377e4 <exec_byte_code+9948>,
0x737854 <exec_byte_code+10060>, 0x7378e4
<exec_byte_code+10204>,
0x737931 <exec_byte_code+10281>, 0x73797e
<exec_byte_code+10358>,
0x7379ee <exec_byte_code+10470>, 0x737a5e
<exec_byte_code+10582>,
0x737ace <exec_byte_code+10694>, 0x737b5e
<exec_byte_code+10838>,
0x737bb5 <exec_byte_code+10925>, 0x737c0c
<exec_byte_code+11012>,
0x737cf0 <exec_byte_code+11240>, 0x737d86
<exec_byte_code+11390>,
0x737e1c <exec_byte_code+11540>, 0x738149
<exec_byte_code+12353>,
0x7381b9 <exec_byte_code+12465>, 0x738229
<exec_byte_code+12577>,
0x738299 <exec_byte_code+12689>, 0x738309
<exec_byte_code+12801>,
0x738360 <exec_byte_code+12888>, 0x7383fa
<exec_byte_code+13042>,
0x738451 <exec_byte_code+13129>, 0x7384a8
<exec_byte_code+13216>,
0x7384ff <exec_byte_code+13303>, 0x73861d
<exec_byte_code+13589>,
0x736dc6 <exec_byte_code+7358>, 0x738680 <exec_byte_code+13688>,
0x7386cd <exec_byte_code+13765>, 0x7387a9
<exec_byte_code+13985>,
---Type <return> to continue, or q <return> to quit---
0x73880c <exec_byte_code+14084>, 0x73886f
<exec_byte_code+14183>,
0x7388bc <exec_byte_code+14260>, 0x738912
<exec_byte_code+14346>,
0x738968 <exec_byte_code+14432>, 0x7389c2
<exec_byte_code+14522>,
0x739d87 <exec_byte_code+19583>, 0x738a19
<exec_byte_code+14609>,
0x738a61 <exec_byte_code+14681>, 0x738aa9
<exec_byte_code+14753>,
0x738af1 <exec_byte_code+14825>, 0x738b39
<exec_byte_code+14897>,
0x738b81 <exec_byte_code+14969>, 0x736dc6 <exec_byte_code+7358>,
0x739d87 <exec_byte_code+19583>, 0x738bce
<exec_byte_code+15046>,
0x738c16 <exec_byte_code+15118>, 0x738c63
<exec_byte_code+15195>,
0x738cb0 <exec_byte_code+15272>, 0x738d20
<exec_byte_code+15384>,
0x738d90 <exec_byte_code+15496>, 0x738ddd
<exec_byte_code+15573>,
0x7391da <exec_byte_code+16594>, 0x73924a
<exec_byte_code+16706>,
0x7392ba <exec_byte_code+16818>, 0x73932a
<exec_byte_code+16930>,
0x739372 <exec_byte_code+17002>, 0x739d87
<exec_byte_code+19583>,
0x736cf1 <exec_byte_code+7145>, 0x73623e <exec_byte_code+4406>,
0x7358ff <exec_byte_code+2039>, 0x736350 <exec_byte_code+4680>,
0x73648f <exec_byte_code+4999>, 0x7365c5 <exec_byte_code+5309>,
0x736c5c <exec_byte_code+6996>, 0x736cb8 <exec_byte_code+7088>,
0x735f30 <exec_byte_code+3624>, 0x736d83 <exec_byte_code+7291>,
0x736dfc <exec_byte_code+7412>, 0x736e9b <exec_byte_code+7571>,
0x736ede <exec_byte_code+7638>, 0x736f50 <exec_byte_code+7752>,
0x736fa0 <exec_byte_code+7832>, 0x737030 <exec_byte_code+7976>,
0x7370ee <exec_byte_code+8166>, 0x7361f4 <exec_byte_code+4332>,
---Type <return> to continue, or q <return> to quit---
0x7393bf <exec_byte_code+17079>, 0x73944f
<exec_byte_code+17223>,
0x73949c <exec_byte_code+17300>, 0x7394e9
<exec_byte_code+17377>,
0x739536 <exec_byte_code+17454>, 0x739583
<exec_byte_code+17531>,
0x7395f3 <exec_byte_code+17643>, 0x739663
<exec_byte_code+17755>,
0x7396d3 <exec_byte_code+17867>, 0x739743
<exec_byte_code+17979>,
0x739930 <exec_byte_code+18472>, 0x7399a0
<exec_byte_code+18584>,
0x739a10 <exec_byte_code+18696>, 0x739a5d
<exec_byte_code+18773>,
0x739acd <exec_byte_code+18885>, 0x739b37
<exec_byte_code+18991>,
0x739bce <exec_byte_code+19142>, 0x739c66
<exec_byte_code+19294>,
0x738556 <exec_byte_code+13390>, 0x7385ad
<exec_byte_code+13477>,
0x739cbd <exec_byte_code+19381>, 0x739d2b
<exec_byte_code+19491>,
0x739d87 <exec_byte_code+19583>, 0x7366fb <exec_byte_code+5619>,
0x7367e0 <exec_byte_code+5848>, 0x7368fe <exec_byte_code+6134>,
0x736a1c <exec_byte_code+6420>, 0x736b3c <exec_byte_code+6708>,
0x73770a <exec_byte_code+9730>, 0x737c63 <exec_byte_code+11099>,
0x73871c <exec_byte_code+13844>, 0x739f16
<exec_byte_code+19982>,
0x739f8a <exec_byte_code+20098>, 0x739d87
<exec_byte_code+19583>,
0x739d87 <exec_byte_code+19583>, 0x73a026
<exec_byte_code+20254>,
0x739d87 <exec_byte_code+19583>, 0x739d87
<exec_byte_code+19583>,
0x739d87 <exec_byte_code+19583>, 0x739d87
<exec_byte_code+19583>,
0x739d87 <exec_byte_code+19583>, 0x739d87
<exec_byte_code+19583>,
0x739d87 <exec_byte_code+19583>, 0x739d87
<exec_byte_code+19583>,
0x739d87 <exec_byte_code+19583>,
---Type <return> to continue, or q <return> to quit---
0x73a0c4 <exec_byte_code+20412> <repeats 64 times>}
count = 32
op = 0
vectorp = 0xcaf910 <pure+1656752>
stack = {
pc = 0xde69af <pure+2930767> "\210\n\203\027",
byte_string = 13301729,
byte_string_start = 0xde69a7 <pure+2930759> "\b\211\021\203j",
constants = 13302021,
next = 0x7fffffff78a0
}
top = 0x7fffffff6ff8
result = 30500326
#9 0x00000000006c5a29 in funcall_lambda (fun=13301677, nargs=1,
arg_vector=0x7fffffff7530) at eval.c:3010
val = 30500326
syms_left = 15708706
next = 19011106
lexenv = 15708706
count = 31
i = 1
optional = false
rest = false
---Type <return> to continue, or q <return> to quit---
#10 0x00000000006c4e06 in Ffuncall (nargs=2, args=0x7fffffff7528)
at eval.c:2827
fun = 13301677
original_fun = 23441122
funcar = 23445122
numargs = 1
lisp_numargs = 15708754
val = 140737488319760
backtrace = {
next = 0x7fffffff79d0,
function = 23441122,
args = 0x7fffffff7530,
nargs = 1,
debug_on_exit = 0
}
internal_args = 0x7fffffff7a30
i = 6940436
#11 0x00000000007360e5 in exec_byte_code (bytestr=13302705,
vector=13302829,
maxdepth=20, args_template=15708706, nargs=0, args=0x0) at
bytecode.c:900
targets = {0x739d87 <exec_byte_code+19583>,
0x739d96 <exec_byte_code+19598>, 0x739d98
<exec_byte_code+19600>,
0x739d9a <exec_byte_code+19602>, 0x739d9c
<exec_byte_code+19604>,
0x739d9c <exec_byte_code+19604>, 0x739e06
<exec_byte_code+19710>,
---Type <return> to continue, or q <return> to quit---
0x739e7a <exec_byte_code+19826>, 0x73571e <exec_byte_code+1558>,
0x735720 <exec_byte_code+1560>, 0x735722 <exec_byte_code+1562>,
0x735724 <exec_byte_code+1564>, 0x735726 <exec_byte_code+1566>,
0x735726 <exec_byte_code+1566>, 0x73572f <exec_byte_code+1575>,
0x7356e9 <exec_byte_code+1505>, 0x735cd6 <exec_byte_code+3022>,
0x735cd8 <exec_byte_code+3024>, 0x735cda <exec_byte_code+3026>,
0x735cdc <exec_byte_code+3028>, 0x735cde <exec_byte_code+3030>,
0x735cde <exec_byte_code+3030>, 0x735d1c <exec_byte_code+3092>,
0x735ce7 <exec_byte_code+3039>, 0x735fda <exec_byte_code+3794>,
0x735fdc <exec_byte_code+3796>, 0x735fde <exec_byte_code+3798>,
0x735fe0 <exec_byte_code+3800>, 0x735fe2 <exec_byte_code+3802>,
0x735fe2 <exec_byte_code+3802>, 0x735f8b <exec_byte_code+3715>,
0x735fa5 <exec_byte_code+3741>, 0x7360a3 <exec_byte_code+3995>,
0x7360a5 <exec_byte_code+3997>, 0x7360a7 <exec_byte_code+3999>,
0x7360a9 <exec_byte_code+4001>, 0x7360ab <exec_byte_code+4003>,
0x7360ab <exec_byte_code+4003>, 0x736054 <exec_byte_code+3916>,
0x73606e <exec_byte_code+3942>, 0x73616f <exec_byte_code+4199>,
0x736171 <exec_byte_code+4201>, 0x736173 <exec_byte_code+4203>,
0x736175 <exec_byte_code+4205>, 0x736177 <exec_byte_code+4207>,
0x736177 <exec_byte_code+4207>, 0x736120 <exec_byte_code+4120>,
0x73613a <exec_byte_code+4146>, 0x739d87 <exec_byte_code+19583>,
0x739d87 <exec_byte_code+19583>, 0x739d87
<exec_byte_code+19583>,
0x739d87 <exec_byte_code+19583>, 0x739d87
<exec_byte_code+19583>,
---Type <return> to continue, or q <return> to quit---
0x739d87 <exec_byte_code+19583>, 0x739d87
<exec_byte_code+19583>,
0x739d87 <exec_byte_code+19583>, 0x73718f <exec_byte_code+8327>,
0x737325 <exec_byte_code+8733>, 0x737382 <exec_byte_code+8826>,
0x7373df <exec_byte_code+8919>, 0x73743c <exec_byte_code+9012>,
0x735b16 <exec_byte_code+2574>, 0x735b8d <exec_byte_code+2693>,
0x7374af <exec_byte_code+9127>, 0x735a3e <exec_byte_code+2358>,
0x735bfd <exec_byte_code+2805>, 0x737510 <exec_byte_code+9224>,
0x737580 <exec_byte_code+9336>, 0x7375d7 <exec_byte_code+9423>,
0x73765c <exec_byte_code+9556>, 0x7376b3 <exec_byte_code+9643>,
0x737797 <exec_byte_code+9871>, 0x7377e4 <exec_byte_code+9948>,
0x737854 <exec_byte_code+10060>, 0x7378e4
<exec_byte_code+10204>,
0x737931 <exec_byte_code+10281>, 0x73797e
<exec_byte_code+10358>,
0x7379ee <exec_byte_code+10470>, 0x737a5e
<exec_byte_code+10582>,
0x737ace <exec_byte_code+10694>, 0x737b5e
<exec_byte_code+10838>,
0x737bb5 <exec_byte_code+10925>, 0x737c0c
<exec_byte_code+11012>,
0x737cf0 <exec_byte_code+11240>, 0x737d86
<exec_byte_code+11390>,
0x737e1c <exec_byte_code+11540>, 0x738149
<exec_byte_code+12353>,
0x7381b9 <exec_byte_code+12465>, 0x738229
<exec_byte_code+12577>,
0x738299 <exec_byte_code+12689>, 0x738309
<exec_byte_code+12801>,
0x738360 <exec_byte_code+12888>, 0x7383fa
<exec_byte_code+13042>,
0x738451 <exec_byte_code+13129>, 0x7384a8
<exec_byte_code+13216>,
0x7384ff <exec_byte_code+13303>, 0x73861d
<exec_byte_code+13589>,
0x736dc6 <exec_byte_code+7358>, 0x738680 <exec_byte_code+13688>,
---Type <return> to continue, or q <return> to quit---
0x7386cd <exec_byte_code+13765>, 0x7387a9
<exec_byte_code+13985>,
0x73880c <exec_byte_code+14084>, 0x73886f
<exec_byte_code+14183>,
0x7388bc <exec_byte_code+14260>, 0x738912
<exec_byte_code+14346>,
0x738968 <exec_byte_code+14432>, 0x7389c2
<exec_byte_code+14522>,
0x739d87 <exec_byte_code+19583>, 0x738a19
<exec_byte_code+14609>,
0x738a61 <exec_byte_code+14681>, 0x738aa9
<exec_byte_code+14753>,
0x738af1 <exec_byte_code+14825>, 0x738b39
<exec_byte_code+14897>,
0x738b81 <exec_byte_code+14969>, 0x736dc6 <exec_byte_code+7358>,
0x739d87 <exec_byte_code+19583>, 0x738bce
<exec_byte_code+15046>,
0x738c16 <exec_byte_code+15118>, 0x738c63
<exec_byte_code+15195>,
0x738cb0 <exec_byte_code+15272>, 0x738d20
<exec_byte_code+15384>,
0x738d90 <exec_byte_code+15496>, 0x738ddd
<exec_byte_code+15573>,
0x7391da <exec_byte_code+16594>, 0x73924a
<exec_byte_code+16706>,
0x7392ba <exec_byte_code+16818>, 0x73932a
<exec_byte_code+16930>,
0x739372 <exec_byte_code+17002>, 0x739d87
<exec_byte_code+19583>,
0x736cf1 <exec_byte_code+7145>, 0x73623e <exec_byte_code+4406>,
0x7358ff <exec_byte_code+2039>, 0x736350 <exec_byte_code+4680>,
0x73648f <exec_byte_code+4999>, 0x7365c5 <exec_byte_code+5309>,
0x736c5c <exec_byte_code+6996>, 0x736cb8 <exec_byte_code+7088>,
0x735f30 <exec_byte_code+3624>, 0x736d83 <exec_byte_code+7291>,
0x736dfc <exec_byte_code+7412>, 0x736e9b <exec_byte_code+7571>,
0x736ede <exec_byte_code+7638>, 0x736f50 <exec_byte_code+7752>,
0x736fa0 <exec_byte_code+7832>, 0x737030 <exec_byte_code+7976>,
---Type <return> to continue, or q <return> to quit---
0x7370ee <exec_byte_code+8166>, 0x7361f4 <exec_byte_code+4332>,
0x7393bf <exec_byte_code+17079>, 0x73944f
<exec_byte_code+17223>,
0x73949c <exec_byte_code+17300>, 0x7394e9
<exec_byte_code+17377>,
0x739536 <exec_byte_code+17454>, 0x739583
<exec_byte_code+17531>,
0x7395f3 <exec_byte_code+17643>, 0x739663
<exec_byte_code+17755>,
0x7396d3 <exec_byte_code+17867>, 0x739743
<exec_byte_code+17979>,
0x739930 <exec_byte_code+18472>, 0x7399a0
<exec_byte_code+18584>,
0x739a10 <exec_byte_code+18696>, 0x739a5d
<exec_byte_code+18773>,
0x739acd <exec_byte_code+18885>, 0x739b37
<exec_byte_code+18991>,
0x739bce <exec_byte_code+19142>, 0x739c66
<exec_byte_code+19294>,
0x738556 <exec_byte_code+13390>, 0x7385ad
<exec_byte_code+13477>,
0x739cbd <exec_byte_code+19381>, 0x739d2b
<exec_byte_code+19491>,
0x739d87 <exec_byte_code+19583>, 0x7366fb <exec_byte_code+5619>,
0x7367e0 <exec_byte_code+5848>, 0x7368fe <exec_byte_code+6134>,
0x736a1c <exec_byte_code+6420>, 0x736b3c <exec_byte_code+6708>,
0x73770a <exec_byte_code+9730>, 0x737c63 <exec_byte_code+11099>,
0x73871c <exec_byte_code+13844>, 0x739f16
<exec_byte_code+19982>,
0x739f8a <exec_byte_code+20098>, 0x739d87
<exec_byte_code+19583>,
0x739d87 <exec_byte_code+19583>, 0x73a026
<exec_byte_code+20254>,
0x739d87 <exec_byte_code+19583>, 0x739d87
<exec_byte_code+19583>,
0x739d87 <exec_byte_code+19583>, 0x739d87
<exec_byte_code+19583>,
0x739d87 <exec_byte_code+19583>, 0x739d87
<exec_byte_code+19583>,
0x739d87 <exec_byte_code+19583>, 0x739d87
<exec_byte_code+19583>,
---Type <return> to continue, or q <return> to quit---
^ permalink raw reply [flat|nested] 34+ messages in thread
* bug#13743: 24.2.93; Segmentation fault when trying to [s]teal a file opened elsewhere
2013-02-23 3:37 ` Dmitry Gutov
@ 2013-02-23 15:10 ` Eli Zaretskii
2013-02-23 16:59 ` Stefan Monnier
0 siblings, 1 reply; 34+ messages in thread
From: Eli Zaretskii @ 2013-02-23 15:10 UTC (permalink / raw)
To: Dmitry Gutov; +Cc: 13743
> Date: Sat, 23 Feb 2013 07:37:09 +0400
> From: Dmitry Gutov <dgutov@yandex.ru>
> CC: 13743@debbugs.gnu.org, Eli Zaretskii <eliz@gnu.org>
>
> > make clean
> > make CFLAGS='-g3 -DENABLE_CHECKING'
>
> So, I compiled it with checking and it crashes with a failed assertion
> in the same place. Not sure how useful that is.
It catches the problem one step before we segfault:
> #1 0x000000000069a6c2 in die (msg=0x8c9ac4 "assertion failed: i != 0",
> file=0x8c8fa8 "textprop.c", line=1173) at alloc.c:6440
> No locals.
> #2 0x0000000000768f5b in Fadd_text_properties (start=4, end=3068,
> properties=30489510, object=30971749) at textprop.c:1173
> i = 0x0
> unchanged = 0x7fffffffc130
> s = 1
> len = 558
> modified = 19
> gcpro1 = {
> next = 0xcac4d5 <pure+1643381>,
> var = 0xcac461 <pure+1643265>,
> nvars = 579820584989
> }
This is where it aborts:
if (BUFFERP (object))
modify_region (XBUFFER (object), XINT (start), XINT (end), 1);
/* We are at the beginning of interval I, with LEN chars to scan. */
for (;;)
{
eassert (i != 0); <<<<<<<<<<<<<<<<<<<<<<<<<
if (LENGTH (i) >= len)
Anyway, this problem happens because add-text-properties is re-entered
from the call to modify_region shown above. That function calls
prepare_to_modify_buffer, which calls lock_file, which calls
ask-user-about-lock, which enters redisplay, which tries to fontify
the current buffer, which calls add-text-properties again. This
recursive call modifies the interval tree for the current buffer, so
when modify_region returns, the interval whose pointer 'i' we computed
before calling modify_region is no longer correct (the interval
structure to which 'i' points has changed), and the rest is history.
I attach below the backtrace that clearly shows the recursive
invocation of add-text-properties.
I can fix this particular problem with this simple patch:
=== modified file 'src/textprop.c'
--- src/textprop.c 2013-01-02 16:13:04 +0000
+++ src/textprop.c 2013-02-23 14:56:45 +0000
@@ -1175,7 +1175,24 @@ Return t if any property value actually
}
if (BUFFERP (object))
- modify_region (object, start, end);
+ {
+ ptrdiff_t prev_total_length = i->total_length;
+ ptrdiff_t prev_pos = i->position;
+
+ modify_region (object, start, end);
+ /* If someone called us, as a side effect of modify_region, and
+ changed the intervals behind our back (could happen if
+ lock_file, called by prepare_to_modify_buffer, triggers
+ redisplay and that calls add-text-properties again in the
+ same buffer), we cannot continue with I. So re-invoke
+ ourselves, to have the intervals evaluated anew. */
+ if (i->total_length != prev_total_length
+ || i->position != prev_pos)
+ {
+ UNGCPRO;
+ return Fadd_text_properties (start, end, properties, object);
+ }
+ }
/* We are at the beginning of interval I, with LEN chars to scan. */
for (;;)
However, I'm not sure this is the right or the best way. If it is, it
will probably be prudent to add some protection against infinite
recursion here.
Here's the backtrace from the recursive call to add-text-properties.
It ends at rotate_right because I caught this by setting a watchpoint
at i->total_length, and the watchpoint fired when that was changed.
#0 rotate_right (interval=0x1693738) at intervals.c:374
#1 0x0000000000732aa5 in balance_an_interval (i=0x1693738) at intervals.c:448
#2 0x0000000000732c27 in balance_possible_root_interval (interval=0x1693738)
at intervals.c:484
#3 0x000000000073311f in split_interval_left (interval=0x1693738, offset=506)
at intervals.c:617
#4 0x000000000073d713 in Fadd_text_properties (start=4, end=2028,
properties=22501590, object=23493237) at textprop.c:1212
#5 0x000000000073d89b in Fput_text_property (start=4, end=2028,
property=15624258, value=15399602, object=15399554) at textprop.c:1239
#6 0x000000000069c49b in Ffuncall (nargs=5, args=0x7fffffff02c8)
at eval.c:2691
#7 0x000000000070bdfd in exec_byte_code (bytestr=12996377, vector=12996685,
maxdepth=32, args_template=15399554, nargs=0, args=0x0) at bytecode.c:898
#8 0x000000000069d353 in funcall_lambda (fun=12996333, nargs=2,
arg_vector=0xc6504d <pure+1601741>) at eval.c:2907
#9 0x000000000069c6e9 in Ffuncall (nargs=3, args=0x7fffffff07c8)
at eval.c:2724
#10 0x000000000070bdfd in exec_byte_code (bytestr=12995609, vector=12995837,
maxdepth=40, args_template=15399554, nargs=0, args=0x0) at bytecode.c:898
#11 0x000000000069d353 in funcall_lambda (fun=12995565, nargs=1,
arg_vector=0xc64cfd <pure+1600893>) at eval.c:2907
#12 0x000000000069c6e9 in Ffuncall (nargs=2, args=0x7fffffff0e70)
at eval.c:2724
#13 0x0000000000697a3c in internal_condition_case_n (bfun=0x69ba9e <Ffuncall>,
nargs=2, args=0x7fffffff0e70, handlers=15399602,
hfun=0x44709f <safe_eval_handler>) at eval.c:1317
#14 0x00000000004472f7 in safe_call (nargs=2, func=23095458) at xdisp.c:2432
#15 0x0000000000447368 in safe_call1 (fn=23095458, arg=4) at xdisp.c:2448
#16 0x000000000044b318 in handle_fontified_prop (it=0x7fffffff11f0)
at xdisp.c:3667
#17 0x000000000044a17a in handle_stop (it=0x7fffffff11f0) at xdisp.c:3231
#18 0x00000000004556f9 in reseat (it=0x7fffffff11f0, pos=..., force_p=1)
at xdisp.c:6271
#19 0x0000000000448fee in init_iterator (it=0x7fffffff11f0, w=0xec3598,
charpos=1, bytepos=1, row=0x1643140, base_face_id=DEFAULT_FACE_ID)
at xdisp.c:2888
#20 0x0000000000449268 in start_display (it=0x7fffffff11f0, w=0xec3598,
pos=...) at xdisp.c:2904
#21 0x000000000047b80f in try_window (window=15480221, pos=..., flags=1)
at xdisp.c:16096
#22 0x0000000000478b55 in redisplay_window (window=15480221, just_this_one_p=0)
at xdisp.c:15631
#23 0x0000000000470a0b in redisplay_window_0 (window=15480221) at xdisp.c:13685
#24 0x0000000000697736 in internal_condition_case_1 (
bfun=0x4709c9 <redisplay_window_0>, arg=15480221, handlers=15370182,
hfun=0x470998 <redisplay_window_error>) at eval.c:1231
#25 0x0000000000470979 in redisplay_windows (window=15480221) at xdisp.c:13665
#26 0x000000000046ee3c in redisplay_internal () at xdisp.c:13271
#27 0x0000000000465f90 in echo_area_display (update_frame_p=1) at xdisp.c:10685
#28 0x0000000000461f7f in message3_nolog (m=16562561) at xdisp.c:9650
#29 0x0000000000461ac9 in message3 (m=16562561) at xdisp.c:9596
#30 0x000000000068d088 in Fmessage (nargs=3, args=0x7fffffff5a10)
at editfns.c:3462
#31 0x000000000069bf6b in Ffuncall (nargs=4, args=0x7fffffff5a08)
at eval.c:2656
#32 0x000000000070bdfd in exec_byte_code (bytestr=16578913, vector=15479317,
maxdepth=24, args_template=15399554, nargs=0, args=0x0) at bytecode.c:898
#33 0x000000000069d353 in funcall_lambda (fun=21727621, nargs=2,
arg_vector=0xec3215) at eval.c:2907
#34 0x000000000069c6e9 in Ffuncall (nargs=3, args=0x7fffffff5f10)
at eval.c:2724
#35 0x000000000069b815 in call2 (fn=19454322, arg1=16142209, arg2=16597585)
at eval.c:2484
#36 0x000000000060db60 in lock_file (fn=16142209) at filelock.c:590
#37 0x0000000000613f76 in prepare_to_modify_buffer (start=1, end=515,
preserve_ptr=0x0) at insdel.c:1829
#38 0x0000000000613a22 in modify_region_1 (start=1, end=515,
preserve_chars_modiff=true) at insdel.c:1763
#39 0x00000000007389f8 in modify_region (buffer=16202757, start=4, end=2060)
at textprop.c:97
#40 0x000000000073d4ee in Fadd_text_properties (start=4, end=2060,
properties=22458134, object=16202757) at textprop.c:1178
Lisp Backtrace:
"put-text-property" (0xffff02d0)
"jit-lock-fontify-now" (0xffff07d0)
"jit-lock-function" (0xffff0e78)
"redisplay_internal (C function)" (0xea33d8)
"message" (0xffff5a10)
"ask-user-about-lock" (0xffff5f18)
"put-text-property" (0xffff6370)
"jit-lock-refontify" (0xffff6860)
"jit-lock-mode" (0xffff6d70)
"jit-lock-register" (0xffff7250)
"font-lock-turn-on-thing-lock" (0xffff7740)
"font-lock-mode-internal" (0xffff7c20)
"font-lock-default-function" (0xffff8100)
"font-lock-mode" (0xffff85e0)
"turn-on-font-lock" (0xffff8aa0)
"turn-on-font-lock-if-desired" (0xffff8f70)
"global-font-lock-mode-enable-in-buffers" (0xffff9528)
"run-hooks" (0xffff95f8)
"apply" (0xffff9780)
"run-mode-hooks" (0xffff9ba0)
"html-erb-mode" (0xffff9fa8)
"funcall" (0xffff9fa0)
"save-current-buffer" (0xffffa310)
"unwind-protect" (0xffffa4e0)
"let" (0xffffa7c0)
"if" (0xffffaa00)
"let" (0xffffad00)
"mmm-update-mode-info" (0xffffae20)
"if" (0xffffb280)
"if" (0xffffb4c0)
"mmm-mode-on" (0xffffb5e0)
"cond" (0xffffba30)
"mmm-mode-on-maybe" (0xffffbc18)
"funcall" (0xffffbc10)
"progn" (0xffffbf50)
"condition-case" (0xffffc2c0)
"while" (0xffffc520)
"let" (0xffffc800)
"progn" (0xffffc9f0)
"mmm-run-major-mode-hook" (0xffffcb10)
"save-current-buffer" (0xffffcf40)
"progn" (0xffffd130)
"if" (0xffffd320)
"while" (0xffffd580)
"let" (0xffffd860)
"progn" (0xffffda50)
"mmm-check-changed-buffers" (0xffffdc30)
^ permalink raw reply [flat|nested] 34+ messages in thread
* bug#13743: 24.2.93; Segmentation fault when trying to [s]teal a file opened elsewhere
2013-02-23 15:10 ` Eli Zaretskii
@ 2013-02-23 16:59 ` Stefan Monnier
2013-02-23 18:44 ` Eli Zaretskii
0 siblings, 1 reply; 34+ messages in thread
From: Stefan Monnier @ 2013-02-23 16:59 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: Dmitry Gutov, 13743
> I can fix this particular problem with this simple patch:
[...]
> However, I'm not sure this is the right or the best way. If it is, it
> will probably be prudent to add some protection against infinite
> recursion here.
How 'bout moving the
if (BUFFERP (object))
modify_region (object, start, end);
earlier in the function. Something like the patch below.
Stefan
=== modified file 'src/textprop.c'
--- src/textprop.c 2013-01-02 16:13:04 +0000
+++ src/textprop.c 2013-02-23 16:58:50 +0000
@@ -60,7 +60,7 @@
static Lisp_Object Qread_only;
Lisp_Object Qminibuffer_prompt;
-/* Sticky properties */
+/* Sticky properties. */
Lisp_Object Qfront_sticky, Qrear_nonsticky;
/* If o1 is a cons whose cdr is a cons, return non-zero and set o2 to
@@ -1145,9 +1145,16 @@
if (!i)
return Qnil;
+ if (BUFFERP (object))
+ modify_region (object, start, end);
+
s = XINT (start);
len = XINT (end) - s;
+ /* Recompute `i' since modify_region may have performed indirectly
+ arbitrary modifications to the interval tree. */
+ i = interval_of (s, object);
+
/* No need to protect OBJECT, because we GC only if it's a buffer,
and live buffers are always protected. */
GCPRO1 (properties);
@@ -1174,9 +1181,6 @@
}
}
- if (BUFFERP (object))
- modify_region (object, start, end);
-
/* We are at the beginning of interval I, with LEN chars to scan. */
for (;;)
{
^ permalink raw reply [flat|nested] 34+ messages in thread
* bug#13743: 24.2.93; Segmentation fault when trying to [s]teal a file opened elsewhere
2013-02-23 16:59 ` Stefan Monnier
@ 2013-02-23 18:44 ` Eli Zaretskii
2013-02-24 15:28 ` Dmitry Gutov
0 siblings, 1 reply; 34+ messages in thread
From: Eli Zaretskii @ 2013-02-23 18:44 UTC (permalink / raw)
To: Stefan Monnier; +Cc: dgutov, 13743
> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: Dmitry Gutov <dgutov@yandex.ru>, 13743@debbugs.gnu.org
> Date: Sat, 23 Feb 2013 11:59:18 -0500
>
> > I can fix this particular problem with this simple patch:
> [...]
> > However, I'm not sure this is the right or the best way. If it is, it
> > will probably be prudent to add some protection against infinite
> > recursion here.
>
> How 'bout moving the
>
> if (BUFFERP (object))
> modify_region (object, start, end);
>
> earlier in the function. Something like the patch below.
This will (falsely, AFAIU) tell us that the region is about to be
modified when we return at the point marked below:
/* If we're not starting on an interval boundary, we have to
split this interval. */
if (i->position != s)
{
/* If this interval already has the properties, we can
skip it. */
if (interval_has_all_properties (properties, i))
{
ptrdiff_t got = (LENGTH (i) - (s - i->position));
if (got >= len)
RETURN_UNGCPRO (Qnil); <<<<<<<<<<<<<<<<<<<<<<<<<<<
len -= got;
i = next_interval (i);
}
else
^ permalink raw reply [flat|nested] 34+ messages in thread
* bug#13743: 24.2.93; Segmentation fault when trying to [s]teal a file opened elsewhere
2013-02-23 18:44 ` Eli Zaretskii
@ 2013-02-24 15:28 ` Dmitry Gutov
2013-02-24 15:50 ` Eli Zaretskii
0 siblings, 1 reply; 34+ messages in thread
From: Dmitry Gutov @ 2013-02-24 15:28 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: 13743
On 23.02.2013 22:44, Eli Zaretskii wrote:
>>> I can fix this particular problem with this simple patch:
>> [...]
>>> However, I'm not sure this is the right or the best way. If it is, it
>>> will probably be prudent to add some protection against infinite
>>> recursion here.
>>
>> How 'bout moving the
>>
>> if (BUFFERP (object))
>> modify_region (object, start, end);
>>
>> earlier in the function. Something like the patch below.
>
> This will (falsely, AFAIU) tell us that the region is about to be
> modified when we return at the point marked below:
I tried the patches, and both seem to work fine so far. If you could
explain the practical implications of the drawback in Stefan's patch
you're describing here, I'll try to test for that, too.
> /* If we're not starting on an interval boundary, we have to
> split this interval. */
> if (i->position != s)
> {
> /* If this interval already has the properties, we can
> skip it. */
> if (interval_has_all_properties (properties, i))
> {
> ptrdiff_t got = (LENGTH (i) - (s - i->position));
> if (got >= len)
> RETURN_UNGCPRO (Qnil); <<<<<<<<<<<<<<<<<<<<<<<<<<<
> len -= got;
> i = next_interval (i);
> }
> else
>
^ permalink raw reply [flat|nested] 34+ messages in thread
* bug#13743: 24.2.93; Segmentation fault when trying to [s]teal a file opened elsewhere
2013-02-24 15:28 ` Dmitry Gutov
@ 2013-02-24 15:50 ` Eli Zaretskii
2013-02-25 5:52 ` Dmitry Gutov
0 siblings, 1 reply; 34+ messages in thread
From: Eli Zaretskii @ 2013-02-24 15:50 UTC (permalink / raw)
To: Dmitry Gutov; +Cc: 13743
> Date: Sun, 24 Feb 2013 19:28:32 +0400
> From: Dmitry Gutov <dgutov@yandex.ru>
> CC: Stefan Monnier <monnier@iro.umontreal.ca>, 13743@debbugs.gnu.org
>
> >> How 'bout moving the
> >>
> >> if (BUFFERP (object))
> >> modify_region (object, start, end);
> >>
> >> earlier in the function. Something like the patch below.
> >
> > This will (falsely, AFAIU) tell us that the region is about to be
> > modified when we return at the point marked below:
>
> I tried the patches, and both seem to work fine so far. If you could
> explain the practical implications of the drawback in Stefan's patch
> you're describing here, I'll try to test for that, too.
You need to simulate the situation which causes us to return here:
> > /* If this interval already has the properties, we can
> > skip it. */
> > if (interval_has_all_properties (properties, i))
> > {
> > ptrdiff_t got = (LENGTH (i) - (s - i->position));
> > if (got >= len)
> > RETURN_UNGCPRO (Qnil); <<<<<<<<<<<<<<<<<<<<<<<<<<<
This condition means that we find an interval which already has the
property we are trying to add, and that interval's length is at least
as large as the distance between START and END.
The simplest thing to try reproducing this would be to call
add-text-properties with the property that is already somewhere in the
buffer and with START and END that belong to the buffer region with
this property. I hope this will show you what happens.
The manifestation of the problem will be that modify_region will be
called in this case, although we don't actually modify anything. You
will probably see the "modified" indicator on the mode line, something
that shouldn't have happened.
^ permalink raw reply [flat|nested] 34+ messages in thread
* bug#13743: 24.2.93; Segmentation fault when trying to [s]teal a file opened elsewhere
2013-02-24 15:50 ` Eli Zaretskii
@ 2013-02-25 5:52 ` Dmitry Gutov
2013-02-25 15:25 ` Stefan Monnier
` (2 more replies)
0 siblings, 3 replies; 34+ messages in thread
From: Dmitry Gutov @ 2013-02-25 5:52 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: 13743
On 24.02.2013 19:50, Eli Zaretskii wrote:
>> Date: Sun, 24 Feb 2013 19:28:32 +0400
>> From: Dmitry Gutov <dgutov@yandex.ru>
>> CC: Stefan Monnier <monnier@iro.umontreal.ca>, 13743@debbugs.gnu.org
>>
>>>> How 'bout moving the
>>>>
>>>> if (BUFFERP (object))
>>>> modify_region (object, start, end);
>>>>
>>>> earlier in the function. Something like the patch below.
>>>
>>> This will (falsely, AFAIU) tell us that the region is about to be
>>> modified when we return at the point marked below:
>>
>> I tried the patches, and both seem to work fine so far. If you could
>> explain the practical implications of the drawback in Stefan's patch
>> you're describing here, I'll try to test for that, too.
>
> You need to simulate the situation which causes us to return here:
>
>>> /* If this interval already has the properties, we can
>>> skip it. */
>>> if (interval_has_all_properties (properties, i))
>>> {
>>> ptrdiff_t got = (LENGTH (i) - (s - i->position));
>>> if (got >= len)
>>> RETURN_UNGCPRO (Qnil); <<<<<<<<<<<<<<<<<<<<<<<<<<<
>
> This condition means that we find an interval which already has the
> property we are trying to add, and that interval's length is at least
> as large as the distance between START and END.
>
> The simplest thing to try reproducing this would be to call
> add-text-properties with the property that is already somewhere in the
> buffer and with START and END that belong to the buffer region with
> this property. I hope this will show you what happens.
Thanks.
> The manifestation of the problem will be that modify_region will be
> called in this case, although we don't actually modify anything. You
> will probably see the "modified" indicator on the mode line, something
> that shouldn't have happened.
That is indeed what happens.
OTOH, the existing behavior in this area is rather messy anyway:
a) If START equals to the beginning of the region with the same
property, the buffer is marked modified anyway (even though nothing
changes from the observer's point of view).
So, the trivial example of repeating an `add-text-properties' call with
the same arguments in a previously unpropertized buffer will mark it as
modified every time.
b) This probably has something to do with internal representation, but
even having the same property span before START is not a safe bet:
1. Create a new file with a line of text in it, preferably without
spaces, to see face changes easily
2. Save it, disable font-lock-mode.
3. Evaluate:
(add-text-properties 1 6 '(face font-lock-constant-face)) => modified
save
(add-text-properties 2 6 '(face font-lock-constant-face)) => unmodified
(add-text-properties 2 7 '(face font-lock-constant-face)) => modified
save
(add-text-properties 2 6 '(face font-lock-constant-face)) => unmodified
- optional step
(add-text-properties 2 7 '(face font-lock-constant-face)) => modified(!)
- even though 1 still has the same face
- you can save and repeat this step indefinitely
^ permalink raw reply [flat|nested] 34+ messages in thread
* bug#13743: 24.2.93; Segmentation fault when trying to [s]teal a file opened elsewhere
2013-02-25 5:52 ` Dmitry Gutov
@ 2013-02-25 15:25 ` Stefan Monnier
2013-02-25 16:37 ` Eli Zaretskii
2013-02-25 16:25 ` Eli Zaretskii
2013-02-25 16:27 ` Eli Zaretskii
2 siblings, 1 reply; 34+ messages in thread
From: Stefan Monnier @ 2013-02-25 15:25 UTC (permalink / raw)
To: Dmitry Gutov; +Cc: 13743
>> The manifestation of the problem will be that modify_region will be
>> called in this case, although we don't actually modify anything. You
>> will probably see the "modified" indicator on the mode line, something
>> that shouldn't have happened.
> That is indeed what happens.
> OTOH, the existing behavior in this area is rather messy anyway:
Not only that, but it's not clear why "that shouldn't have happened".
It's good to optimize away the whole add-text-properties when it ends up
doing nothing, but it's just an optimization.
And I don't think it's an important one here, since (as Dmitry points
out) the likely most common case (of having `start' be right at the
beginning of an interval object) didn't work anyway, and furthermore
most calls to add-text-properties are likely to be protected by
inhibit-modification-hooks.
Stefan
^ permalink raw reply [flat|nested] 34+ messages in thread
* bug#13743: 24.2.93; Segmentation fault when trying to [s]teal a file opened elsewhere
2013-02-25 5:52 ` Dmitry Gutov
2013-02-25 15:25 ` Stefan Monnier
@ 2013-02-25 16:25 ` Eli Zaretskii
2013-02-25 18:27 ` Dmitry Gutov
2013-02-25 16:27 ` Eli Zaretskii
2 siblings, 1 reply; 34+ messages in thread
From: Eli Zaretskii @ 2013-02-25 16:25 UTC (permalink / raw)
To: Dmitry Gutov; +Cc: 13743
> Date: Mon, 25 Feb 2013 09:52:24 +0400
> From: Dmitry Gutov <dgutov@yandex.ru>
> CC: monnier@iro.umontreal.ca, 13743@debbugs.gnu.org
>
> OTOH, the existing behavior in this area is rather messy anyway:
>
> a) If START equals to the beginning of the region with the same
> property, the buffer is marked modified anyway (even though nothing
> changes from the observer's point of view).
>
> So, the trivial example of repeating an `add-text-properties' call with
> the same arguments in a previously unpropertized buffer will mark it as
> modified every time.
>
> b) This probably has something to do with internal representation, but
> even having the same property span before START is not a safe bet:
That's a bug, actually, and a very old one at that (at least 17 years
old, IIUC). The code didn't handle correctly all the situations where
there's nothing to change, before it announced a change by calling
modify_region (and later called signal_after_change).
I installed on the trunk revision 111875 to fix this. Now all your
examples:
> 1. Create a new file with a line of text in it, preferably without
> spaces, to see face changes easily
> 2. Save it, disable font-lock-mode.
> 3. Evaluate:
>
> (add-text-properties 1 6 '(face font-lock-constant-face)) => modified
> save
> (add-text-properties 2 6 '(face font-lock-constant-face)) => unmodified
> (add-text-properties 2 7 '(face font-lock-constant-face)) => modified
> save
> (add-text-properties 2 6 '(face font-lock-constant-face)) => unmodified
> - optional step
> (add-text-properties 2 7 '(face font-lock-constant-face)) => modified(!)
> - even though 1 still has the same face
> - you can save and repeat this step indefinitely
work as expected.
Interestingly, this also fixes the original segfault which started
this discussion (not before I fixed similar bugs in
remove-text-properties and elsewhere in textprop.c, because making the
change only n add-text-properties still triggered a similar segfault
from remove-text-properties). So perhaps the fact that buffer
modifications were announced unnecessarily is the root cause for the
segfault.
I couldn't convince myself that, even after revision 111875, we could
not end up in a situation where redisplay triggered by modify_region
changes the intervals when it fontifies the buffer. So perhaps we
need a followup patch to plumb that potential hole, something along
the following:
=== modified file 'src/textprop.c'
--- src/textprop.c 2013-02-25 16:13:42 +0000
+++ src/textprop.c 2013-02-25 16:23:43 +0000
@@ -1134,6 +1134,7 @@ Return t if any property value actually
register int modified = 0;
struct gcpro gcpro1;
ptrdiff_t got;
+ int first_time = 1;
properties = validate_plist (properties);
if (NILP (properties))
@@ -1142,6 +1143,7 @@ Return t if any property value actually
if (NILP (object))
XSETBUFFER (object, current_buffer);
+ retry:
i = validate_interval_range (object, &start, &end, hard);
if (!i)
return Qnil;
@@ -1174,8 +1176,25 @@ Return t if any property value actually
copy_properties (unchanged, i);
}
- if (BUFFERP (object))
- modify_region (object, start, end);
+ if (BUFFERP (object) && first_time)
+ {
+ ptrdiff_t prev_total_length = TOTAL_LENGTH (i);
+ ptrdiff_t prev_pos = i->position;
+
+ modify_region (object, start, end);
+ /* If someone called us recursively as a side effect of
+ modify_region, and changed the intervals behind our back
+ (could happen if lock_file, called by prepare_to_modify_buffer,
+ triggers redisplay, and that calls add-text-properties again
+ in the same buffer), we cannot continue with I, because its
+ data changed. So we restart the interval analysis anew. */
+ if (TOTAL_LENGTH (i) != prev_total_length
+ || i->position != prev_pos)
+ {
+ first_time = 0;
+ goto retry;
+ }
+ }
/* We are at the beginning of interval I, with LEN chars to scan. */
for (;;)
^ permalink raw reply [flat|nested] 34+ messages in thread
* bug#13743: 24.2.93; Segmentation fault when trying to [s]teal a file opened elsewhere
2013-02-25 5:52 ` Dmitry Gutov
2013-02-25 15:25 ` Stefan Monnier
2013-02-25 16:25 ` Eli Zaretskii
@ 2013-02-25 16:27 ` Eli Zaretskii
2013-02-25 19:08 ` Dmitry Gutov
2 siblings, 1 reply; 34+ messages in thread
From: Eli Zaretskii @ 2013-02-25 16:27 UTC (permalink / raw)
To: Dmitry Gutov; +Cc: 13743
Btw, what mmm-mode does is quite nasty, because it causes stale lock
files to be left behind, if you press 'p' when Emacs says that the
file is locked. This is because mmm-mode makes the buffer unmodified
again after doing whatever it is that causes these prompts, and if you
then kill Emacs without ever editing the file, the function that
unlocks the file is not called (because the buffer is not modified).
^ permalink raw reply [flat|nested] 34+ messages in thread
* bug#13743: 24.2.93; Segmentation fault when trying to [s]teal a file opened elsewhere
2013-02-25 15:25 ` Stefan Monnier
@ 2013-02-25 16:37 ` Eli Zaretskii
2013-02-25 18:29 ` Stefan Monnier
0 siblings, 1 reply; 34+ messages in thread
From: Eli Zaretskii @ 2013-02-25 16:37 UTC (permalink / raw)
To: Stefan Monnier; +Cc: dgutov, 13743
> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: Eli Zaretskii <eliz@gnu.org>, 13743@debbugs.gnu.org
> Date: Mon, 25 Feb 2013 10:25:15 -0500
>
> >> The manifestation of the problem will be that modify_region will be
> >> called in this case, although we don't actually modify anything. You
> >> will probably see the "modified" indicator on the mode line, something
> >> that shouldn't have happened.
> > That is indeed what happens.
> > OTOH, the existing behavior in this area is rather messy anyway:
>
> Not only that, but it's not clear why "that shouldn't have happened".
Because we announce that the buffer was changed when in fact it
wasn't. That's a lie. (It also causes redisplay to work harder as a
side effect.)
> It's good to optimize away the whole add-text-properties when it ends up
> doing nothing, but it's just an optimization.
Well, avoiding lies is always an optimization, isn't it? Life can
(and does) go on even without that optimization.
But seriously, how can you claim this not to be a bug? Here, try this
simplified recipe:
emacs -Q
C-x b foo RET
M-: (insert-char ?a 60) RET
M-: (add-text-properties 2 10 '(face error)) RET => t
The buffer is marked modified.
M-~
The buffer is marked unmodified.
M-: (add-text-properties 2 10 '(face error)) RET => nil
The buffer is marked modified again, although nothing's changed, and
the value returned is nil.
You can repeat the last 2 steps forever, the buffer always becomes
modified. I don't see how this could be anything but a bug. Not a
catastrophe, I agree, but a bug nonetheless.
> And I don't think it's an important one here, since (as Dmitry points
> out) the likely most common case (of having `start' be right at the
> beginning of an interval object) didn't work anyway
It does work now. More importantly, it fixed the original crash.
> and furthermore most calls to add-text-properties are likely to be
> protected by inhibit-modification-hooks.
I don't think inhibit-modification-hooks stops the file-locking prompt
from being shown, does it?
^ permalink raw reply [flat|nested] 34+ messages in thread
* bug#13743: 24.2.93; Segmentation fault when trying to [s]teal a file opened elsewhere
2013-02-25 16:25 ` Eli Zaretskii
@ 2013-02-25 18:27 ` Dmitry Gutov
0 siblings, 0 replies; 34+ messages in thread
From: Dmitry Gutov @ 2013-02-25 18:27 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: 13743
On 25.02.2013 20:25, Eli Zaretskii wrote:
> I installed on the trunk revision 111875 to fix this. Now all your
> examples:
>> ...
> work as expected.
Thanks!
> Interestingly, this also fixes the original segfault which started
> this discussion (not before I fixed similar bugs in
> remove-text-properties and elsewhere in textprop.c, because making the
> change only n add-text-properties still triggered a similar segfault
> from remove-text-properties). So perhaps the fact that buffer
> modifications were announced unnecessarily is the root cause for the
> segfault.
Also, mmm-mode now opens small files like the test one noticeably
faster. Not sure why, but it's a nice win.
> I couldn't convince myself that, even after revision 111875, we could
> not end up in a situation where redisplay triggered by modify_region
> changes the intervals when it fontifies the buffer. So perhaps we
> need a followup patch to plumb that potential hole, something along
> the following:
That scenario doesn't sound good, but I'll leave judging the last patch
to the experts. I can't reproduce the original problem anymore, so
please this bug when you think appropriate.
^ permalink raw reply [flat|nested] 34+ messages in thread
* bug#13743: 24.2.93; Segmentation fault when trying to [s]teal a file opened elsewhere
2013-02-25 16:37 ` Eli Zaretskii
@ 2013-02-25 18:29 ` Stefan Monnier
2013-02-25 18:56 ` Eli Zaretskii
0 siblings, 1 reply; 34+ messages in thread
From: Stefan Monnier @ 2013-02-25 18:29 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: dgutov, 13743
>> >> The manifestation of the problem will be that modify_region will be
>> >> called in this case, although we don't actually modify anything. You
>> >> will probably see the "modified" indicator on the mode line, something
>> >> that shouldn't have happened.
>> > That is indeed what happens.
>> > OTOH, the existing behavior in this area is rather messy anyway:
>> Not only that, but it's not clear why "that shouldn't have happened".
> Because we announce that the buffer was changed when in fact it
> wasn't. That's a lie. (It also causes redisplay to work harder as a
> side effect.)
That's a widespread "lie". E.g. turn on overwrite-mode and replace the
char at point with itself: sure enough the buffer is marked as modified.
Along the same lines, try (setq t t) and watch how it complains that
we're trying to modify a read-only object, ...
> You can repeat the last 2 steps forever, the buffer always becomes
> modified. I don't see how this could be anything but a bug. Not a
> catastrophe, I agree, but a bug nonetheless.
add-text-property is a mutation operation, like setq. Whether or not it
returns data about the "old state" doesn't make it less of
a side-effecting operation, in my eyes. So, no I do not consider it to
be a bug at all.
Try (add-text-properties 2 10 '(foo nil)) for another corner case: the
`foo' property was already nil (by default), and yet add-text-properties
claims that setting it to nil is a modification.
>> And I don't think it's an important one here, since (as Dmitry points
>> out) the likely most common case (of having `start' be right at the
>> beginning of an interval object) didn't work anyway
> It does work now. More importantly, it fixed the original crash.
I suspect it only works around the crash by optimizing away the call
to modify_region in the particular case you're testing.
>> and furthermore most calls to add-text-properties are likely to be
>> protected by inhibit-modification-hooks.
> I don't think inhibit-modification-hooks stops the file-locking prompt
> from being shown, does it?
Well, I meant not just inhibit-modification-hooks but
with-silent-modifications (or a comparable set of let-bindings and
unwind-protect), which does prevent the prompt.
Stefan
^ permalink raw reply [flat|nested] 34+ messages in thread
* bug#13743: 24.2.93; Segmentation fault when trying to [s]teal a file opened elsewhere
2013-02-25 18:29 ` Stefan Monnier
@ 2013-02-25 18:56 ` Eli Zaretskii
2013-02-25 20:28 ` Stefan Monnier
0 siblings, 1 reply; 34+ messages in thread
From: Eli Zaretskii @ 2013-02-25 18:56 UTC (permalink / raw)
To: Stefan Monnier; +Cc: dgutov, 13743
> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: dgutov@yandex.ru, 13743@debbugs.gnu.org
> Date: Mon, 25 Feb 2013 13:29:57 -0500
>
> turn on overwrite-mode and replace the char at point with itself:
> sure enough the buffer is marked as modified.
Since you know how things work internally in this case, I'm surprised
that you bring this example. It is not analogous to what happens in
the case in point. In the case in point, we didn't change anything at
all, we just walked the interval tree and wound up discovering that no
changes are needed. But the call to modify_region was issued before
we made that discovery -- and that's the problem.
By contrast, in overwrite-mode we actually make the change without
trying to avoid it.
> Along the same lines, try (setq t t) and watch how it complains that
> we're trying to modify a read-only object, ...
Feel free to fix this blunder.
> > You can repeat the last 2 steps forever, the buffer always becomes
> > modified. I don't see how this could be anything but a bug. Not a
> > catastrophe, I agree, but a bug nonetheless.
>
> add-text-property is a mutation operation, like setq. Whether or not it
> returns data about the "old state" doesn't make it less of
> a side-effecting operation, in my eyes.
If add-text-property was a black box, I might consider agreeing with
you. But since it isn't, and its algorithm is glaringly clear, I
don't. The algorithm clearly tries to avoid mutation when possible,
it just didn't go far enough.
> So, no I do not consider it to be a bug at all.
Not even considering the fact that it causes redisplay do redundant
work? If so, we will have to agree to disagree.
> Try (add-text-properties 2 10 '(foo nil)) for another corner case: the
> `foo' property was already nil (by default), and yet add-text-properties
> claims that setting it to nil is a modification.
I didn't say that what I fixed was the last bug.
> >> And I don't think it's an important one here, since (as Dmitry points
> >> out) the likely most common case (of having `start' be right at the
> >> beginning of an interval object) didn't work anyway
> > It does work now. More importantly, it fixed the original crash.
>
> I suspect it only works around the crash by optimizing away the call
> to modify_region in the particular case you're testing.
So you think I should install the followup I showed earlier?
> >> and furthermore most calls to add-text-properties are likely to be
> >> protected by inhibit-modification-hooks.
> > I don't think inhibit-modification-hooks stops the file-locking prompt
> > from being shown, does it?
>
> Well, I meant not just inhibit-modification-hooks but
> with-silent-modifications (or a comparable set of let-bindings and
> unwind-protect), which does prevent the prompt.
Not with mmm-mode, it doesn't. If you repeat the original recipe for
the crash, putting a breakpoint in filelock.c where it calls
ask-user-about-lock, and type 'p' to the first prompt, you will get a
second prompt, triggered by jit-lock, which does use
with-silent-modifications, AFAICS. I didn't try to figure out why
this happens.
^ permalink raw reply [flat|nested] 34+ messages in thread
* bug#13743: 24.2.93; Segmentation fault when trying to [s]teal a file opened elsewhere
2013-02-25 16:27 ` Eli Zaretskii
@ 2013-02-25 19:08 ` Dmitry Gutov
2013-02-25 19:31 ` Eli Zaretskii
0 siblings, 1 reply; 34+ messages in thread
From: Dmitry Gutov @ 2013-02-25 19:08 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: 13743
On 25.02.2013 20:27, Eli Zaretskii wrote:
> Btw, what mmm-mode does is quite nasty, because it causes stale lock
> files to be left behind, if you press 'p' when Emacs says that the
> file is locked. This is because mmm-mode makes the buffer unmodified
> again after doing whatever it is that causes these prompts, and if you
> then kill Emacs without ever editing the file, the function that
> unlocks the file is not called (because the buffer is not modified).
AFAICT, it only did that to make sure the subsequent `kill-buffer'
doesn't query the user. It doesn't seem to do that either way, so I
removed the `set-buffer-modified-p' call.
But Emacs still leaves the orphan lock files upon exit.
Maybe that has something to do with the fact that said modification and
killing are being performed in a temporary indirect buffer.
^ permalink raw reply [flat|nested] 34+ messages in thread
* bug#13743: 24.2.93; Segmentation fault when trying to [s]teal a file opened elsewhere
2013-02-25 19:08 ` Dmitry Gutov
@ 2013-02-25 19:31 ` Eli Zaretskii
2013-02-25 23:23 ` Dmitry Gutov
0 siblings, 1 reply; 34+ messages in thread
From: Eli Zaretskii @ 2013-02-25 19:31 UTC (permalink / raw)
To: Dmitry Gutov; +Cc: 13743
> Date: Mon, 25 Feb 2013 23:08:04 +0400
> From: Dmitry Gutov <dgutov@yandex.ru>
> CC: monnier@iro.umontreal.ca, 13743@debbugs.gnu.org
>
> On 25.02.2013 20:27, Eli Zaretskii wrote:
> > Btw, what mmm-mode does is quite nasty, because it causes stale lock
> > files to be left behind, if you press 'p' when Emacs says that the
> > file is locked. This is because mmm-mode makes the buffer unmodified
> > again after doing whatever it is that causes these prompts, and if you
> > then kill Emacs without ever editing the file, the function that
> > unlocks the file is not called (because the buffer is not modified).
>
> AFAICT, it only did that to make sure the subsequent `kill-buffer'
> doesn't query the user. It doesn't seem to do that either way, so I
> removed the `set-buffer-modified-p' call.
And after removing that call, do you end up with a "modified" buffer
after visiting a file?
> But Emacs still leaves the orphan lock files upon exit.
> Maybe that has something to do with the fact that said modification and
> killing are being performed in a temporary indirect buffer.
I doubt that. The only thing that matters to file locking is the name
of the file. It doesn't care about buffers.
^ permalink raw reply [flat|nested] 34+ messages in thread
* bug#13743: 24.2.93; Segmentation fault when trying to [s]teal a file opened elsewhere
2013-02-25 18:56 ` Eli Zaretskii
@ 2013-02-25 20:28 ` Stefan Monnier
2013-02-26 3:39 ` Eli Zaretskii
0 siblings, 1 reply; 34+ messages in thread
From: Stefan Monnier @ 2013-02-25 20:28 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: dgutov, 13743
>> turn on overwrite-mode and replace the char at point with itself:
>> sure enough the buffer is marked as modified.
> Since you know how things work internally in this case, I'm surprised
> that you bring this example.
Actually, I don't really know how overwrite-mode works (I remembering
seeing it some point, but that's about as much I know about it).
> By contrast, in overwrite-mode we actually make the change without
> trying to avoid it.
That's an internal implementation detail, IMO.
>> Along the same lines, try (setq t t) and watch how it complains that
>> we're trying to modify a read-only object, ...
> Feel free to fix this blunder.
;-)
>> > You can repeat the last 2 steps forever, the buffer always becomes
>> > modified. I don't see how this could be anything but a bug. Not a
>> > catastrophe, I agree, but a bug nonetheless.
>> add-text-property is a mutation operation, like setq. Whether or not it
>> returns data about the "old state" doesn't make it less of
>> a side-effecting operation, in my eyes.
> If add-text-property was a black box,
Why should we not consider it as a black box?
> I might consider agreeing with you. But since it isn't, and its
> algorithm is glaringly clear, I don't.
I see nowhere (other than in its implementation) something that might
lead one to think that it's clever.
> The algorithm clearly tries to avoid mutation when possible, it just
> didn't go far enough.
Indeed, we could go further and reduce the interval passed to
modify_region in the case where some of the leading/trailing part of the
text already has the requested property values.
All these are just optimizations (i.e. quality of implementation
details, lack of which is not a bug).
>> So, no I do not consider it to be a bug at all.
> Not even considering the fact that it causes redisplay do redundant
> work? If so, we will have to agree to disagree.
No, not even considering it.
>> >> And I don't think it's an important one here, since (as Dmitry points
>> >> out) the likely most common case (of having `start' be right at the
>> >> beginning of an interval object) didn't work anyway
>> > It does work now. More importantly, it fixed the original crash.
>> I suspect it only works around the crash by optimizing away the call
>> to modify_region in the particular case you're testing.
> So you think I should install the followup I showed earlier?
I'd leaning towards yes, although it's sufficiently ugly (and dangerous
since there's no reason to assume that it won't inf-loop) that I'd
rather not.
> Not with mmm-mode, it doesn't. If you repeat the original recipe for
> the crash, putting a breakpoint in filelock.c where it calls
> ask-user-about-lock, and type 'p' to the first prompt, you will get a
> second prompt, triggered by jit-lock, which does use
> with-silent-modifications, AFAICS. I didn't try to figure out why
> this happens.
Looks like a weird corner case, indeed. Maybe some code run from
jit-lock ends up (re)setting byte-file-name (which is normally bound to
nil by with-silent-modifications).
Stefan
^ permalink raw reply [flat|nested] 34+ messages in thread
* bug#13743: 24.2.93; Segmentation fault when trying to [s]teal a file opened elsewhere
2013-02-25 19:31 ` Eli Zaretskii
@ 2013-02-25 23:23 ` Dmitry Gutov
2013-02-26 3:51 ` Eli Zaretskii
0 siblings, 1 reply; 34+ messages in thread
From: Dmitry Gutov @ 2013-02-25 23:23 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: 13743
On 25.02.2013 23:31, Eli Zaretskii wrote:
>> Date: Mon, 25 Feb 2013 23:08:04 +0400
>> From: Dmitry Gutov <dgutov@yandex.ru>
>> CC: monnier@iro.umontreal.ca, 13743@debbugs.gnu.org
>>
>> On 25.02.2013 20:27, Eli Zaretskii wrote:
>>> Btw, what mmm-mode does is quite nasty, because it causes stale lock
>>> files to be left behind, if you press 'p' when Emacs says that the
>>> file is locked. This is because mmm-mode makes the buffer unmodified
>>> again after doing whatever it is that causes these prompts, and if you
>>> then kill Emacs without ever editing the file, the function that
>>> unlocks the file is not called (because the buffer is not modified).
>>
>> AFAICT, it only did that to make sure the subsequent `kill-buffer'
>> doesn't query the user. It doesn't seem to do that either way, so I
>> removed the `set-buffer-modified-p' call.
>
> And after removing that call, do you end up with a "modified" buffer
> after visiting a file?
Nope. You can see for yourself, I pushed that change.
^ permalink raw reply [flat|nested] 34+ messages in thread
* bug#13743: 24.2.93; Segmentation fault when trying to [s]teal a file opened elsewhere
2013-02-25 20:28 ` Stefan Monnier
@ 2013-02-26 3:39 ` Eli Zaretskii
2013-02-26 4:35 ` Stefan Monnier
0 siblings, 1 reply; 34+ messages in thread
From: Eli Zaretskii @ 2013-02-26 3:39 UTC (permalink / raw)
To: Stefan Monnier; +Cc: dgutov, 13743
> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: dgutov@yandex.ru, 13743@debbugs.gnu.org
> Date: Mon, 25 Feb 2013 15:28:36 -0500
>
> >> I suspect it only works around the crash by optimizing away the call
> >> to modify_region in the particular case you're testing.
> > So you think I should install the followup I showed earlier?
>
> I'd leaning towards yes, although it's sufficiently ugly (and dangerous
> since there's no reason to assume that it won't inf-loop) that I'd
> rather not.
No, the patch I posted a few messages ago cannot infloop, it only
retries once (because another call to modify_region is clearly
unnecessary). I will install it, then.
^ permalink raw reply [flat|nested] 34+ messages in thread
* bug#13743: 24.2.93; Segmentation fault when trying to [s]teal a file opened elsewhere
2013-02-25 23:23 ` Dmitry Gutov
@ 2013-02-26 3:51 ` Eli Zaretskii
2013-02-26 3:59 ` Dmitry Gutov
0 siblings, 1 reply; 34+ messages in thread
From: Eli Zaretskii @ 2013-02-26 3:51 UTC (permalink / raw)
To: Dmitry Gutov; +Cc: 13743
> Date: Tue, 26 Feb 2013 03:23:11 +0400
> From: Dmitry Gutov <dgutov@yandex.ru>
> CC: monnier@iro.umontreal.ca, 13743@debbugs.gnu.org
>
> On 25.02.2013 23:31, Eli Zaretskii wrote:
> >> Date: Mon, 25 Feb 2013 23:08:04 +0400
> >> From: Dmitry Gutov <dgutov@yandex.ru>
> >> CC: monnier@iro.umontreal.ca, 13743@debbugs.gnu.org
> >>
> >> On 25.02.2013 20:27, Eli Zaretskii wrote:
> >>> Btw, what mmm-mode does is quite nasty, because it causes stale lock
> >>> files to be left behind, if you press 'p' when Emacs says that the
> >>> file is locked. This is because mmm-mode makes the buffer unmodified
> >>> again after doing whatever it is that causes these prompts, and if you
> >>> then kill Emacs without ever editing the file, the function that
> >>> unlocks the file is not called (because the buffer is not modified).
> >>
> >> AFAICT, it only did that to make sure the subsequent `kill-buffer'
> >> doesn't query the user. It doesn't seem to do that either way, so I
> >> removed the `set-buffer-modified-p' call.
> >
> > And after removing that call, do you end up with a "modified" buffer
> > after visiting a file?
>
> Nope.
Then the root cause is still there: the file is locked by an operation
that leaves the buffer unmodified.
^ permalink raw reply [flat|nested] 34+ messages in thread
* bug#13743: 24.2.93; Segmentation fault when trying to [s]teal a file opened elsewhere
2013-02-26 3:51 ` Eli Zaretskii
@ 2013-02-26 3:59 ` Dmitry Gutov
2013-02-26 18:42 ` Eli Zaretskii
0 siblings, 1 reply; 34+ messages in thread
From: Dmitry Gutov @ 2013-02-26 3:59 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: 13743
On 26.02.2013 7:51, Eli Zaretskii wrote:
>> Date: Tue, 26 Feb 2013 03:23:11 +0400
>> From: Dmitry Gutov <dgutov@yandex.ru>
>> CC: monnier@iro.umontreal.ca, 13743@debbugs.gnu.org
>>
>> On 25.02.2013 23:31, Eli Zaretskii wrote:
>>>> Date: Mon, 25 Feb 2013 23:08:04 +0400
>>>> From: Dmitry Gutov <dgutov@yandex.ru>
>>>> CC: monnier@iro.umontreal.ca, 13743@debbugs.gnu.org
>>>>
>>>> On 25.02.2013 20:27, Eli Zaretskii wrote:
>>>>> Btw, what mmm-mode does is quite nasty, because it causes stale lock
>>>>> files to be left behind, if you press 'p' when Emacs says that the
>>>>> file is locked. This is because mmm-mode makes the buffer unmodified
>>>>> again after doing whatever it is that causes these prompts, and if you
>>>>> then kill Emacs without ever editing the file, the function that
>>>>> unlocks the file is not called (because the buffer is not modified).
>>>>
>>>> AFAICT, it only did that to make sure the subsequent `kill-buffer'
>>>> doesn't query the user. It doesn't seem to do that either way, so I
>>>> removed the `set-buffer-modified-p' call.
>>>
>>> And after removing that call, do you end up with a "modified" buffer
>>> after visiting a file?
>>
>> Nope.
>
> Then the root cause is still there: the file is locked by an operation
> that leaves the buffer unmodified.
Any ideas what that might be? mmm-mode initialization code is rather
complex.
^ permalink raw reply [flat|nested] 34+ messages in thread
* bug#13743: 24.2.93; Segmentation fault when trying to [s]teal a file opened elsewhere
2013-02-26 3:39 ` Eli Zaretskii
@ 2013-02-26 4:35 ` Stefan Monnier
2013-03-02 9:30 ` Eli Zaretskii
0 siblings, 1 reply; 34+ messages in thread
From: Stefan Monnier @ 2013-02-26 4:35 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: dgutov, 13743
> No, the patch I posted a few messages ago cannot infloop, it only
> retries once (because another call to modify_region is clearly
> unnecessary).
Oh, right I missed that part. It's still ugly, but I guess it is
safe, indeed. Feel free to install it,
Stefan
^ permalink raw reply [flat|nested] 34+ messages in thread
* bug#13743: 24.2.93; Segmentation fault when trying to [s]teal a file opened elsewhere
2013-02-26 3:59 ` Dmitry Gutov
@ 2013-02-26 18:42 ` Eli Zaretskii
2013-02-27 17:46 ` Dmitry Gutov
0 siblings, 1 reply; 34+ messages in thread
From: Eli Zaretskii @ 2013-02-26 18:42 UTC (permalink / raw)
To: Dmitry Gutov; +Cc: 13743
> Date: Tue, 26 Feb 2013 07:59:36 +0400
> From: Dmitry Gutov <dgutov@yandex.ru>
> CC: monnier@iro.umontreal.ca, 13743@debbugs.gnu.org
>
> On 26.02.2013 7:51, Eli Zaretskii wrote:
> >> Date: Tue, 26 Feb 2013 03:23:11 +0400
> >> From: Dmitry Gutov <dgutov@yandex.ru>
> >> CC: monnier@iro.umontreal.ca, 13743@debbugs.gnu.org
> >>
> >> On 25.02.2013 23:31, Eli Zaretskii wrote:
> >>>> Date: Mon, 25 Feb 2013 23:08:04 +0400
> >>>> From: Dmitry Gutov <dgutov@yandex.ru>
> >>>> CC: monnier@iro.umontreal.ca, 13743@debbugs.gnu.org
> >>>>
> >>>> On 25.02.2013 20:27, Eli Zaretskii wrote:
> >>>>> Btw, what mmm-mode does is quite nasty, because it causes stale lock
> >>>>> files to be left behind, if you press 'p' when Emacs says that the
> >>>>> file is locked. This is because mmm-mode makes the buffer unmodified
> >>>>> again after doing whatever it is that causes these prompts, and if you
> >>>>> then kill Emacs without ever editing the file, the function that
> >>>>> unlocks the file is not called (because the buffer is not modified).
> >>>>
> >>>> AFAICT, it only did that to make sure the subsequent `kill-buffer'
> >>>> doesn't query the user. It doesn't seem to do that either way, so I
> >>>> removed the `set-buffer-modified-p' call.
> >>>
> >>> And after removing that call, do you end up with a "modified" buffer
> >>> after visiting a file?
> >>
> >> Nope.
> >
> > Then the root cause is still there: the file is locked by an operation
> > that leaves the buffer unmodified.
>
> Any ideas what that might be? mmm-mode initialization code is rather
> complex.
I suggest to run Emacs under GDB, put a breakpoint in lock_file and
unlock_file, and when they break, see who calls them in C and in Lisp.
^ permalink raw reply [flat|nested] 34+ messages in thread
* bug#13743: 24.2.93; Segmentation fault when trying to [s]teal a file opened elsewhere
2013-02-26 18:42 ` Eli Zaretskii
@ 2013-02-27 17:46 ` Dmitry Gutov
0 siblings, 0 replies; 34+ messages in thread
From: Dmitry Gutov @ 2013-02-27 17:46 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: 13743-done
On 26.02.2013 22:42, Eli Zaretskii wrote:
>> Date: Tue, 26 Feb 2013 07:59:36 +0400
>> From: Dmitry Gutov <dgutov@yandex.ru>
>> CC: monnier@iro.umontreal.ca, 13743@debbugs.gnu.org
>>
>> On 26.02.2013 7:51, Eli Zaretskii wrote:
>>>> Date: Tue, 26 Feb 2013 03:23:11 +0400
>>>> From: Dmitry Gutov <dgutov@yandex.ru>
>>>> CC: monnier@iro.umontreal.ca, 13743@debbugs.gnu.org
>>>>
>>>> On 25.02.2013 23:31, Eli Zaretskii wrote:
>>>>>> Date: Mon, 25 Feb 2013 23:08:04 +0400
>>>>>> From: Dmitry Gutov <dgutov@yandex.ru>
>>>>>> CC: monnier@iro.umontreal.ca, 13743@debbugs.gnu.org
>>>>>>
>>>>>> On 25.02.2013 20:27, Eli Zaretskii wrote:
>>>>>>> Btw, what mmm-mode does is quite nasty, because it causes stale lock
>>>>>>> files to be left behind, if you press 'p' when Emacs says that the
>>>>>>> file is locked. This is because mmm-mode makes the buffer unmodified
>>>>>>> again after doing whatever it is that causes these prompts, and if you
>>>>>>> then kill Emacs without ever editing the file, the function that
>>>>>>> unlocks the file is not called (because the buffer is not modified).
>>>>>>
>>>>>> AFAICT, it only did that to make sure the subsequent `kill-buffer'
>>>>>> doesn't query the user. It doesn't seem to do that either way, so I
>>>>>> removed the `set-buffer-modified-p' call.
>>>>>
>>>>> And after removing that call, do you end up with a "modified" buffer
>>>>> after visiting a file?
>>>>
>>>> Nope.
>>>
>>> Then the root cause is still there: the file is locked by an operation
>>> that leaves the buffer unmodified.
>>
>> Any ideas what that might be? mmm-mode initialization code is rather
>> complex.
>
> I suggest to run Emacs under GDB, put a breakpoint in lock_file and
> unlock_file, and when they break, see who calls them in C and in Lisp.
Thanks, this little investigation has resulted in Bug#13836, please take
a look when you have the time.
Meanwhile, binding `buffer-file-truename' to nil around the whole
indirect-buffer business seems to work around this well enough.
^ permalink raw reply [flat|nested] 34+ messages in thread
* bug#13743: 24.2.93; Segmentation fault when trying to [s]teal a file opened elsewhere
2013-02-26 4:35 ` Stefan Monnier
@ 2013-03-02 9:30 ` Eli Zaretskii
0 siblings, 0 replies; 34+ messages in thread
From: Eli Zaretskii @ 2013-03-02 9:30 UTC (permalink / raw)
To: Stefan Monnier; +Cc: 13743-done, dgutov
> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: dgutov@yandex.ru, 13743@debbugs.gnu.org
> Date: Mon, 25 Feb 2013 23:35:29 -0500
>
> > No, the patch I posted a few messages ago cannot infloop, it only
> > retries once (because another call to modify_region is clearly
> > unnecessary).
>
> Oh, right I missed that part. It's still ugly, but I guess it is
> safe, indeed. Feel free to install it,
Done (trunk revision 111914).
Closing the bug.
^ permalink raw reply [flat|nested] 34+ messages in thread
end of thread, other threads:[~2013-03-02 9:30 UTC | newest]
Thread overview: 34+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2013-02-18 6:41 bug#13743: 24.2.93; Segmentation fault when trying to [s]teal a file opened elsewhere Dmitry Gutov
2013-02-18 16:11 ` Eli Zaretskii
2013-02-19 0:52 ` Dmitry Gutov
2013-02-20 19:31 ` Eli Zaretskii
2013-02-21 8:30 ` Dmitry Gutov
2013-02-18 19:35 ` Glenn Morris
2013-02-19 0:55 ` Dmitry Gutov
2013-02-21 5:16 ` Paul Eggert
2013-02-21 7:03 ` Dmitry Gutov
2013-02-23 3:37 ` Dmitry Gutov
2013-02-23 15:10 ` Eli Zaretskii
2013-02-23 16:59 ` Stefan Monnier
2013-02-23 18:44 ` Eli Zaretskii
2013-02-24 15:28 ` Dmitry Gutov
2013-02-24 15:50 ` Eli Zaretskii
2013-02-25 5:52 ` Dmitry Gutov
2013-02-25 15:25 ` Stefan Monnier
2013-02-25 16:37 ` Eli Zaretskii
2013-02-25 18:29 ` Stefan Monnier
2013-02-25 18:56 ` Eli Zaretskii
2013-02-25 20:28 ` Stefan Monnier
2013-02-26 3:39 ` Eli Zaretskii
2013-02-26 4:35 ` Stefan Monnier
2013-03-02 9:30 ` Eli Zaretskii
2013-02-25 16:25 ` Eli Zaretskii
2013-02-25 18:27 ` Dmitry Gutov
2013-02-25 16:27 ` Eli Zaretskii
2013-02-25 19:08 ` Dmitry Gutov
2013-02-25 19:31 ` Eli Zaretskii
2013-02-25 23:23 ` Dmitry Gutov
2013-02-26 3:51 ` Eli Zaretskii
2013-02-26 3:59 ` Dmitry Gutov
2013-02-26 18:42 ` Eli Zaretskii
2013-02-27 17:46 ` Dmitry Gutov
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).