From debbugs-submit-bounces@debbugs.gnu.org Mon Jul 14 05:47:44 2014 Received: (at submit) by debbugs.gnu.org; 14 Jul 2014 09:47:44 +0000 Received: from localhost ([127.0.0.1]:54197 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1X6crF-0003el-Rd for submit@debbugs.gnu.org; Mon, 14 Jul 2014 05:47:43 -0400 Received: from eggs.gnu.org ([208.118.235.92]:57157) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1X6crB-0003dv-Lh for submit@debbugs.gnu.org; Mon, 14 Jul 2014 05:47:39 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1X6cr1-0005kK-8g for submit@debbugs.gnu.org; Mon, 14 Jul 2014 05:47:32 -0400 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org X-Spam-Level: X-Spam-Status: No, score=0.8 required=5.0 tests=BAYES_50,FREEMAIL_FROM autolearn=disabled version=3.3.2 Received: from lists.gnu.org ([2001:4830:134:3::11]:42924) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1X6cr1-0005kG-6D for submit@debbugs.gnu.org; Mon, 14 Jul 2014 05:47:27 -0400 Received: from eggs.gnu.org ([2001:4830:134:3::10]:58703) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1X6cqw-0001Wu-4Z for bug-gnu-emacs@gnu.org; Mon, 14 Jul 2014 05:47:27 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1X6cqr-0005Qd-3A for bug-gnu-emacs@gnu.org; Mon, 14 Jul 2014 05:47:22 -0400 Received: from mxin.ulb.ac.be ([164.15.128.112]:25356) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1X6cqq-0005KR-Cw for bug-gnu-emacs@gnu.org; Mon, 14 Jul 2014 05:47:17 -0400 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjsGAK2mw1OkD4Xx/2dsb2JhbABZg2CDS6kfAQEBAQEBBgWVIYh2dYQtgQsCBSECEQEEiQkBFA2gQo8jgXKNXgGHfxeBLIRPgiKKLIFMBZAXjEGFMIRdiEaDRjs Received: from mathsrv4.ulb.ac.be (HELO geodiff-mac3.ulb.ac.be) ([164.15.133.241]) by smtp.ulb.ac.be with ESMTP; 14 Jul 2014 11:46:53 +0200 From: Nicolas Richard To: bug-gnu-emacs@gnu.org Subject: 24.3.92; Infloop in re_search_2 Date: Mon, 14 Jul 2014 11:48:41 +0200 Message-ID: <87oaws9sp2.fsf@geodiff-mac3.ulb.ac.be> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3.92 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-Received-From: 2001:4830:134:3::11 X-Spam-Score: -5.0 (-----) X-Debbugs-Envelope-To: submit X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -5.0 (-----) 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=3D0x859b3c0 ,=20 str1=3D0xaf38e008 "Source file `/home/youngfrog/sources/org-mode/lisp/o= rg.el' newer than byte-compiled file\nLoading /home/youngfrog/sources/ido-h= acks/ido-hacks.el (source)...done\nLoading /home/youngfrog/sources/org-mode= "...,=20 size1=3D77021414, str2=3D0xb3d028be "", size2=3D0, startpos=3D71810484,= range=3D-71810484, regs=3D0x859c9a4 , stop=3D77021414) at reg= ex.c:4416 d =3D 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\3= 47[\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\3= 02\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\3= 47[\b\302\347[\b\302\347[\b\302\347[\b\302\347[", ... buf_ch =3D 105 val =3D -1 string1 =3D 0xaf38e008 "Source file `/home/youngfrog/sources/org-mo= de/lisp/org.el' newer than byte-compiled file\nLoading /home/youngfrog/sour= ces/ido-hacks/ido-hacks.el (source)...done\nLoading /home/youngfrog/sources= /org-mode"... string2 =3D 0xb3d028be "" fastmap =3D 0x859b3e4 "\001\001\001\001\001\001\00= 1\001\001\001" translate =3D 143073349 total_size =3D 77021414 endpos =3D 0 anchored_start =3D 0 '\000' multibyte =3D 1 '\001' #1 0x081d96aa in search_buffer (string=3D176212305, pos=3D77021413, pos_by= te=3D77021415, lim=3D1, lim_byte=3D1, n=3D-1, RE=3D1, trt=3D143073349, inve= rse_trt=3D142978709, posix=3Dfalse) at search.c:1223 val =3D -1073762664 p2 =3D 0xb3d028be "" s1 =3D 77021414 p1 =3D 0xaf38e008 "Source file `/home/youngfrog/sources/org-mode/li= sp/org.el' newer than byte-compiled file\nLoading /home/youngfrog/sources/i= do-hacks/ido-hacks.el (source)...done\nLoading /home/youngfrog/sources/org-= mode"... s2 =3D 0 bufp =3D 0x859b3c0 len =3D 12 len_byte =3D 12 i =3D 77021414 #2 0x081d922f in search_command (string=3D176212305, bound=3D140240834, no= error=3D140240858, count=3D140240834, direction=3D-1, RE=3D1, posix=3Dfalse= ) at search.c:1061 np =3D 137757216 lim =3D 1 lim_byte =3D 1 n =3D -1 #3 0x081dc11d in Fre_search_backward (regexp=3D176212305, bound=3D14024083= 4, noerror=3D140240858, count=3D140240834) at search.c:2223 No locals. #4 0x08214c1a in Ffuncall (nargs=3D4, args=3D0xbfffb054) at eval.c:2826 fun =3D 137757221 original_fun =3D 140334834 funcar =3D 169661589 numargs =3D 3 lisp_numargs =3D -1073762264 val =3D -1073762264 internal_args =3D 0xbfffafa0 i =3D 4 #5 0x08255cde in exec_byte_code (bytestr=3D137828585, vector=3D137828605, = maxdepth=3D36, args_template=3D3076, nargs=3D1, args=3D0xbfffb37c) at bytec= ode.c:916 targets =3D [hand-removed] count =3D 59 op =3D 3 vectorp =3D 0x83718fc stack =3D { pc =3D 0x8553a33 "\205\016",=20 byte_string =3D 137828585,=20 byte_string_start =3D 0x8553a29 "`\212\300\301\005= \302Q\004\303#\205\016",=20 next =3D 0xbfffb3bc } top =3D 0xbfffb054 result =3D 0 type =3D (unknown: 12) #6 0x08215365 in funcall_lambda (fun=3D137828565, nargs=3D1, arg_vector=3D= 0xbfffb378) at eval.c:2983 val =3D 136393299 syms_left =3D 3076 next =3D 140094908 lexenv =3D 12 count =3D 59 i =3D 137828560 optional =3D 8 rest =3D 23 #7 0x08214dc1 in Ffuncall (nargs=3D2, args=3D0xbfffb374) at eval.c:2864 fun =3D 137828565 original_fun =3D 142029138 funcar =3D 152709998 numargs =3D 1 lisp_numargs =3D -1073761480 val =3D -1073761448 internal_args =3D 0x94009b5 i =3D 155191733 #8 0x08255cde in exec_byte_code (bytestr=3D155177161, vector=3D155191733, = maxdepth=3D16, args_template=3D140240834, nargs=3D0, args=3D0x0) at bytecod= e.c:916 targets =3D [hand-removed] count =3D 55 op =3D 1 vectorp =3D 0x94009b4 stack =3D { pc =3D 0x93ed523 "\203\021",=20 byte_string =3D 155177161,=20 byte_string_start =3D 0x93ed518 "\304\030\305\031r\306q\210\307\3= 10!\203\021",=20 next =3D 0xbfffb7cc } top =3D 0xbfffb374 result =3D 0 type =3D (unknown: 12) #9 0x0821572f in funcall_lambda (fun=3D155191789, nargs=3D2, arg_vector=3D= 0x94009b5) at eval.c:3049 val =3D 136393299 syms_left =3D 140240834 next =3D 142059538 lexenv =3D 140240834 count =3D 53 i =3D 2 optional =3D true rest =3D false #10 0x08214dc1 in Ffuncall (nargs=3D3, args=3D0xbfffb78c) at eval.c:2864 fun =3D 155191789 original_fun =3D 155175722 funcar =3D 12 numargs =3D 2 lisp_numargs =3D -1073760648 val =3D 36318 internal_args =3D 0x0 i =3D 140240834 #11 0x08213d29 in Fapply (nargs=3D3, args=3D0xbfffb78c) at eval.c:2301 i =3D 135779084 numargs =3D 1 spread_arg =3D 185772774 funcall_args =3D 0x0 fun =3D 155175722 retval =3D 139835381 gcpro1 =3D { next =3D 0x855b7f0 ,=20 var =3D 0xbfffb6b8,=20 nvars =3D 135779084 } sa_count =3D 52 sa_must_free =3D false #12 0x08214a81 in Ffuncall (nargs=3D4, args=3D0xbfffb788) at eval.c:2796 fun =3D 139835381 original_fun =3D 140313602 funcar =3D 140240834 numargs =3D 3 lisp_numargs =3D -1073760424 val =3D -1073760408 internal_args =3D 0xbfffbaa8 i =3D 155191229 #13 0x08255cde in exec_byte_code (bytestr=3D142274241, vector=3D155191229, = maxdepth=3D20, args_template=3D512, nargs=3D1, args=3D0xbfffbaa8) at byteco= de.c:916 targets =3D [hand-removed] count =3D 51 op =3D 3 vectorp =3D 0x94007bc stack =3D { pc =3D 0x85c2ff9 "\207",=20 byte_string =3D 142274241,=20 byte_string_start =3D 0x85c2ff4 "\300\301\302\003#\207",=20 next =3D 0xbfffbafc } top =3D 0xbfffb788 result =3D 208 type =3D (unknown: 12) #14 0x08215365 in funcall_lambda (fun=3D155191253, nargs=3D1, arg_vector=3D= 0xbfffbaa8) at eval.c:2983 val =3D 136393299 syms_left =3D 512 next =3D -2 lexenv =3D 12 count =3D 51 i =3D 155191248 optional =3D 8 rest =3D 23 #15 0x08214dc1 in Ffuncall (nargs=3D2, args=3D0xbfffbaa4) at eval.c:2864 fun =3D 155191253 original_fun =3D 140359890 funcar =3D 5 numargs =3D 1 lisp_numargs =3D -1073759608 val =3D -8 internal_args =3D 0x85be7c2 i =3D 1 #16 0x08255cde in exec_byte_code (bytestr=3D158483249, vector=3D159321197, = maxdepth=3D32, args_template=3D140240834, nargs=3D0, args=3D0x0) at bytecod= e.c:916 targets =3D [hand-removed] count =3D 40 op =3D 1 vectorp =3D 0x97f0c6c stack =3D { pc =3D 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\00= 2\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",=20 byte_string =3D 158483249,=20 byte_string_start =3D 0xa2cc3cc "\b\204\006",=20 next =3D 0xbfffbe2c } top =3D 0xbfffbaa4 result =3D -1073759208 type =3D (unknown: 12) #17 0x0821572f in funcall_lambda (fun=3D159276165, nargs=3D6, arg_vector=3D= 0x97f0c6d) at eval.c:3049 val =3D 136393299 syms_left =3D 140240834 next =3D 164009058 lexenv =3D 140240834 count =3D 34 i =3D 6 optional =3D true rest =3D false #18 0x08214dc1 in Ffuncall (nargs=3D7, args=3D0xbfffbdd4) at eval.c:2864 fun =3D 159276165 original_fun =3D 151710058 funcar =3D 88 numargs =3D 6 lisp_numargs =3D -1073758792 val =3D 176185209 internal_args =3D 0x9869dbd i =3D 158560833 #19 0x08255cde in exec_byte_code (bytestr=3D158560633, vector=3D159817149, = maxdepth=3D36, args_template=3D140240834, nargs=3D0, args=3D0x0) at bytecod= e.c:916 targets =3D [hand-removed] count =3D 33 op =3D 6 vectorp =3D 0x9869dbc stack =3D { pc =3D 0xa28212d "\207",=20 byte_string =3D 158560633,=20 byte_string_start =3D 0xa28211c "\305\b\t\n\306\307\310\vA\311#\n= \f\235?&\006\207",=20 next =3D 0xbfffc14c } top =3D 0xbfffbdd4 result =3D 12 type =3D (unknown: 12) #20 0x0821572f in funcall_lambda (fun=3D159821221, nargs=3D5, arg_vector=3D= 0x9869dbd) at eval.c:3049 val =3D 136393299 syms_left =3D 140240834 next =3D 140361394 lexenv =3D 140240834 count =3D 28 i =3D 5 optional =3D false rest =3D false #21 0x08214dc1 in Ffuncall (nargs=3D6, args=3D0xbfffc104) at eval.c:2864 fun =3D 159821221 original_fun =3D 169426138 funcar =3D 140289744 numargs =3D 5 lisp_numargs =3D -1073757976 val =3D 140240834 internal_args =3D 0xa26df7d i =3D 28 #22 0x08255cde in exec_byte_code (bytestr=3D158561665, vector=3D170319741, = maxdepth=3D28, args_template=3D140240834, nargs=3D0, args=3D0x0) at bytecod= e.c:916 targets =3D [hand-removed] count =3D 19 op =3D 5 vectorp =3D 0xa26df7c stack =3D { pc =3D 0xa282016 "\210\202Z",=20 byte_string =3D 158561665,=20 byte_string_start =3D 0xa281fc8 "\306\307\b\"\203g",=20 next =3D 0xbfffc5cc } top =3D 0xbfffc104 result =3D 140240834 type =3D (unknown: 12) #23 0x0821572f in funcall_lambda (fun=3D159817125, nargs=3D2, arg_vector=3D= 0xa26df7d) at eval.c:3049 val =3D 136280421 syms_left =3D 140240834 next =3D 140361394 lexenv =3D 140240834 count =3D 17 i =3D 2 optional =3D false rest =3D false #24 0x0821507f in apply_lambda (fun=3D159817125, args=3D169484462) at eval.= c:2924 args_left =3D 140240834 i =3D 2 numargs =3D 2 arg_vector =3D 0xbfffc390 gcpro1 =3D { next =3D 0x817d285 ,=20 var =3D 0x9869da0,=20 nvars =3D 2 } gcpro2 =3D { next =3D 0x3e,=20 var =3D 0x0,=20 nvars =3D -1073757192 } gcpro3 =3D { next =3D 0x0,=20 var =3D 0xcda,=20 nvars =3D 191592772 } tem =3D 172259337 sa_count =3D 17 sa_must_free =3D false #25 0x08213a7f in eval_sub (form=3D169484470) at eval.c:2230 fun =3D 159817125 val =3D 140240834 original_fun =3D 169426090 original_args =3D 169484462 funcar =3D 190099238 gcpro1 =3D { next =3D 0xb6e1c440 ,=20 var =3D 0x0,=20 nvars =3D 9208 } gcpro2 =3D { next =3D 0x81fb0c5 ,=20 var =3D 0x20,=20 nvars =3D 528 } gcpro3 =3D { next =3D 0x8872045,=20 var =3D 0xd,=20 nvars =3D -1073757016 } #26 0x082119d5 in internal_lisp_condition_case (var=3D141981354, bodyform= =3D169484470, handlers=3D169484062) at eval.c:1323 val =3D 140240834 c =3D 0x85ccfd8 oldhandlerlist =3D 0x85cc468 clausenb =3D 1 #27 0x08256bac in exec_byte_code (bytestr=3D158562761, vector=3D161535597, = maxdepth=3D12, args_template=3D140240834, nargs=3D0, args=3D0x0) at bytecod= e.c:1162 handlers =3D 169484062 body =3D 169484470 targets =3D [hand-removed] count =3D 16 op =3D 143 vectorp =3D 0x9a0d66c stack =3D { pc =3D 0xa281f60 "\207\306\t\n\"\207",=20 byte_string =3D 158562761,=20 byte_string_start =3D 0xa281f58 "\b\203\t",=20 next =3D 0xbfffc8dc } top =3D 0xbfffc594 result =3D 140240834 type =3D (unknown: 12) #28 0x0821572f in funcall_lambda (fun=3D161535629, nargs=3D2, arg_vector=3D= 0x9a0d66d) at eval.c:3049 val =3D 136393299 syms_left =3D 140240834 next =3D 140361394 lexenv =3D 140240834 count =3D 14 i =3D 2 optional =3D false rest =3D false #29 0x08214dc1 in Ffuncall (nargs=3D3, args=3D0xbfffc8a4) at eval.c:2864 fun =3D 161535629 original_fun =3D 169426018 funcar =3D 12 numargs =3D 2 lisp_numargs =3D 0 val =3D -1073756024 internal_args =3D 0x9866de5 i =3D 0 #30 0x08255cde in exec_byte_code (bytestr=3D162182137, vector=3D159804901, = maxdepth=3D12, args_template=3D140240834, nargs=3D0, args=3D0x0) at bytecod= e.c:916 targets =3D [hand-removed] count =3D 13 op =3D 2 vectorp =3D 0x9866de4 stack =3D { pc =3D 0xa281eb0 "\207",=20 byte_string =3D 162182137,=20 byte_string_start =3D 0xa281eac "\302\b\t\"\207",=20 next =3D 0xbfffcd4c } top =3D 0xbfffc8a4 result =3D 140240834 type =3D (unknown: 12) #31 0x0821572f in funcall_lambda (fun=3D160247229, nargs=3D1, arg_vector=3D= 0x9866de5) at eval.c:3049 val =3D 136393299 syms_left =3D 140240834 next =3D 140241770 lexenv =3D 140240834 count =3D 12 i =3D 1 optional =3D false rest =3D false #32 0x08214dc1 in Ffuncall (nargs=3D2, args=3D0xbfffcbb8) at eval.c:2864 fun =3D 160247229 original_fun =3D 160247229 funcar =3D 100000000 numargs =3D 1 lisp_numargs =3D 137829253 val =3D 140240834 internal_args =3D 0x11 i =3D 190654374 #33 0x0821467b in call1 (fn=3D160247229, arg1=3D172259337) at eval.c:2614 ret_ungc_val =3D 140240834 gcpro1 =3D { next =3D 0xa447c41,=20 var =3D 0x0,=20 nvars =3D 2 } args =3D {160247229, 172259337} #34 0x0821f42b in mapcar1 (leni=3D60, vals=3D0x0, fn=3D160247229, seq=3D190= 654006) at fns.c:2329 tail =3D 190653870 dummy =3D 140240834 i =3D 17 gcpro1 =3D { next =3D 0x85be7c2,=20 var =3D 0x85be7c2,=20 nvars =3D 1405328919 } gcpro2 =3D { next =3D 0xc,=20 var =3D 0xbfffcc38,=20 nvars =3D 136414020 } gcpro3 =3D { next =3D 0xbfffcc08,=20 var =3D 0x817d327 ,=20 nvars =3D 190654006 } #35 0x0821f7ad in Fmapc (function=3D160247229, sequence=3D190654006) at fns= .c:2418 leni =3D 60 #36 0x08214bb3 in Ffuncall (nargs=3D3, args=3D0xbfffcd04) at eval.c:2818 fun =3D 139837541 original_fun =3D 140280338 funcar =3D 5 numargs =3D 2 lisp_numargs =3D -1073754904 val =3D 190654006 internal_args =3D 0xbfffcd08 i =3D 5161 #37 0x08255cde in exec_byte_code (bytestr=3D162182313, vector=3D160296045, = maxdepth=3D28, args_template=3D140240834, nargs=3D0, args=3D0x0) at bytecod= e.c:916 targets =3D [hand-removed] count =3D 9 op =3D 2 vectorp =3D 0x98dec6c stack =3D { pc =3D 0xa281e80 "\210=CE=89\023)\207",=20 byte_string =3D 162182313,=20 byte_string_start =3D 0xa281e58 "\304\b\t\"\210\305\b!\210r\306\b= !q\210\307 \022\v\tP\211\023\211GSH\310U\205,",=20 next =3D 0x0 } top =3D 0xbfffcd04 result =3D 139835376 type =3D (unknown: 12) #38 0x0821572f in funcall_lambda (fun=3D159808989, nargs=3D2, arg_vector=3D= 0x98dec6d) at eval.c:3049 val =3D 136393299 syms_left =3D 140240834 next =3D 144181106 lexenv =3D 140240834 count =3D 7 i =3D 2 optional =3D false rest =3D false #39 0x08214dc1 in Ffuncall (nargs=3D3, args=3D0xbfffd020) at eval.c:2864 fun =3D 159808989 original_fun =3D 170495538 funcar =3D -1073754112 numargs =3D 2 lisp_numargs =3D -1073754088 val =3D -1073754120 internal_args =3D 0xbfffd020 i =3D -1073754112 #40 0x082140f0 in Fapply (nargs=3D2, args=3D0xbfffd0a4) at eval.c:2354 i =3D 3 numargs =3D 2 spread_arg =3D 140240834 funcall_args =3D 0xbfffd020 fun =3D 159808989 retval =3D 142097605 gcpro1 =3D { next =3D 0x8783cc0,=20 var =3D 0xbfffd068,=20 nvars =3D 3 } sa_count =3D 6 sa_must_free =3D false #41 0x08214626 in apply1 (fn=3D170495538, arg=3D190654414) at eval.c:2588 ret_ungc_val =3D 6 args =3D {170495538, 190654414} gcpro1 =3D { next =3D 0x817bebf ,=20 var =3D 0xbfffd0a4,=20 nvars =3D 2 } #42 0x0826187d in read_process_output_call (fun_and_args=3D190654406) at pr= ocess.c:4964 No locals. #43 0x08211c11 in internal_condition_case_1 (bfun=3D0x82617f0 , arg=3D190654406, handlers=3D140240834, hfun=3D0x826187f ) at eval.c:1378 val =3D 190654414 c =3D 0x85cc468 #44 0x08261e44 in read_and_dispose_of_process_output (p=3D0xab6a4f0,=20 chars=3D0xbfffd190 " like to thank Private Internet Access\r\n:verne.fr= eenode.net 372 YoungFrog :- (https://www.privateinternetaccess.com/) and th= e other\r\n:verne.freenode.net 372 YoungFrog :- organisations that help kee= p f"...,=20 nbytes=3D1126, coding=3D0xa17db78) at process.c:5177 outstream =3D 170495538 text =3D 172260417 outer_running_asynch_code =3D false waiting =3D -1 #45 0x08261b66 in read_process_output (proc=3D179741941, channel=3D1126) at= process.c:5086 nbytes =3D 1126 chars =3D 0xbfffd190 " like to thank Private Internet Access\r\n:ve= rne.freenode.net 372 YoungFrog :- (https://www.privateinternetaccess.com/) = and the other\r\n:verne.freenode.net 372 YoungFrog :- organisations that he= lp keep f"... p =3D 0xab6a4f0 coding =3D 0xa17db78 carryover =3D 0 readmax =3D 4096 count =3D 3 odeactivate =3D 140240834 #46 0x0826121e in wait_reading_process_output (time_limit=3D30, nsecs=3D0, = read_kbd=3D-1, do_display=3Dtrue, wait_for_cell=3D140240834, wait_proc=3D0x= 0, just_wait_proc=3D0) at process.c:4808 nread =3D 134682442 timeout_reduced_for_timers =3D true channel =3D 12 nfds =3D 1 Available =3D { fds_bits =3D {4096, 0 } } Writeok =3D { fds_bits =3D {0 } } check_write =3D true check_delay =3D 0 no_avail =3D false xerrno =3D 11 proc =3D 179741941 timeout =3D { tv_sec =3D 0,=20 tv_nsec =3D 84131398 } end_time =3D { tv_sec =3D 1405328949,=20 tv_nsec =3D 388317164 } wait_channel =3D -1 got_some_input =3D true count =3D 2 #47 0x08064253 in sit_for (timeout=3D120, reading=3Dtrue, display_option=3D= 1) at dispnew.c:5854 sec =3D 30 nsec =3D 0 do_display =3D true #48 0x08187251 in read_char (commandflag=3D1, map=3D190657822, prev_event= =3D140240834, used_mouse_menu=3D0xbfffe883, end_time=3D0x0) at keyboard.c:2= 809 tem0 =3D -1 timeout =3D 30 delay_level =3D 4 buffer_size =3D 58 c =3D 140240834 jmpcount =3D 2 local_getcjmp =3D {{ __jmpbuf =3D {0, 0, 0, -1073748056, 224214774, -1035889255},=20 __mask_was_saved =3D 0,=20 __saved_mask =3D { __val =3D {142358288, 3221219000, 136428008, 140240834, 16966= 1584, 142358288, 142618912, 34569, 0, 3221219096, 135916180, 142618914, 140= 240858, 3221219048, 135773887, 190657830, 190657830, 6, 6, 146706358, 0, 32= 21219096,=20 136248700, 190657830, 190657838, 142618914, 142445350, 1402= 40834, 140240834, 2, 140240834, 0} } }} save_jump =3D {{ __jmpbuf =3D {-1227516652, -1073765192, -1073765016, 0, -107376= 4992, -1226580033},=20 __mask_was_saved =3D -1073765016,=20 __saved_mask =3D { __val =3D {3067450473, 3066474484, 1, 171890800, 3221202280, = 3066369452, 13, 3221202408, 4294967285, 0, 171890800, 3068396128, 306840650= 1, 3066378700, 13, 171890888, 4096, 0, 171890836, 8, 3066369033, 3221202276= , 171890800,=20 3066375302, 3066474484, 3066370758, 171895036, 4294967295, = 3221202276, 3221202280, 0, 136570541} } }} tem =3D 140240834 save =3D 169526782 previous_echo_area_message =3D 140240834 also_record =3D 140240834 reread =3D false gcpro1 =3D { next =3D 0x85c41b2,=20 var =3D 0xbfffe6d8,=20 nvars =3D 136323248 } gcpro2 =3D { next =3D 0x21c20,=20 var =3D 0x0,=20 nvars =3D 0 } polling_stopped_here =3D false orig_kboard =3D 0xb3292e8 #49 0x0819478f in read_key_sequence (keybuf=3D0xbfffe9a0, bufsize=3D30, pro= mpt=3D140240834, dont_downcase_last=3Dfalse, can_return_switch_frame=3Dtrue= , fix_current_buffer=3Dtrue, prevent_redisplay=3Dfalse) at keyboard.c:9088 interrupted_kboard =3D 0xb3292e8 interrupted_frame =3D 0x98e9c68 key =3D 169661589 used_mouse_menu =3D false echo_local_start =3D 0 last_real_key_start =3D 0 keys_local_start =3D 0 new_binding =3D 169661584 count =3D 2 t =3D 0 echo_start =3D 0 keys_start =3D 0 current_binding =3D 190657822 first_event =3D 140240834 first_unbound =3D 31 mock_input =3D 0 fkey =3D { parent =3D 188709838,=20 map =3D 188709838,=20 start =3D 0,=20 end =3D 0 } keytran =3D { parent =3D 140228366,=20 map =3D 140228366,=20 start =3D 0,=20 end =3D 0 } indec =3D { parent =3D 188709830,=20 map =3D 188709830,=20 start =3D 0,=20 end =3D 0 } shift_translated =3D false delayed_switch_frame =3D 140240834 original_uppercase =3D 135779138 original_uppercase_position =3D -1 dummyflag =3D false starting_buffer =3D 0xa1cd490 fake_prefixed_keys =3D 140240834 gcpro1 =3D { next =3D 0x85be7c2,=20 var =3D 0xbfffe8a8,=20 nvars =3D 136285844 } #50 0x08184120 in command_loop_1 () at keyboard.c:1452 cmd =3D 150156170 keybuf =3D {12, 268435584, 137757649, 170495586, 140312882, 1402408= 34, 4, 140240834, 142376306, 0, -1073747480, 135804890, 140271938, 18790973= 4, 137757649, 170495586, 187863784, 0, -1073747384, 135804666, 187909734, -= 1073747441,=20 -1073747416, 136392923, 2, 165381745, -1227960375, 0, 0, 0} i =3D 2 prev_modiff =3D 424 prev_buffer =3D 0xa2c3408 already_adjusted =3D false #51 0x08211aef in internal_condition_case (bfun=3D0x8183d9f , handlers=3D140273914, hfun=3D0x81835ce ) at eval.c:1354 val =3D 165381745 c =3D 0x85cc390 #52 0x08183a49 in command_loop_2 (ignore=3D140240834) at keyboard.c:1177 val =3D 0 #53 0x0821106a in internal_catch (tag=3D140271962, func=3D0x8183a25 , arg=3D140240834) at eval.c:1118 val =3D 140240834 c =3D 0x8994248 #54 0x08183a03 in command_loop () at keyboard.c:1156 No locals. #55 0x08183162 in recursive_edit_1 () at keyboard.c:777 count =3D 1 val =3D -1073747160 #56 0x08183322 in Frecursive_edit () at keyboard.c:848 count =3D 0 buffer =3D 140240834 #57 0x08181663 in main (argc=3D2, argv=3D0xbfffecb4) at emacs.c:1646 dummy =3D 2 stack_bottom_variable =3D 0 '\000' do_initial_setlocale =3D true dumping =3D false skip_args =3D 1 rlim =3D { rlim_cur =3D 8388608,=20 rlim_max =3D 18446744073709551615 } no_loadup =3D false junk =3D 0x0 dname_arg =3D 0x0 ch_to_dir =3D 0x0 original_pwd =3D 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=3Dlucid --enable-checking 'CFLAGS=3D -O0 -g3'' Important settings: value of $LANG: fr_FR.UTF-8 locale-coding-system: utf-8-unix --=20 Nico. From debbugs-submit-bounces@debbugs.gnu.org Mon Jul 14 06:07:07 2014 Received: (at 18013) by debbugs.gnu.org; 14 Jul 2014 10:07:07 +0000 Received: from localhost ([127.0.0.1]:54204 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1X6d9z-0004AY-I0 for submit@debbugs.gnu.org; Mon, 14 Jul 2014 06:07:07 -0400 Received: from cantor2.suse.de ([195.135.220.15]:35694 helo=mx2.suse.de) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1X6d9t-0004A4-Lx for 18013@debbugs.gnu.org; Mon, 14 Jul 2014 06:07:01 -0400 Received: from relay2.suse.de (charybdis-ext.suse.de [195.135.220.254]) by mx2.suse.de (Postfix) with ESMTP id 95E56AB5D; Mon, 14 Jul 2014 10:06:56 +0000 (UTC) From: Andreas Schwab To: Nicolas Richard Subject: Re: bug#18013: 24.3.92; Infloop in re_search_2 References: <87oaws9sp2.fsf@geodiff-mac3.ulb.ac.be> X-Yow: Yow! Is this sexual intercourse yet?? Is it, huh, is it?? Date: Mon, 14 Jul 2014 12:06:55 +0200 In-Reply-To: <87oaws9sp2.fsf@geodiff-mac3.ulb.ac.be> (Nicolas Richard's message of "Mon, 14 Jul 2014 11:48:41 +0200") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -5.0 (-----) X-Debbugs-Envelope-To: 18013 Cc: 18013@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -5.0 (-----) Nicolas Richard 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." From debbugs-submit-bounces@debbugs.gnu.org Mon Jul 14 06:13:49 2014 Received: (at 18013) by debbugs.gnu.org; 14 Jul 2014 10:13:49 +0000 Received: from localhost ([127.0.0.1]:54213 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1X6dGT-0004LU-GV for submit@debbugs.gnu.org; Mon, 14 Jul 2014 06:13:49 -0400 Received: from mxin.ulb.ac.be ([164.15.128.112]:53275) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1X6dGN-0004LD-LJ for 18013@debbugs.gnu.org; Mon, 14 Jul 2014 06:13:43 -0400 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AisGANCsw1OkD4Xx/2dsb2JhbABZsEoBAQEBAQEGnG0BgS51hAQBBAF5BQsLISUPAQRJExmIFAEDCQixUY1iAYd/F4V7giKFAYItB4RDAQSEbAWUI4h0hF2CMIYWg0Y7 Received: from mathsrv4.ulb.ac.be (HELO geodiff-mac3.ulb.ac.be) ([164.15.133.241]) by smtp.ulb.ac.be with ESMTP; 14 Jul 2014 12:13:38 +0200 From: Nicolas Richard To: Andreas Schwab Subject: Re: bug#18013: 24.3.92; Infloop in re_search_2 References: <87oaws9sp2.fsf@geodiff-mac3.ulb.ac.be> Date: Mon, 14 Jul 2014 12:15:26 +0200 In-Reply-To: (Andreas Schwab's message of "Mon, 14 Jul 2014 12:06:55 +0200") Message-ID: <87ion09rgh.fsf@geodiff-mac3.ulb.ac.be> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3.92 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 18013 Cc: Nicolas Richard , 18013@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -2.3 (--) Andreas Schwab writes: > Nicolas Richard 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. From debbugs-submit-bounces@debbugs.gnu.org Mon Jul 14 07:10:57 2014 Received: (at 18013) by debbugs.gnu.org; 14 Jul 2014 11:10:57 +0000 Received: from localhost ([127.0.0.1]:54241 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1X6e9l-0005tW-Ct for submit@debbugs.gnu.org; Mon, 14 Jul 2014 07:10:57 -0400 Received: from mxin.ulb.ac.be ([164.15.128.112]:19048) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1X6e9f-0005tF-JP for 18013@debbugs.gnu.org; Mon, 14 Jul 2014 07:10:51 -0400 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AooFALS5w1OkD4Xx/2dsb2JhbABZhyupJAEBAQEBAQacbQGBLnWEBAEEASNWBQsLGgIfBwICEARJE4gtAQMJCK9vgXKNZQGHfxeBLIRPgiKFAYF6MweCd4FMBYRsBZQjiHSEXYIwhheCAoFEOw Received: from mathsrv4.ulb.ac.be (HELO geodiff-mac3.ulb.ac.be) ([164.15.133.241]) by smtp.ulb.ac.be with ESMTP; 14 Jul 2014 13:10:46 +0200 From: Nicolas Richard To: Andreas Schwab Subject: Re: bug#18013: 24.3.92; looking-back "[^\n]" taking a lot of time in large buffers (was: Infloop in re_search_2) References: <87oaws9sp2.fsf@geodiff-mac3.ulb.ac.be> Date: Mon, 14 Jul 2014 13:12:34 +0200 In-Reply-To: (Andreas Schwab's message of "Mon, 14 Jul 2014 12:06:55 +0200") Message-ID: <878unw9ot9.fsf_-_@geodiff-mac3.ulb.ac.be> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3.92 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 18013 Cc: Nicolas Richard , 18013@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -2.3 (--) Andreas Schwab writes: > Nicolas Richard 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=3D1MB iflag=3Dfullblock count=3D50 > foobartest=20 50+0=C2=A0enregistrements lus 50+0=C2=A0enregistrements =C3=A9crits 50000000=C2=A0octets (50 MB) copi=C3=A9s, 0,853576=C2=A0s, 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 "fo= obartest") (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. --=20 Nico. From debbugs-submit-bounces@debbugs.gnu.org Mon Jul 14 11:40:08 2014 Received: (at control) by debbugs.gnu.org; 14 Jul 2014 15:40:08 +0000 Received: from localhost ([127.0.0.1]:54800 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1X6iMJ-0005aL-Cr for submit@debbugs.gnu.org; Mon, 14 Jul 2014 11:40:07 -0400 Received: from fencepost.gnu.org ([208.118.235.10]:47636 ident=Debian-exim) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1X6iMG-0005aC-WA for control@debbugs.gnu.org; Mon, 14 Jul 2014 11:40:05 -0400 Received: from rgm by fencepost.gnu.org with local (Exim 4.71) (envelope-from ) id 1X6iMG-0001Eh-8S for control@debbugs.gnu.org; Mon, 14 Jul 2014 11:40:04 -0400 Date: Mon, 14 Jul 2014 11:40:04 -0400 Message-Id: Subject: control message for bug 18013 To: X-Mailer: mail (GNU Mailutils 2.1) From: Glenn Morris X-Spam-Score: -5.0 (-----) X-Debbugs-Envelope-To: control X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -5.0 (-----) retitle 18013 looking-back is inefficient severity 18013 minor From debbugs-submit-bounces@debbugs.gnu.org Tue Jul 15 02:07:56 2014 Received: (at submit) by debbugs.gnu.org; 15 Jul 2014 06:07:56 +0000 Received: from localhost ([127.0.0.1]:55217 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1X6vu7-0006PA-OO for submit@debbugs.gnu.org; Tue, 15 Jul 2014 02:07:56 -0400 Received: from eggs.gnu.org ([208.118.235.92]:58195) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1X6vu5-0006Ot-1D for submit@debbugs.gnu.org; Tue, 15 Jul 2014 02:07:53 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1X6vtp-0002Jy-Ht for submit@debbugs.gnu.org; Tue, 15 Jul 2014 02:07:47 -0400 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org X-Spam-Level: X-Spam-Status: No, score=0.8 required=5.0 tests=BAYES_50,FREEMAIL_FROM autolearn=disabled version=3.3.2 Received: from lists.gnu.org ([2001:4830:134:3::11]:41173) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1X6vtp-0002Jp-FH for submit@debbugs.gnu.org; Tue, 15 Jul 2014 02:07:37 -0400 Received: from eggs.gnu.org ([2001:4830:134:3::10]:59694) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1X6vth-0006od-T6 for bug-gnu-emacs@gnu.org; Tue, 15 Jul 2014 02:07:37 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1X6vta-0002BG-E3 for bug-gnu-emacs@gnu.org; Tue, 15 Jul 2014 02:07:29 -0400 Received: from plane.gmane.org ([80.91.229.3]:54656) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1X6vta-0002Ar-72 for bug-gnu-emacs@gnu.org; Tue, 15 Jul 2014 02:07:22 -0400 Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1X6vtY-00050I-0X for bug-gnu-emacs@gnu.org; Tue, 15 Jul 2014 08:07:20 +0200 Received: from 71-212-253-190.hlrn.qwest.net ([71.212.253.190]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 15 Jul 2014 08:07:20 +0200 Received: from kevin.d.rodgers by 71-212-253-190.hlrn.qwest.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 15 Jul 2014 08:07:20 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: bug-gnu-emacs@gnu.org From: Kevin Rodgers Subject: Re: bug#18013: 24.3.92; looking-back "[^\n]" taking a lot of time in large buffers Date: Tue, 15 Jul 2014 00:08:01 -0600 Lines: 13 Message-ID: References: <87oaws9sp2.fsf@geodiff-mac3.ulb.ac.be> <878unw9ot9.fsf_-_@geodiff-mac3.ulb.ac.be> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: 71-212-253-190.hlrn.qwest.net User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.4; en-US; rv:1.9.2.28) Gecko/20120306 Thunderbird/3.1.20 In-Reply-To: <878unw9ot9.fsf_-_@geodiff-mac3.ulb.ac.be> X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-Received-From: 2001:4830:134:3::11 X-Spam-Score: -4.1 (----) X-Debbugs-Envelope-To: submit X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -4.1 (----) 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 From debbugs-submit-bounces@debbugs.gnu.org Tue Jul 15 03:21:16 2014 Received: (at 18013) by debbugs.gnu.org; 15 Jul 2014 07:21:16 +0000 Received: from localhost ([127.0.0.1]:55242 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1X6x35-0008HP-KV for submit@debbugs.gnu.org; Tue, 15 Jul 2014 03:21:15 -0400 Received: from cantor2.suse.de ([195.135.220.15]:52440 helo=mx2.suse.de) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1X6x33-0008HE-8L for 18013@debbugs.gnu.org; Tue, 15 Jul 2014 03:21:14 -0400 Received: from relay2.suse.de (charybdis-ext.suse.de [195.135.220.254]) by mx2.suse.de (Postfix) with ESMTP id 7F6E4AC47; Tue, 15 Jul 2014 07:21:12 +0000 (UTC) From: Andreas Schwab To: Kevin Rodgers Subject: Re: bug#18013: 24.3.92; looking-back "[^\n]" taking a lot of time in large buffers References: <87oaws9sp2.fsf@geodiff-mac3.ulb.ac.be> <878unw9ot9.fsf_-_@geodiff-mac3.ulb.ac.be> X-Yow: --Hello, POLICE? I"ve got ABBOTT & COSTELLO here on suspicion of HIGHWAY ROBBERY!! Date: Tue, 15 Jul 2014 09:21:12 +0200 In-Reply-To: (Kevin Rodgers's message of "Tue, 15 Jul 2014 00:08:01 -0600") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -5.0 (-----) X-Debbugs-Envelope-To: 18013 Cc: 18013@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -5.0 (-----) Kevin Rodgers 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." From debbugs-submit-bounces@debbugs.gnu.org Sat Mar 25 16:58:48 2017 Received: (at 18013) by debbugs.gnu.org; 25 Mar 2017 20:58:48 +0000 Received: from localhost ([127.0.0.1]:44703 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1crsls-00070f-4n for submit@debbugs.gnu.org; Sat, 25 Mar 2017 16:58:48 -0400 Received: from mail-it0-f48.google.com ([209.85.214.48]:35149) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1crslp-00070K-9G; Sat, 25 Mar 2017 16:58:46 -0400 Received: by mail-it0-f48.google.com with SMTP id y18so39608685itc.0; Sat, 25 Mar 2017 13:58:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:from:to:cc:subject:references:date:in-reply-to:message-id :user-agent:mime-version; bh=9e/cz1LkRulhxJTSh/f6o2buxiIdvGRrh3hJAzThzsU=; b=rke0603rHSobJLu6hqt+XwuMAMgXuPnKKMP49PEiXkXPQkZO5KjW9Fy7wmSASKHnN8 Od3pJ3riwNdBlBN74LmA17Oy4qfedA1MWs/I8Rh9oxglLmiVfoVZ7aLJwcT9KcYPu51l 31woSuW5J+pXY+FDxikVTWvrivcANoAwpUhoe5rqtkbf8SjJiJjh8Qj87/BFnqq+vJlP FJ0LVeumIMlFnUBima0v/HdADG///QT8UOKQKBVASVeCUfSgBGTCpFqXN5ZLIUbaoR4c s1nLl6/TQ88vaTTfXxjxsJmqUWA+k3PZGk/YQaHPzwCikn/qkf9p1C5D2oB3CYYEknxf RPjw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:from:to:cc:subject:references:date :in-reply-to:message-id:user-agent:mime-version; bh=9e/cz1LkRulhxJTSh/f6o2buxiIdvGRrh3hJAzThzsU=; b=r8OHS3K5pwHVvQyTIbj4Cmak5d3pWDcxx2m84rw4gPQu+WiZvi0CNP3MHhpct7oiAn mPS88XMbs0Xwew69/z8sTYPhbpQQzY+Ct8mFSIZ9hYyqJg1tGt0/GxPqy1SUhBYnbLVt m/tuMP4prlKdTmeKGKhgSgtUwVObeKlbCmmwRkGIK6xF98krck5OCdcv8v713PbFPS8u RHl8sWaXkpKRH+I5amZ7oyvGZUju0Rs6g6Hyg3s8JW3NHrZo63nK6nOy+oEebYuHVC3f AD6iXE5N03xJlKvIWxG+d+Z3e4IaoiBSmRuxA3jizjVVBIURE41tkrKqTSafL0JIuBtP tKKA== X-Gm-Message-State: AFeK/H1n53REan2NDj6WJic2k7rN9qSzflu0oUW/1O0A07AghFFGj5FcyUZpXuxFienTBw== X-Received: by 10.36.54.149 with SMTP id l143mr3040301itl.38.1490475519539; Sat, 25 Mar 2017 13:58:39 -0700 (PDT) Received: from zony ([45.2.7.65]) by smtp.googlemail.com with ESMTPSA id w133sm2968580itf.2.2017.03.25.13.58.38 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Sat, 25 Mar 2017 13:58:39 -0700 (PDT) From: npostavs@users.sourceforge.net To: Nicolas Richard Subject: Re: bug#18013: 24.3.92; looking-back "[^\n]" taking a lot of time in large buffers References: <87oaws9sp2.fsf@geodiff-mac3.ulb.ac.be> <878unw9ot9.fsf_-_@geodiff-mac3.ulb.ac.be> Date: Sat, 25 Mar 2017 16:59:51 -0400 In-Reply-To: <878unw9ot9.fsf_-_@geodiff-mac3.ulb.ac.be> (Nicolas Richard's message of "Mon, 14 Jul 2014 13:12:34 +0200") Message-ID: <87o9wp5ayg.fsf@users.sourceforge.net> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: 0.7 (/) X-Debbugs-Envelope-To: 18013 Cc: Andreas Schwab , 18013@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 0.7 (/) tags 18013 wontfix close 18013 quit Nicolas Richard 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))) From unknown Fri Aug 15 16:00:19 2025 Received: (at fakecontrol) by fakecontrolmessage; To: internal_control@debbugs.gnu.org From: Debbugs Internal Request Subject: Internal Control Message-Id: bug archived. Date: Sun, 23 Apr 2017 11:24:04 +0000 User-Agent: Fakemail v42.6.9 # This is a fake control message. # # The action: # bug archived. thanks # This fakemail brought to you by your local debbugs # administrator