* bug#18013: 24.3.92; Infloop in re_search_2
@ 2014-07-14 9:48 Nicolas Richard
2014-07-14 10:06 ` Andreas Schwab
0 siblings, 1 reply; 7+ messages in thread
From: Nicolas Richard @ 2014-07-14 9:48 UTC (permalink / raw)
To: 18013
Hello,
After reconnecting to rcirc, my emacs stopped responding. Hitting C-g
let me enter gdb. I hit "fin RET RET RET" until emacs stops responding
again, and found that I could not finish re_search_2. Here's the
backtrace (hand-edited to remove the value of "targets" which was
uselessly long):
#0 0x081e76c3 in re_search_2 (bufp=0x859b3c0 <searchbufs+640>,
str1=0xaf38e008 "Source file `/home/youngfrog/sources/org-mode/lisp/org.el' newer than byte-compiled file\nLoading /home/youngfrog/sources/ido-hacks/ido-hacks.el (source)...done\nLoading /home/youngfrog/sources/org-mode"...,
size1=77021414, str2=0xb3d028be "", size2=0, startpos=71810484, range=-71810484, regs=0x859c9a4 <search_regs>, stop=77021414) at regex.c:4416
d = 0x8872045 "\347[\b\302\347[\bR\350[\b\315Y\212\b\225\262\177\b\302\347[\b\302\347[\b\302\347[\b\302\347[\b\302\347[\b\302\347[\b\302\347[\b\302\347[\b\302\347[\b\302\347[\b\302\347[\b\302\347[\b\302\347[\b\302\347[\b\302\347[\b\302\347[\b\302\347[\b\302\347[\b\302\347[\b\302\347[\b\302\347[\b\302\347[\b\302\347[\b\302\347[\b\302\347[\b\302\347[\b\302\347[\b\302\347[\b\302\347[\b\302\347[\b\302\347[\b\035\201\203\b\302\347[\b\302\347[\b\302\347[\b\302\347[\b\302\347[\b\302\347[\b\302\347[\b\302\347[\b\302\347[\b\302\347[\b\302\347[\b\302\347[\b\302\347[", <incomplete sequence \302>...
buf_ch = 105
val = -1
string1 = 0xaf38e008 "Source file `/home/youngfrog/sources/org-mode/lisp/org.el' newer than byte-compiled file\nLoading /home/youngfrog/sources/ido-hacks/ido-hacks.el (source)...done\nLoading /home/youngfrog/sources/org-mode"...
string2 = 0xb3d028be ""
fastmap = 0x859b3e4 <searchbufs+676> "\001\001\001\001\001\001\001\001\001\001"
translate = 143073349
total_size = 77021414
endpos = 0
anchored_start = 0 '\000'
multibyte = 1 '\001'
#1 0x081d96aa in search_buffer (string=176212305, pos=77021413, pos_byte=77021415, lim=1, lim_byte=1, n=-1, RE=1, trt=143073349, inverse_trt=142978709, posix=false) at search.c:1223
val = -1073762664
p2 = 0xb3d028be ""
s1 = 77021414
p1 = 0xaf38e008 "Source file `/home/youngfrog/sources/org-mode/lisp/org.el' newer than byte-compiled file\nLoading /home/youngfrog/sources/ido-hacks/ido-hacks.el (source)...done\nLoading /home/youngfrog/sources/org-mode"...
s2 = 0
bufp = 0x859b3c0 <searchbufs+640>
len = 12
len_byte = 12
i = 77021414
#2 0x081d922f in search_command (string=176212305, bound=140240834, noerror=140240858, count=140240834, direction=-1, RE=1, posix=false) at search.c:1061
np = 137757216
lim = 1
lim_byte = 1
n = -1
#3 0x081dc11d in Fre_search_backward (regexp=176212305, bound=140240834, noerror=140240858, count=140240834) at search.c:2223
No locals.
#4 0x08214c1a in Ffuncall (nargs=4, args=0xbfffb054) at eval.c:2826
fun = 137757221
original_fun = 140334834
funcar = 169661589
numargs = 3
lisp_numargs = -1073762264
val = -1073762264
internal_args = 0xbfffafa0
i = 4
#5 0x08255cde in exec_byte_code (bytestr=137828585, vector=137828605, maxdepth=36, args_template=3076, nargs=1, args=0xbfffb37c) at bytecode.c:916
targets = [hand-removed]
count = 59
op = 3
vectorp = 0x83718fc <pure+70972>
stack = {
pc = 0x8553a33 <pure+2045555> "\205\016",
byte_string = 137828585,
byte_string_start = 0x8553a29 <pure+2045545> "`\212\300\301\005\302Q\004\303#\205\016",
next = 0xbfffb3bc
}
top = 0xbfffb054
result = 0
type = (unknown: 12)
#6 0x08215365 in funcall_lambda (fun=137828565, nargs=1, arg_vector=0xbfffb378) at eval.c:2983
val = 136393299
syms_left = 3076
next = 140094908
lexenv = 12
count = 59
i = 137828560
optional = 8
rest = 23
#7 0x08214dc1 in Ffuncall (nargs=2, args=0xbfffb374) at eval.c:2864
fun = 137828565
original_fun = 142029138
funcar = 152709998
numargs = 1
lisp_numargs = -1073761480
val = -1073761448
internal_args = 0x94009b5
i = 155191733
#8 0x08255cde in exec_byte_code (bytestr=155177161, vector=155191733, maxdepth=16, args_template=140240834, nargs=0, args=0x0) at bytecode.c:916
targets = [hand-removed]
count = 55
op = 1
vectorp = 0x94009b4
stack = {
pc = 0x93ed523 "\203\021",
byte_string = 155177161,
byte_string_start = 0x93ed518 "\304\030\305\031r\306q\210\307\310!\203\021",
next = 0xbfffb7cc
}
top = 0xbfffb374
result = 0
type = (unknown: 12)
#9 0x0821572f in funcall_lambda (fun=155191789, nargs=2, arg_vector=0x94009b5) at eval.c:3049
val = 136393299
syms_left = 140240834
next = 142059538
lexenv = 140240834
count = 53
i = 2
optional = true
rest = false
#10 0x08214dc1 in Ffuncall (nargs=3, args=0xbfffb78c) at eval.c:2864
fun = 155191789
original_fun = 155175722
funcar = 12
numargs = 2
lisp_numargs = -1073760648
val = 36318
internal_args = 0x0
i = 140240834
#11 0x08213d29 in Fapply (nargs=3, args=0xbfffb78c) at eval.c:2301
i = 135779084
numargs = 1
spread_arg = 185772774
funcall_args = 0x0
fun = 155175722
retval = 139835381
gcpro1 = {
next = 0x855b7f0 <Sapply>,
var = 0xbfffb6b8,
nvars = 135779084
}
sa_count = 52
sa_must_free = false
#12 0x08214a81 in Ffuncall (nargs=4, args=0xbfffb788) at eval.c:2796
fun = 139835381
original_fun = 140313602
funcar = 140240834
numargs = 3
lisp_numargs = -1073760424
val = -1073760408
internal_args = 0xbfffbaa8
i = 155191229
#13 0x08255cde in exec_byte_code (bytestr=142274241, vector=155191229, maxdepth=20, args_template=512, nargs=1, args=0xbfffbaa8) at bytecode.c:916
targets = [hand-removed]
count = 51
op = 3
vectorp = 0x94007bc
stack = {
pc = 0x85c2ff9 "\207",
byte_string = 142274241,
byte_string_start = 0x85c2ff4 "\300\301\302\003#\207",
next = 0xbfffbafc
}
top = 0xbfffb788
result = 208
type = (unknown: 12)
#14 0x08215365 in funcall_lambda (fun=155191253, nargs=1, arg_vector=0xbfffbaa8) at eval.c:2983
val = 136393299
syms_left = 512
next = -2
lexenv = 12
count = 51
i = 155191248
optional = 8
rest = 23
#15 0x08214dc1 in Ffuncall (nargs=2, args=0xbfffbaa4) at eval.c:2864
fun = 155191253
original_fun = 140359890
funcar = 5
numargs = 1
lisp_numargs = -1073759608
val = -8
internal_args = 0x85be7c2
i = 1
#16 0x08255cde in exec_byte_code (bytestr=158483249, vector=159321197, maxdepth=32, args_template=140240834, nargs=0, args=0x0) at bytecode.c:916
targets = [hand-removed]
count = 40
op = 1
vectorp = 0x97f0c6c
stack = {
pc = 0xa2cc58d "\210+)\366 \210\367 \210+\016[\203\374\001\016\\\204\374\001\016]\203\357\001\t\203\357\001\312\370\016]!\t\"\203\357\001\371\016B!\204\374\001\372p\371\016^!?\205\372\001\373\"\210\016_\203\026\002\016B\204\v\002\016`\203\026\002\374\016@\t\016A\016B\b%\210\375\347!\210\376\377\016@\t\016A\016B\b&\006+\207",
byte_string = 158483249,
byte_string_start = 0xa2cc3cc "\b\204\006",
next = 0xbfffbe2c
}
top = 0xbfffbaa4
result = -1073759208
type = (unknown: 12)
#17 0x0821572f in funcall_lambda (fun=159276165, nargs=6, arg_vector=0x97f0c6d) at eval.c:3049
val = 136393299
syms_left = 140240834
next = 164009058
lexenv = 140240834
count = 34
i = 6
optional = true
rest = false
#18 0x08214dc1 in Ffuncall (nargs=7, args=0xbfffbdd4) at eval.c:2864
fun = 159276165
original_fun = 151710058
funcar = 88
numargs = 6
lisp_numargs = -1073758792
val = 176185209
internal_args = 0x9869dbd
i = 158560833
#19 0x08255cde in exec_byte_code (bytestr=158560633, vector=159817149, maxdepth=36, args_template=140240834, nargs=0, args=0x0) at bytecode.c:916
targets = [hand-removed]
count = 33
op = 6
vectorp = 0x9869dbc
stack = {
pc = 0xa28212d "\207",
byte_string = 158560633,
byte_string_start = 0xa28211c "\305\b\t\n\306\307\310\vA\311#\n\f\235?&\006\207",
next = 0xbfffc14c
}
top = 0xbfffbdd4
result = 12
type = (unknown: 12)
#20 0x0821572f in funcall_lambda (fun=159821221, nargs=5, arg_vector=0x9869dbd) at eval.c:3049
val = 136393299
syms_left = 140240834
next = 140361394
lexenv = 140240834
count = 28
i = 5
optional = false
rest = false
#21 0x08214dc1 in Ffuncall (nargs=6, args=0xbfffc104) at eval.c:2864
fun = 159821221
original_fun = 169426138
funcar = 140289744
numargs = 5
lisp_numargs = -1073757976
val = 140240834
internal_args = 0xa26df7d
i = 28
#22 0x08255cde in exec_byte_code (bytestr=158561665, vector=170319741, maxdepth=28, args_template=140240834, nargs=0, args=0x0) at bytecode.c:916
targets = [hand-removed]
count = 19
op = 5
vectorp = 0xa26df7c
stack = {
pc = 0xa282016 "\210\202Z",
byte_string = 158561665,
byte_string_start = 0xa281fc8 "\306\307\b\"\203g",
next = 0xbfffc5cc
}
top = 0xbfffc104
result = 140240834
type = (unknown: 12)
#23 0x0821572f in funcall_lambda (fun=159817125, nargs=2, arg_vector=0xa26df7d) at eval.c:3049
val = 136280421
syms_left = 140240834
next = 140361394
lexenv = 140240834
count = 17
i = 2
optional = false
rest = false
#24 0x0821507f in apply_lambda (fun=159817125, args=169484462) at eval.c:2924
args_left = 140240834
i = 2
numargs = 2
arg_vector = 0xbfffc390
gcpro1 = {
next = 0x817d285 <PSEUDOVECTORP+51>,
var = 0x9869da0,
nvars = 2
}
gcpro2 = {
next = 0x3e,
var = 0x0,
nvars = -1073757192
}
gcpro3 = {
next = 0x0,
var = 0xcda,
nvars = 191592772
}
tem = 172259337
sa_count = 17
sa_must_free = false
#25 0x08213a7f in eval_sub (form=169484470) at eval.c:2230
fun = 159817125
val = 140240834
original_fun = 169426090
original_args = 169484462
funcar = 190099238
gcpro1 = {
next = 0xb6e1c440 <main_arena>,
var = 0x0,
nvars = 9208
}
gcpro2 = {
next = 0x81fb0c5 <Faref+608>,
var = 0x20,
nvars = 528
}
gcpro3 = {
next = 0x8872045,
var = 0xd,
nvars = -1073757016
}
#26 0x082119d5 in internal_lisp_condition_case (var=141981354, bodyform=169484470, handlers=169484062) at eval.c:1323
val = 140240834
c = 0x85ccfd8
oldhandlerlist = 0x85cc468
clausenb = 1
#27 0x08256bac in exec_byte_code (bytestr=158562761, vector=161535597, maxdepth=12, args_template=140240834, nargs=0, args=0x0) at bytecode.c:1162
handlers = 169484062
body = 169484470
targets = [hand-removed]
count = 16
op = 143
vectorp = 0x9a0d66c
stack = {
pc = 0xa281f60 "\207\306\t\n\"\207",
byte_string = 158562761,
byte_string_start = 0xa281f58 "\b\203\t",
next = 0xbfffc8dc
}
top = 0xbfffc594
result = 140240834
type = (unknown: 12)
#28 0x0821572f in funcall_lambda (fun=161535629, nargs=2, arg_vector=0x9a0d66d) at eval.c:3049
val = 136393299
syms_left = 140240834
next = 140361394
lexenv = 140240834
count = 14
i = 2
optional = false
rest = false
#29 0x08214dc1 in Ffuncall (nargs=3, args=0xbfffc8a4) at eval.c:2864
fun = 161535629
original_fun = 169426018
funcar = 12
numargs = 2
lisp_numargs = 0
val = -1073756024
internal_args = 0x9866de5
i = 0
#30 0x08255cde in exec_byte_code (bytestr=162182137, vector=159804901, maxdepth=12, args_template=140240834, nargs=0, args=0x0) at bytecode.c:916
targets = [hand-removed]
count = 13
op = 2
vectorp = 0x9866de4
stack = {
pc = 0xa281eb0 "\207",
byte_string = 162182137,
byte_string_start = 0xa281eac "\302\b\t\"\207",
next = 0xbfffcd4c
}
top = 0xbfffc8a4
result = 140240834
type = (unknown: 12)
#31 0x0821572f in funcall_lambda (fun=160247229, nargs=1, arg_vector=0x9866de5) at eval.c:3049
val = 136393299
syms_left = 140240834
next = 140241770
lexenv = 140240834
count = 12
i = 1
optional = false
rest = false
#32 0x08214dc1 in Ffuncall (nargs=2, args=0xbfffcbb8) at eval.c:2864
fun = 160247229
original_fun = 160247229
funcar = 100000000
numargs = 1
lisp_numargs = 137829253
val = 140240834
internal_args = 0x11
i = 190654374
#33 0x0821467b in call1 (fn=160247229, arg1=172259337) at eval.c:2614
ret_ungc_val = 140240834
gcpro1 = {
next = 0xa447c41,
var = 0x0,
nvars = 2
}
args = {160247229, 172259337}
#34 0x0821f42b in mapcar1 (leni=60, vals=0x0, fn=160247229, seq=190654006) at fns.c:2329
tail = 190653870
dummy = 140240834
i = 17
gcpro1 = {
next = 0x85be7c2,
var = 0x85be7c2,
nvars = 1405328919
}
gcpro2 = {
next = 0xc,
var = 0xbfffcc38,
nvars = 136414020
}
gcpro3 = {
next = 0xbfffcc08,
var = 0x817d327 <COMPILEDP+25>,
nvars = 190654006
}
#35 0x0821f7ad in Fmapc (function=160247229, sequence=190654006) at fns.c:2418
leni = 60
#36 0x08214bb3 in Ffuncall (nargs=3, args=0xbfffcd04) at eval.c:2818
fun = 139837541
original_fun = 140280338
funcar = 5
numargs = 2
lisp_numargs = -1073754904
val = 190654006
internal_args = 0xbfffcd08
i = 5161
#37 0x08255cde in exec_byte_code (bytestr=162182313, vector=160296045, maxdepth=28, args_template=140240834, nargs=0, args=0x0) at bytecode.c:916
targets = [hand-removed]
count = 9
op = 2
vectorp = 0x98dec6c
stack = {
pc = 0xa281e80 "\210Ή\023)\207",
byte_string = 162182313,
byte_string_start = 0xa281e58 "\304\b\t\"\210\305\b!\210r\306\b!q\210\307 \022\v\tP\211\023\211GSH\310U\205,",
next = 0x0
}
top = 0xbfffcd04
result = 139835376
type = (unknown: 12)
#38 0x0821572f in funcall_lambda (fun=159808989, nargs=2, arg_vector=0x98dec6d) at eval.c:3049
val = 136393299
syms_left = 140240834
next = 144181106
lexenv = 140240834
count = 7
i = 2
optional = false
rest = false
#39 0x08214dc1 in Ffuncall (nargs=3, args=0xbfffd020) at eval.c:2864
fun = 159808989
original_fun = 170495538
funcar = -1073754112
numargs = 2
lisp_numargs = -1073754088
val = -1073754120
internal_args = 0xbfffd020
i = -1073754112
#40 0x082140f0 in Fapply (nargs=2, args=0xbfffd0a4) at eval.c:2354
i = 3
numargs = 2
spread_arg = 140240834
funcall_args = 0xbfffd020
fun = 159808989
retval = 142097605
gcpro1 = {
next = 0x8783cc0,
var = 0xbfffd068,
nvars = 3
}
sa_count = 6
sa_must_free = false
#41 0x08214626 in apply1 (fn=170495538, arg=190654414) at eval.c:2588
ret_ungc_val = 6
args = {170495538, 190654414}
gcpro1 = {
next = 0x817bebf <XSETCDR+17>,
var = 0xbfffd0a4,
nvars = 2
}
#42 0x0826187d in read_process_output_call (fun_and_args=190654406) at process.c:4964
No locals.
#43 0x08211c11 in internal_condition_case_1 (bfun=0x82617f0 <read_process_output_call>, arg=190654406, handlers=140240834, hfun=0x826187f <read_process_output_error_handler>) at eval.c:1378
val = 190654414
c = 0x85cc468
#44 0x08261e44 in read_and_dispose_of_process_output (p=0xab6a4f0,
chars=0xbfffd190 " like to thank Private Internet Access\r\n:verne.freenode.net 372 YoungFrog :- (https://www.privateinternetaccess.com/) and the other\r\n:verne.freenode.net 372 YoungFrog :- organisations that help keep f"...,
nbytes=1126, coding=0xa17db78) at process.c:5177
outstream = 170495538
text = 172260417
outer_running_asynch_code = false
waiting = -1
#45 0x08261b66 in read_process_output (proc=179741941, channel=1126) at process.c:5086
nbytes = 1126
chars = 0xbfffd190 " like to thank Private Internet Access\r\n:verne.freenode.net 372 YoungFrog :- (https://www.privateinternetaccess.com/) and the other\r\n:verne.freenode.net 372 YoungFrog :- organisations that help keep f"...
p = 0xab6a4f0
coding = 0xa17db78
carryover = 0
readmax = 4096
count = 3
odeactivate = 140240834
#46 0x0826121e in wait_reading_process_output (time_limit=30, nsecs=0, read_kbd=-1, do_display=true, wait_for_cell=140240834, wait_proc=0x0, just_wait_proc=0) at process.c:4808
nread = 134682442
timeout_reduced_for_timers = true
channel = 12
nfds = 1
Available = {
fds_bits = {4096, 0 <repeats 31 times>}
}
Writeok = {
fds_bits = {0 <repeats 32 times>}
}
check_write = true
check_delay = 0
no_avail = false
xerrno = 11
proc = 179741941
timeout = {
tv_sec = 0,
tv_nsec = 84131398
}
end_time = {
tv_sec = 1405328949,
tv_nsec = 388317164
}
wait_channel = -1
got_some_input = true
count = 2
#47 0x08064253 in sit_for (timeout=120, reading=true, display_option=1) at dispnew.c:5854
sec = 30
nsec = 0
do_display = true
#48 0x08187251 in read_char (commandflag=1, map=190657822, prev_event=140240834, used_mouse_menu=0xbfffe883, end_time=0x0) at keyboard.c:2809
tem0 = -1
timeout = 30
delay_level = 4
buffer_size = 58
c = 140240834
jmpcount = 2
local_getcjmp = {{
__jmpbuf = {0, 0, 0, -1073748056, 224214774, -1035889255},
__mask_was_saved = 0,
__saved_mask = {
__val = {142358288, 3221219000, 136428008, 140240834, 169661584, 142358288, 142618912, 34569, 0, 3221219096, 135916180, 142618914, 140240858, 3221219048, 135773887, 190657830, 190657830, 6, 6, 146706358, 0, 3221219096,
136248700, 190657830, 190657838, 142618914, 142445350, 140240834, 140240834, 2, 140240834, 0}
}
}}
save_jump = {{
__jmpbuf = {-1227516652, -1073765192, -1073765016, 0, -1073764992, -1226580033},
__mask_was_saved = -1073765016,
__saved_mask = {
__val = {3067450473, 3066474484, 1, 171890800, 3221202280, 3066369452, 13, 3221202408, 4294967285, 0, 171890800, 3068396128, 3068406501, 3066378700, 13, 171890888, 4096, 0, 171890836, 8, 3066369033, 3221202276, 171890800,
3066375302, 3066474484, 3066370758, 171895036, 4294967295, 3221202276, 3221202280, 0, 136570541}
}
}}
tem = 140240834
save = 169526782
previous_echo_area_message = 140240834
also_record = 140240834
reread = false
gcpro1 = {
next = 0x85c41b2,
var = 0xbfffe6d8,
nvars = 136323248
}
gcpro2 = {
next = 0x21c20,
var = 0x0,
nvars = 0
}
polling_stopped_here = false
orig_kboard = 0xb3292e8
#49 0x0819478f in read_key_sequence (keybuf=0xbfffe9a0, bufsize=30, prompt=140240834, dont_downcase_last=false, can_return_switch_frame=true, fix_current_buffer=true, prevent_redisplay=false) at keyboard.c:9088
interrupted_kboard = 0xb3292e8
interrupted_frame = 0x98e9c68
key = 169661589
used_mouse_menu = false
echo_local_start = 0
last_real_key_start = 0
keys_local_start = 0
new_binding = 169661584
count = 2
t = 0
echo_start = 0
keys_start = 0
current_binding = 190657822
first_event = 140240834
first_unbound = 31
mock_input = 0
fkey = {
parent = 188709838,
map = 188709838,
start = 0,
end = 0
}
keytran = {
parent = 140228366,
map = 140228366,
start = 0,
end = 0
}
indec = {
parent = 188709830,
map = 188709830,
start = 0,
end = 0
}
shift_translated = false
delayed_switch_frame = 140240834
original_uppercase = 135779138
original_uppercase_position = -1
dummyflag = false
starting_buffer = 0xa1cd490
fake_prefixed_keys = 140240834
gcpro1 = {
next = 0x85be7c2,
var = 0xbfffe8a8,
nvars = 136285844
}
#50 0x08184120 in command_loop_1 () at keyboard.c:1452
cmd = 150156170
keybuf = {12, 268435584, 137757649, 170495586, 140312882, 140240834, 4, 140240834, 142376306, 0, -1073747480, 135804890, 140271938, 187909734, 137757649, 170495586, 187863784, 0, -1073747384, 135804666, 187909734, -1073747441,
-1073747416, 136392923, 2, 165381745, -1227960375, 0, 0, 0}
i = 2
prev_modiff = 424
prev_buffer = 0xa2c3408
already_adjusted = false
#51 0x08211aef in internal_condition_case (bfun=0x8183d9f <command_loop_1>, handlers=140273914, hfun=0x81835ce <cmd_error>) at eval.c:1354
val = 165381745
c = 0x85cc390
#52 0x08183a49 in command_loop_2 (ignore=140240834) at keyboard.c:1177
val = 0
#53 0x0821106a in internal_catch (tag=140271962, func=0x8183a25 <command_loop_2>, arg=140240834) at eval.c:1118
val = 140240834
c = 0x8994248
#54 0x08183a03 in command_loop () at keyboard.c:1156
No locals.
#55 0x08183162 in recursive_edit_1 () at keyboard.c:777
count = 1
val = -1073747160
#56 0x08183322 in Frecursive_edit () at keyboard.c:848
count = 0
buffer = 140240834
#57 0x08181663 in main (argc=2, argv=0xbfffecb4) at emacs.c:1646
dummy = 2
stack_bottom_variable = 0 '\000'
do_initial_setlocale = true
dumping = false
skip_args = 1
rlim = {
rlim_cur = 8388608,
rlim_max = 18446744073709551615
}
no_loadup = false
junk = 0x0
dname_arg = 0x0
ch_to_dir = 0x0
original_pwd = 0x0
Lisp Backtrace:
"re-search-backward" (0xbfffb058)
"looking-back" (0xbfffb378)
"ad-Advice-recenter" (0xbfffb790)
"apply" (0xbfffb78c)
"recenter" (0xbfffbaa8)
"rcirc-print" (0xbfffbdd8)
"rcirc-handler-generic" (0xbfffc108)
"rcirc-process-server-response-1" (0xbfffc390)
"rcirc-process-server-response" (0xbfffc8a8)
0x98d2db8 PVEC_COMPILED
"mapc" (0xbfffcd08)
"rcirc-filter" (0xbfffd024)
The advice on recenter most probably is this one :
(defadvice recenter (before backtrace activate)
(let ((inhibit-read-only t))
(with-current-buffer "*Messages*"
(when (looking-back "[^\n]")
(insert "\n"))
(insert
(format "Recenter backtrace: \n%s"
(yf/light-backtrace))))))
I'll admit that (looking-back "[^\n]") is not exactly the canonical way
to test for (not (bolp)), but should it make an infloop ? I can't
reproduce though.
I'll keep the gdb session around for the time being.
In GNU Emacs 24.3.92.1 (i686-pc-linux-gnu, X toolkit, Xaw3d scroll bars)
of 2014-07-11 on geodiff-mac3
Windowing system distributor `The X.Org Foundation', version 11.0.11304000
System Description: Gentoo Base System release 2.2
Configured using:
`configure --with-x-toolkit=lucid --enable-checking 'CFLAGS= -O0 -g3''
Important settings:
value of $LANG: fr_FR.UTF-8
locale-coding-system: utf-8-unix
--
Nico.
^ permalink raw reply [flat|nested] 7+ messages in thread
* bug#18013: 24.3.92; Infloop in re_search_2
2014-07-14 9:48 bug#18013: 24.3.92; Infloop in re_search_2 Nicolas Richard
@ 2014-07-14 10:06 ` Andreas Schwab
2014-07-14 10:15 ` Nicolas Richard
2014-07-14 11:12 ` bug#18013: 24.3.92; looking-back "[^\n]" taking a lot of time in large buffers (was: Infloop in re_search_2) Nicolas Richard
0 siblings, 2 replies; 7+ messages in thread
From: Andreas Schwab @ 2014-07-14 10:06 UTC (permalink / raw)
To: Nicolas Richard; +Cc: 18013
Nicolas Richard <theonewiththeevillook@yahoo.fr> writes:
> I'll admit that (looking-back "[^\n]") is not exactly the canonical way
> to test for (not (bolp)), but should it make an infloop ? I can't
> reproduce though.
I don't think it infloops, it just takes a very long time. Since this
is running in a process filter interrupts are disabled, so you have to
be extra careful with what you do here.
Andreas.
--
Andreas Schwab, SUSE Labs, schwab@suse.de
GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE 1748 E4D4 88E3 0EEA B9D7
"And now for something completely different."
^ permalink raw reply [flat|nested] 7+ messages in thread
* bug#18013: 24.3.92; Infloop in re_search_2
2014-07-14 10:06 ` Andreas Schwab
@ 2014-07-14 10:15 ` Nicolas Richard
2014-07-14 11:12 ` bug#18013: 24.3.92; looking-back "[^\n]" taking a lot of time in large buffers (was: Infloop in re_search_2) Nicolas Richard
1 sibling, 0 replies; 7+ messages in thread
From: Nicolas Richard @ 2014-07-14 10:15 UTC (permalink / raw)
To: Andreas Schwab; +Cc: Nicolas Richard, 18013
Andreas Schwab <schwab@suse.de> writes:
> Nicolas Richard <theonewiththeevillook@yahoo.fr> writes:
>
>> I'll admit that (looking-back "[^\n]") is not exactly the canonical way
>> to test for (not (bolp)), but should it make an infloop ? I can't
>> reproduce though.
>
> I don't think it infloops, it just takes a very long time. Since this
> is running in a process filter interrupts are disabled, so you have to
> be extra careful with what you do here.
Thanks, I'll let it run more and see if it comes back to life (it should
be faster since the connection certainly died meanwhile).
--
Nico.
^ permalink raw reply [flat|nested] 7+ messages in thread
* bug#18013: 24.3.92; looking-back "[^\n]" taking a lot of time in large buffers (was: Infloop in re_search_2)
2014-07-14 10:06 ` Andreas Schwab
2014-07-14 10:15 ` Nicolas Richard
@ 2014-07-14 11:12 ` Nicolas Richard
2014-07-15 6:08 ` bug#18013: 24.3.92; looking-back "[^\n]" taking a lot of time in large buffers Kevin Rodgers
2017-03-25 20:59 ` npostavs
1 sibling, 2 replies; 7+ messages in thread
From: Nicolas Richard @ 2014-07-14 11:12 UTC (permalink / raw)
To: Andreas Schwab; +Cc: Nicolas Richard, 18013
Andreas Schwab <schwab@suse.de> writes:
> Nicolas Richard <theonewiththeevillook@yahoo.fr> writes:
>
>> I'll admit that (looking-back "[^\n]") is not exactly the canonical way
>> to test for (not (bolp)), but should it make an infloop ? I can't
>> reproduce though.
>
> I don't think it infloops, it just takes a very long time. Since this
> is running in a process filter interrupts are disabled, so you have to
> be extra careful with what you do here.
It seems you were totally right, thanks ! Here's a repro test case :
# pick up a big file or make one :
$ yes | dd bs=1MB iflag=fullblock count=50 > foobartest
50+0 enregistrements lus
50+0 enregistrements écrits
50000000 octets (50 MB) copiés, 0,853576 s, 58,6 MB/s
# open it in an emacs buffer and try looking-back :
$ time emacs --batch -Q --eval '(with-temp-buffer (insert-file-contents "foobartest") (goto-char (point-max)) (princ "Looking back...") (looking-back "[^\n]") (princ "done!") (terpri))'
"Looking back..."
"done!"
real 0m8.577s
user 0m8.541s
sys 0m0.047s
As you see it takes more than 8 seconds on my system, most of that time
is spent looking-back (inserting the file is quick).
(looking-back "[^\n]") is bad code, so I totally deserve this. Still, is
it possible to make the search smarter when the match is supposed to be
"anchored" at point ? Otherwise let's just close this bug.
--
Nico.
^ permalink raw reply [flat|nested] 7+ messages in thread
* bug#18013: 24.3.92; looking-back "[^\n]" taking a lot of time in large buffers
2014-07-14 11:12 ` bug#18013: 24.3.92; looking-back "[^\n]" taking a lot of time in large buffers (was: Infloop in re_search_2) Nicolas Richard
@ 2014-07-15 6:08 ` Kevin Rodgers
2014-07-15 7:21 ` Andreas Schwab
2017-03-25 20:59 ` npostavs
1 sibling, 1 reply; 7+ messages in thread
From: Kevin Rodgers @ 2014-07-15 6:08 UTC (permalink / raw)
To: 18013
On 7/14/14 5:12 AM, Nicolas Richard wrote:
> As you see it takes more than 8 seconds on my system, most of that time
> is spent looking-back (inserting the file is quick).
>
> (looking-back "[^\n]") is bad code, so I totally deserve this. Still, is
> it possible to make the search smarter when the match is supposed to be
> "anchored" at point ? Otherwise let's just close this bug.
Use "\\=" to match the empty string at point.
--
Kevin Rodgers
Denver, Colorado, USA
^ permalink raw reply [flat|nested] 7+ messages in thread
* bug#18013: 24.3.92; looking-back "[^\n]" taking a lot of time in large buffers
2014-07-15 6:08 ` bug#18013: 24.3.92; looking-back "[^\n]" taking a lot of time in large buffers Kevin Rodgers
@ 2014-07-15 7:21 ` Andreas Schwab
0 siblings, 0 replies; 7+ messages in thread
From: Andreas Schwab @ 2014-07-15 7:21 UTC (permalink / raw)
To: Kevin Rodgers; +Cc: 18013
Kevin Rodgers <kevin.d.rodgers@gmail.com> writes:
> On 7/14/14 5:12 AM, Nicolas Richard wrote:
>> As you see it takes more than 8 seconds on my system, most of that time
>> is spent looking-back (inserting the file is quick).
>>
>> (looking-back "[^\n]") is bad code, so I totally deserve this. Still, is
>> it possible to make the search smarter when the match is supposed to be
>> "anchored" at point ? Otherwise let's just close this bug.
>
> Use "\\=" to match the empty string at point.
That's what looking-back does.
Andreas.
--
Andreas Schwab, SUSE Labs, schwab@suse.de
GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE 1748 E4D4 88E3 0EEA B9D7
"And now for something completely different."
^ permalink raw reply [flat|nested] 7+ messages in thread
* bug#18013: 24.3.92; looking-back "[^\n]" taking a lot of time in large buffers
2014-07-14 11:12 ` bug#18013: 24.3.92; looking-back "[^\n]" taking a lot of time in large buffers (was: Infloop in re_search_2) Nicolas Richard
2014-07-15 6:08 ` bug#18013: 24.3.92; looking-back "[^\n]" taking a lot of time in large buffers Kevin Rodgers
@ 2017-03-25 20:59 ` npostavs
1 sibling, 0 replies; 7+ messages in thread
From: npostavs @ 2017-03-25 20:59 UTC (permalink / raw)
To: Nicolas Richard; +Cc: Andreas Schwab, 18013
tags 18013 wontfix
close 18013
quit
Nicolas Richard <theonewiththeevillook@yahoo.fr> writes:
>
> (looking-back "[^\n]") is bad code, so I totally deserve this. Still, is
> it possible to make the search smarter when the match is supposed to be
> "anchored" at point ? Otherwise let's just close this bug.
`looking-back' would have to analyse "[^\n]" to realize that it could
only match a single character. I think this is too much effort for too
little benefit to justify implementing this. For cases like this you
can limit the amount of searching by passing a non-nil LIMIT argument
(as described in the docstring):
(looking-back "[^\n]" (1- (point)))
^ permalink raw reply [flat|nested] 7+ messages in thread
end of thread, other threads:[~2017-03-25 20:59 UTC | newest]
Thread overview: 7+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2014-07-14 9:48 bug#18013: 24.3.92; Infloop in re_search_2 Nicolas Richard
2014-07-14 10:06 ` Andreas Schwab
2014-07-14 10:15 ` Nicolas Richard
2014-07-14 11:12 ` bug#18013: 24.3.92; looking-back "[^\n]" taking a lot of time in large buffers (was: Infloop in re_search_2) Nicolas Richard
2014-07-15 6:08 ` bug#18013: 24.3.92; looking-back "[^\n]" taking a lot of time in large buffers Kevin Rodgers
2014-07-15 7:21 ` Andreas Schwab
2017-03-25 20:59 ` npostavs
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).