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