GNU bug report logs - #12196
24.1.50; setting cache-long-line-scans to non-nil freezes Emacs

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 12196 in the body.
You can then email your comments to 12196 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Michael Heerdegen <michael_heerdegen <at> web.de>
To: bug-gnu-emacs <at> gnu.org
Subject: 24.1.50; setting cache-long-line-scans to non-nil freezes Emacs
Date: Tue, 14 Aug 2012 06:54:28 +0200

Hi,

I recently found this variable in the manual: `cache-long-line-scans'.

However, nearly every time I set it to a non-nil value, Emacs instantly
freezes, C-g has no more effect.

To reproduce in emacs -Q, e.g. type C-h n and then M-:
(setq cache-long-line-scans t).


Thanks,

Michael.


In GNU Emacs 24.1.50.1 (i486-pc-linux-gnu, GTK+ Version 3.4.2)
 of 2012-08-07 on dex, modified by Debian
 (emacs-snapshot package, version 2:20120807-1)
Windowing system distributor `The X.Org Foundation', version 11.0.11203000
Configured using:
 `configure '--build' 'i486-linux-gnu' '--host' 'i486-linux-gnu'
 '--prefix=/usr' '--sharedstatedir=/var/lib' '--libexecdir=/usr/lib'
 '--localstatedir=/var' '--infodir=/usr/share/info'
 '--mandir=/usr/share/man' '--with-pop=yes'
 '--enable-locallisppath=/etc/emacs-snapshot:/etc/emacs:/usr/local/share/emacs/24.1.50/site-lisp:/usr/local/share/emacs/site-lisp:/usr/share/emacs/24.1.50/site-lisp:/usr/share/emacs/site-lisp'
 '--without-compress-info' '--with-crt-dir=/usr/lib/i386-linux-gnu/'
 '--with-x=yes' '--with-x-toolkit=gtk3' '--with-imagemagick=yes'
 'build_alias=i486-linux-gnu' 'host_alias=i486-linux-gnu'
 'CFLAGS=-DDEBIAN -DSITELOAD_PURESIZE_EXTRA=5000 -g -O2' 'LDFLAGS=-g
 -Wl,--as-needed -znocombreloc' 'CPPFLAGS=-D_FORTIFY_SOURCE=2''

Message #8 received at 12196 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: michael_heerdegen <at> web.de
Cc: 12196 <at> debbugs.gnu.org
Subject: Re: bug#12196: 24.1.50;
	setting cache-long-line-scans to non-nil freezes Emacs
Date: Wed, 15 Aug 2012 19:36:05 +0300

> Date: Tue, 14 Aug 2012 06:54:28 +0200
> From: Michael Heerdegen <michael_heerdegen <at> web.de>
> 
> I recently found this variable in the manual: `cache-long-line-scans'.
> 
> However, nearly every time I set it to a non-nil value, Emacs instantly
> freezes, C-g has no more effect.

For me, it didn't freeze, it simply announced that memory was
exhausted and I should exit and restart Emacs.  Under a debugger I saw
that the region cache code tried to allocate some ridiculously large
chunk of memory, like 1.6 GB.  This happened because some changes
about a year ago modified the memory allocation for the cache in a way
that made the cache data structure and the memory it allocated
inconsistent.  So the cache became confused and tried to allocate
more and more memory.

Should be fixed now (revision 109631 on the trunk), please test.

Message #11 received at 12196 <at> debbugs.gnu.org (full text, mbox):

From: Michael Heerdegen <michael_heerdegen <at> web.de>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 12196 <at> debbugs.gnu.org
Subject: Re: bug#12196: 24.1.50;
	setting cache-long-line-scans to non-nil freezes Emacs
Date: Fri, 24 Aug 2012 14:19:34 +0200

Eli Zaretskii <eliz <at> gnu.org> writes:

> Should be fixed now (revision 109631 on the trunk), please test.

Thanks, Eli.  However, I still see the freezing.  I have 

   GNU Emacs 24.2.50.1 (i486-pc-linux-gnu, GTK+ Version 3.4.2)
   of 2012-08-23 on dex, modified by Debian

now, so your fix should be included.

In emacs -Q, I did C-x d ~ RET and set `cache-long-line-scans' to t.
Then I moved around in that buffer with the arrow keys and prior/ next.
After a few seconds, Emacs was frozen.

In another test, I started emacs -Q and evaluated

  (setq-default cache-long-line-scans t)

Then I did some trivial things like changing current buffer and moving
around.  In some cases, CPU consumption went to 100% while I did
nothing, and Emacs didn't respond anymore.  Another time, Emacs aborted.


Thanks,

Michael.

Message #14 received at 12196 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Michael Heerdegen <michael_heerdegen <at> web.de>
Cc: 12196 <at> debbugs.gnu.org
Subject: Re: bug#12196: 24.1.50;
	setting cache-long-line-scans to non-nil freezes Emacs
Date: Fri, 24 Aug 2012 16:35:32 +0300

> From: Michael Heerdegen <michael_heerdegen <at> web.de>
> Cc: 12196 <at> debbugs.gnu.org
> Date: Fri, 24 Aug 2012 14:19:34 +0200
> 
> Thanks, Eli.  However, I still see the freezing.  I have 
> 
>    GNU Emacs 24.2.50.1 (i486-pc-linux-gnu, GTK+ Version 3.4.2)
>    of 2012-08-23 on dex, modified by Debian
> 
> now, so your fix should be included.

Do you see a reference to bug#12196 in src/ChangeLog of that
distribution?  If not, then my fix is not included.

> In emacs -Q, I did C-x d ~ RET and set `cache-long-line-scans' to t.
> Then I moved around in that buffer with the arrow keys and prior/ next.
> After a few seconds, Emacs was frozen.
> 
> In another test, I started emacs -Q and evaluated
> 
>   (setq-default cache-long-line-scans t)
> 
> Then I did some trivial things like changing current buffer and moving
> around.  In some cases, CPU consumption went to 100% while I did
> nothing, and Emacs didn't respond anymore.  Another time, Emacs aborted.

I cannot reproduce any of this on my system.  Emacs never freezes on
me.

Does Emacs really freeze, or does it just do some prolonged operation?
(And is your CPU really an i486?)  If you wait for a long time, does
Emacs eventually recover and become responsive again?

If Emacs really freezes, attach a debugger to it when it does, type
"bt" at the debugger's prompt, and post here everything the debugger
displays in response.  Then try to follow the advice in etc/DEBUG,
under "If the symptom of the bug is that Emacs fails to respond", to
establish which Emacs function, if any, is looping.

Message #17 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Christopher Schmidt <christopher <at> ch.ristopher.com>
To: bug-gnu-emacs <at> gnu.org
Subject: Re: bug#12196: 24.1.50;
	setting cache-long-line-scans to non-nil freezes Emacs
Date: Sun, 26 Aug 2012 12:53:49 +0100 (BST)

[Message part 1 (text/plain, inline)]

Eli Zaretskii <eliz <at> gnu.org> writes:
>> In emacs -Q, I did C-x d ~ RET and set `cache-long-line-scans' to t.
>> Then I moved around in that buffer with the arrow keys and prior/
>> next.  After a few seconds, Emacs was frozen.
>>
>> In another test, I started emacs -Q and evaluated
>>
>>   (setq-default cache-long-line-scans t)
>>
>> Then I did some trivial things like changing current buffer and
>> moving around.  In some cases, CPU consumption went to 100% while I
>> did nothing, and Emacs didn't respond anymore.  Another time, Emacs
>> aborted.
>
> I cannot reproduce any of this on my system.  Emacs never freezes on
> me.
>
> Does Emacs really freeze, or does it just do some prolonged operation?
> (And is your CPU really an i486?)  If you wait for a long time, does
> Emacs eventually recover and become responsive again?
>
> If Emacs really freezes, attach a debugger to it when it does, type
> "bt" at the debugger's prompt, and post here everything the debugger
> displays in response.  Then try to follow the advice in etc/DEBUG,
> under "If the symptom of the bug is that Emacs fails to respond", to
> establish which Emacs function, if any, is looping.

I can reproduce this problem.  I am using GNU Emacs 24.2.50.3
(x86_64-unknown-linux-gnu, GTK+ Version 2.24.10) of 2012-08-26, revno:
109786.

Setting cache-long-line-scans to t in various buffer that are meant to
be displayed in a window, such as *Info*, *Help* etc., works just fine.
Setting the default value of cache-long-line-scans to t in my init.el
makes Emacs freeze whenever I try to view a remote post in Gnus.

Here is the backtrace:

[backtrace.txt (text/plain, attachment)]

[Message part 3 (text/plain, inline)]

Do you want me to investigate?

        Christopher

Message #20 received at 12196 <at> debbugs.gnu.org (full text, mbox):

From: Michael Heerdegen <michael_heerdegen <at> web.de>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: Christopher Schmidt <christopher <at> ristopher.com>, 12196 <at> debbugs.gnu.org
Subject: Re: bug#12196: 24.1.50;
	setting cache-long-line-scans to non-nil freezes Emacs
Date: Sun, 26 Aug 2012 17:58:45 +0200

Eli Zaretskii <eliz <at> gnu.org> writes:

> Do you see a reference to bug#12196 in src/ChangeLog of that
> distribution?  If not, then my fix is not included.

Yes, I see it:

2012-08-15  Eli Zaretskii  <eliz <at> gnu.org>

	* region-cache.c (move_cache_gap): Update gap_len using the actual
	growth of the boundaries array.  Do not change cache_len.
	(Bug#12196)

> Does Emacs really freeze, or does it just do some prolonged operation?
> (And is your CPU really an i486?)  If you wait for a long time, does
> Emacs eventually recover and become responsive again?

No, it really freezes.  I can wait ten minutes and emacs doesn't become
responsive again.

uname says that my CPU is an i686.  To be honest, I don't know much
about hardware.  But I used the emacs-snapshot binaries nearly everyday
for many months without seeing any freezes besides these.

> If Emacs really freezes, attach a debugger to it when it does, type
> "bt" at the debugger's prompt, and post here everything the debugger
> displays in response.

Here is a backtrace:

#0  0x08167976 in buf_charpos_to_bytepos (b=0x8e72420, charpos=charpos <at> entry=32027) at marker.c:168
#1  0x08185005 in scan_buffer (target=target <at> entry=10, start=32027, start <at> entry=27007, end=32089, 
    end <at> entry=0, count=count <at> entry=1, shortage=shortage <at> entry=0xbf9e418c, 
    allow_quit=allow_quit <at> entry=1) at search.c:677
#2  0x08185777 in find_before_next_newline (from=27007, to=to <at> entry=0, cnt=1) at search.c:945
#3  0x081a9b73 in Fline_end_position (n=<optimized out>) at editfns.c:808
#4  0x081afc83 in Ffuncall (nargs=1, args=0xbf9e4274) at eval.c:2837
#5  0x081e4c0b in exec_byte_code (bytestr=149365792, vector=202, maxdepth=149365792, 
    args_template=138855706, nargs=0, args=0x0) at bytecode.c:898
#6  0x081af7e7 in funcall_lambda (fun=137048477, nargs=nargs <at> entry=4, 
    arg_vector=arg_vector <at> entry=0xbf9e4438) at eval.c:3069
#7  0x081afaca in Ffuncall (nargs=5, args=0xbf9e4434) at eval.c:2898
#8  0x081e4c0b in exec_byte_code (bytestr=149365792, vector=-1080146912, maxdepth=149365792, 
    args_template=5128, nargs=5, args=0xbf9e45d0) at bytecode.c:898
#9  0x081af6d3 in funcall_lambda (fun=140693133, nargs=nargs <at> entry=5, 
    arg_vector=arg_vector <at> entry=0xbf9e45d0) at eval.c:3003
#10 0x081afaca in Ffuncall (nargs=6, args=0xbf9e45cc) at eval.c:2898
#11 0x081e4c0b in exec_byte_code (bytestr=149365792, vector=0, maxdepth=149365792, args_template=0, 
    nargs=0, args=0xbf9e475c) at bytecode.c:898
#12 0x081af6d3 in funcall_lambda (fun=141473149, nargs=nargs <at> entry=0, 
    arg_vector=arg_vector <at> entry=0xbf9e475c) at eval.c:3003
#13 0x081afaca in Ffuncall (nargs=1, args=0xbf9e4758) at eval.c:2898
#14 0x081e4c0b in exec_byte_code (bytestr=149365792, vector=-1080146088, maxdepth=149365792, 
    args_template=0, nargs=0, args=0xbf9e48f8) at bytecode.c:898
#15 0x081af6d3 in funcall_lambda (fun=148465485, nargs=nargs <at> entry=0, 
    arg_vector=arg_vector <at> entry=0xbf9e48f8) at eval.c:3003
#16 0x081afaca in Ffuncall (nargs=1, args=0xbf9e48f4) at eval.c:2898
#17 0x081e4c0b in exec_byte_code (bytestr=149365792, vector=-1080145676, maxdepth=149365792, 
    args_template=3076, nargs=2, args=0xbf9e4a98) at bytecode.c:898
#18 0x081af6d3 in funcall_lambda (fun=140201581, nargs=nargs <at> entry=2, 
    arg_vector=arg_vector <at> entry=0xbf9e4a98) at eval.c:3003
#19 0x081afaca in Ffuncall (nargs=3, args=0xbf9e4a94) at eval.c:2898
#20 0x081e4c0b in exec_byte_code (bytestr=149365792, vector=-1080145276, maxdepth=149365792, 
    args_template=2052, nargs=2, args=0xbf9e4c24) at bytecode.c:898
#21 0x081af6d3 in funcall_lambda (fun=141836477, nargs=nargs <at> entry=2, 
    arg_vector=arg_vector <at> entry=0xbf9e4c24) at eval.c:3003
#22 0x081afaca in Ffuncall (nargs=3, args=0xbf9e4c20) at eval.c:2898
#23 0x081e4c0b in exec_byte_code (bytestr=149365792, vector=0, maxdepth=149365792, args_template=2052, 
    nargs=2, args=0xbf9e4d94) at bytecode.c:898
#24 0x081af6d3 in funcall_lambda (fun=141773429, nargs=nargs <at> entry=2, 
    arg_vector=arg_vector <at> entry=0xbf9e4d94) at eval.c:3003
#25 0x081afaca in Ffuncall (nargs=nargs <at> entry=3, args=args <at> entry=0xbf9e4d90) at eval.c:2898
#26 0x081b0b33 in Fapply (nargs=nargs <at> entry=2, args=args <at> entry=0xbf9e4e08) at eval.c:2343
#27 0x081b007f in apply1 (fn=fn <at> entry=140543522, arg=arg <at> entry=140712190) at eval.c:2581
#28 0x081abecd in Fcall_interactively (function=140543522, record_flag=138855706, keys=138864797)
    at callint.c:378
#29 0x081afc62 in Ffuncall (nargs=nargs <at> entry=4, args=args <at> entry=0xbf9e4f30) at eval.c:2844
#30 0x081aff27 in call3 (fn=138934218, arg1=140543522, arg2=138855706, arg3=138855706) at eval.c:2638
#31 0x0813e6f5 in Fcommand_execute (cmd=138934218, record_flag=140543522, keys=138855706, 
    special=138855706) at keyboard.c:10375
#32 0x0814ac63 in command_loop_1 () at keyboard.c:1639
#33 0x081ae230 in internal_condition_case (bfun=bfun <at> entry=0x814a930 <command_loop_1>, 
    handlers=138889274, hfun=hfun <at> entry=0x8140970 <cmd_error>) at eval.c:1322
#34 0x0813f745 in command_loop_2 (ignore=ignore <at> entry=138855706) at keyboard.c:1204
#35 0x081ae15b in internal_catch (tag=138887250, func=func <at> entry=0x813f720 <command_loop_2>, 
    arg=138855706) at eval.c:1079
#36 0x081404aa in command_loop () at keyboard.c:1183
#37 recursive_edit_1 () at keyboard.c:804
#38 0x0814079a in Frecursive_edit () at keyboard.c:868
#39 0x0805acb0 in main (argc=<optimized out>, argv=0xbf9e5644) at emacs.c:1662

> Then try to follow the advice in etc/DEBUG,
> under "If the symptom of the bug is that Emacs fails to respond", to
> establish which Emacs function, if any, is looping.

Since Christopher can also reproduce this problem, and since he surely
is a greater help here, I would prefer if you could work with him.


Thanks,

Michael.

Message #23 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Christopher Schmidt <christopher <at> ch.ristopher.com>
Cc: bug-gnu-emacs <at> gnu.org
Subject: Re: bug#12196: 24.1.50;
	setting cache-long-line-scans to non-nil freezes Emacs
Date: Fri, 31 Aug 2012 11:50:22 +0300

> From: Christopher Schmidt <christopher <at> ch.ristopher.com>
> Date: Sun, 26 Aug 2012 12:53:49 +0100 (BST)
> 
> Setting cache-long-line-scans to t in various buffer that are meant to
> be displayed in a window, such as *Info*, *Help* etc., works just fine.
> Setting the default value of cache-long-line-scans to t in my init.el
> makes Emacs freeze whenever I try to view a remote post in Gnus.

Does it only freeze in Gnus for you, then?

> Do you want me to investigate?

Yes, please.  Please follow the advice in etc/DEBUG to find out where
and why is Emacs looping.

Thanks.

Message #26 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Christopher Schmidt <christopher <at> ch.ristopher.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: bug-gnu-emacs <at> gnu.org
Subject: Re: bug#12196: 24.1.50;
	setting cache-long-line-scans to non-nil freezes Emacs
Date: Mon, 10 Sep 2012 11:28:35 +0100 (BST)

Eli Zaretskii <eliz <at> gnu.org> writes:
>> From: Christopher Schmidt <christopher <at> ch.ristopher.com>
>> Date: Sun, 26 Aug 2012 12:53:49 +0100 (BST)
>>
>> Setting cache-long-line-scans to t in various buffer that are meant
>> to be displayed in a window, such as *Info*, *Help* etc., works just
>> fine.  Setting the default value of cache-long-line-scans to t in my
>> init.el makes Emacs freeze whenever I try to view a remote post in
>> Gnus.
>
> Does it only freeze in Gnus for you, then?

Yes.  It depends on the post I am trying to look at - although I can
usually reproduce the issue after trying about four of five posts.

>> Do you want me to investigate?
>
> Yes, please.  Please follow the advice in etc/DEBUG to find out where
> and why is Emacs looping.

GNU Emacs 24.2.50.6 (x86_64-unknown-linux-gnu, GTK+ Version 2.24.10) of
2012-09-10; emacs-bzr-version is "109965
cyd <at> gnu.org-20120910032510-vrblnwlfnsb0cx3s".

Emacs loops here:

    #0  scan_buffer (target=10, start=6730, end=6749, count=1, shortage=0x7fff171cbbf0, allow_quit=1) at search.c:742
    #1  0x000000000059844f in find_before_next_newline (from=6730, to=0, cnt=1) at search.c:945
    #2  0x00000000005c8c1f in Fline_end_position (n=4) at editfns.c:808
    #3  0x000000000058cdcb in Fend_of_line (n=4) at cmds.c:201

    p start_byte
    $11 = 6750
    p cursor
    $12 = (unsigned char *) 0x3ddc6ad ");\n\n\treturn 0;\n}\n\n\n"
    p base
    $13 = (unsigned char *) 0x3ddc6ad ");\n\n\treturn 0;\n}\n\n\n"

These values do not change.

At the beginning of loop (search.c:669):

    p start
    $14 = 6730
    p end
    $15 = 6749

target is '\n' of course.  Ultimately the problem boils down to
region_cache_forward (search.c:686) always returning 0 from the first
invocation, thus start_byte (search.c:688) is not modified throughout
the loop.

    #0  region_cache_forward (buf=0x4f1db30, c=0x4bae990, pos=6750, next=0x7fff171cbb38) at region-cache.c:706
    #1  0x0000000000597995 in scan_buffer (target=10, start=6730, end=6749, count=1, shortage=0x7fff171cbbf0, allow_quit=1) at search.c:687

    p buf->text->z
    $21 = 6749

I realise I am not much of a help here.  Unfortunately I do not have
time ATM to dig into the C source and understand how the newline cache
works.

        Christopher

Message #29 received at 12196 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Christopher Schmidt <christopher <at> ch.ristopher.com>
Cc: 12196 <at> debbugs.gnu.org
Subject: Re: bug#12196: 24.1.50;
	setting cache-long-line-scans to non-nil freezes Emacs
Date: Mon, 10 Sep 2012 14:10:25 +0300

> From: Christopher Schmidt <christopher <at> ch.ristopher.com>
> Cc: bug-gnu-emacs <at> gnu.org
> Date: Mon, 10 Sep 2012 11:28:35 +0100 (BST)
> 
> Emacs loops here:
> 
>     #0  scan_buffer (target=10, start=6730, end=6749, count=1, shortage=0x7fff171cbbf0, allow_quit=1) at search.c:742
>     #1  0x000000000059844f in find_before_next_newline (from=6730, to=0, cnt=1) at search.c:945
>     #2  0x00000000005c8c1f in Fline_end_position (n=4) at editfns.c:808
>     #3  0x000000000058cdcb in Fend_of_line (n=4) at cmds.c:201
> 
>     p start_byte
>     $11 = 6750
>     p cursor
>     $12 = (unsigned char *) 0x3ddc6ad ");\n\n\treturn 0;\n}\n\n\n"
>     p base
>     $13 = (unsigned char *) 0x3ddc6ad ");\n\n\treturn 0;\n}\n\n\n"
> 
> These values do not change.
> 
> At the beginning of loop (search.c:669):
> 
>     p start
>     $14 = 6730
>     p end
>     $15 = 6749
> 
> target is '\n' of course.  Ultimately the problem boils down to
> region_cache_forward (search.c:686) always returning 0 from the first
> invocation, thus start_byte (search.c:688) is not modified throughout
> the loop.
> 
>     #0  region_cache_forward (buf=0x4f1db30, c=0x4bae990, pos=6750, next=0x7fff171cbb38) at region-cache.c:706
>     #1  0x0000000000597995 in scan_buffer (target=10, start=6730, end=6749, count=1, shortage=0x7fff171cbbf0, allow_quit=1) at search.c:687
> 
>     p buf->text->z
>     $21 = 6749

Thanks.  Does the patch below help?

=== modified file 'src/search.c'
--- src/search.c	2012-09-04 17:34:54 +0000
+++ src/search.c	2012-09-10 11:07:13 +0000
@@ -681,10 +681,11 @@ scan_buffer (register int target, ptrdif
            to see where we can avoid some scanning.  */
         if (target == '\n' && newline_cache)
           {
-            ptrdiff_t next_change;
+            ptrdiff_t next_change = 0;
             immediate_quit = 0;
             while (region_cache_forward
-                   (current_buffer, newline_cache, start_byte, &next_change))
+                   (current_buffer, newline_cache, start_byte, &next_change)
+		   || next_change == Z)
               start_byte = next_change;
             immediate_quit = allow_quit;
 

Message #32 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Christopher Schmidt <christopher <at> ch.ristopher.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: bug-gnu-emacs <at> gnu.org
Subject: Re: bug#12196: 24.1.50;
	setting cache-long-line-scans to non-nil freezes Emacs
Date: Mon, 10 Sep 2012 14:19:00 +0100 (BST)

Eli Zaretskii <eliz <at> gnu.org> writes:
> Thanks.  Does the patch below help?
> === modified file 'src/search.c'
> --- src/search.c	2012-09-04 17:34:54 +0000
> +++ src/search.c	2012-09-10 11:07:13 +0000
> @@ -681,10 +681,11 @@ scan_buffer (register int target, ptrdif
>             to see where we can avoid some scanning.  */
>          if (target == '\n' && newline_cache)
>            {
> -            ptrdiff_t next_change;
> +            ptrdiff_t next_change = 0;
>              immediate_quit = 0;
>              while (region_cache_forward
> -                   (current_buffer, newline_cache, start_byte, &next_change))
> +                   (current_buffer, newline_cache, start_byte, &next_change)
> +                || next_change == Z)
>                start_byte = next_change;
>              immediate_quit = allow_quit;

Unfortunately it does not.  Emacs now loops indefinitely right during
startup.  In this case, next_change is always equal to Z and the while
loop is never exited.

        Christopher

Message #35 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Christopher Schmidt <christopher <at> ch.ristopher.com>
Cc: bug-gnu-emacs <at> gnu.org
Subject: Re: bug#12196: 24.1.50;
	setting cache-long-line-scans to non-nil freezes Emacs
Date: Mon, 10 Sep 2012 20:10:33 +0300

> From: Christopher Schmidt <christopher <at> ch.ristopher.com>
> Cc: bug-gnu-emacs <at> gnu.org
> Date: Mon, 10 Sep 2012 14:19:00 +0100 (BST)
> 
> Eli Zaretskii <eliz <at> gnu.org> writes:
> > Thanks.  Does the patch below help?
> > === modified file 'src/search.c'
> > --- src/search.c	2012-09-04 17:34:54 +0000
> > +++ src/search.c	2012-09-10 11:07:13 +0000
> > @@ -681,10 +681,11 @@ scan_buffer (register int target, ptrdif
> >             to see where we can avoid some scanning.  */
> >          if (target == '\n' && newline_cache)
> >            {
> > -            ptrdiff_t next_change;
> > +            ptrdiff_t next_change = 0;
> >              immediate_quit = 0;
> >              while (region_cache_forward
> > -                   (current_buffer, newline_cache, start_byte, &next_change))
> > +                   (current_buffer, newline_cache, start_byte, &next_change)
> > +                || next_change == Z)
> >                start_byte = next_change;
> >              immediate_quit = allow_quit;
> 
> Unfortunately it does not.

How about the one below?

Once again, a reproducible recipe with buffer text that causes the
infloop would help immensely, TIA.

=== modified file 'src/search.c'
--- src/search.c	2012-09-04 17:34:54 +0000
+++ src/search.c	2012-09-10 17:06:46 +0000
@@ -666,7 +666,7 @@ scan_buffer (register int target, ptrdif
   immediate_quit = allow_quit;
 
   if (count > 0)
-    while (start != end)
+    while (start < end)
       {
         /* Our innermost scanning loop is very simple; it doesn't know
            about gaps, buffer ends, or the newline cache.  ceiling is

Message #38 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Christopher Schmidt <christopher <at> ch.ristopher.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: bug-gnu-emacs <at> gnu.org
Subject: Re: bug#12196: 24.1.50;
	setting cache-long-line-scans to non-nil freezes Emacs
Date: Mon, 10 Sep 2012 18:31:00 +0100 (BST)

Eli Zaretskii <eliz <at> gnu.org> writes:
> How about the one below?

Still hangs right during startup with my init.el setting the default of
cache-long-line-scans to t.

> Once again, a reproducible recipe with buffer text that causes the
> infloop would help immensely, TIA.

With your new patch,

    emacs -q
    M-: (setq-default cache-long-line-scans t) RET
    C-h i

loops indefinitely.  GNU Emacs 24.2.50.10 (x86_64-unknown-linux-gnu,
GTK+ Version 2.24.10) of 2012-09-10, rev. 109966 + both patches applied.

I can try to come up with a recipe for a vanilla trunk build and Gnus
this weekend.

Thanks so much for your help.

        Christopher

Message #41 received at 12196 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Christopher Schmidt <christopher <at> ch.ristopher.com>
Cc: 12196 <at> debbugs.gnu.org
Subject: Re: bug#12196: 24.1.50;
	setting cache-long-line-scans to non-nil freezes Emacs
Date: Mon, 10 Sep 2012 21:43:49 +0300

> From: Christopher Schmidt <christopher <at> ch.ristopher.com>
> Cc: bug-gnu-emacs <at> gnu.org
> Date: Mon, 10 Sep 2012 18:31:00 +0100 (BST)
> 
> Eli Zaretskii <eliz <at> gnu.org> writes:
> > How about the one below?
> 
> Still hangs right during startup with my init.el setting the default of
> cache-long-line-scans to t.

Hangs at the end of the buffer, as in the data you showed me?  That
should not happen anymore, because whenever 'start' becomes more than
'end', Emacs should break from the loop.  What am I missing?

> > Once again, a reproducible recipe with buffer text that causes the
> > infloop would help immensely, TIA.
> 
> With your new patch,
> 
>     emacs -q
>     M-: (setq-default cache-long-line-scans t) RET
>     C-h i
> 
> loops indefinitely.

Not here, sigh...

> I can try to come up with a recipe for a vanilla trunk build and Gnus
> this weekend.

A recipe without Gnus would be preferred.  If you can post a buffer of
text which consistently causes the hang, I could use that here.

By the way, what command causes the hang?

Also, next time you look at the loop in a debugger, step into
region_cache_forward, and type this command at GDB prompt:

 (gdb) call pp_cache (c)

Then post here the results.

Message #44 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Christopher Schmidt <christopher <at> ch.ristopher.com>
To: bug-gnu-emacs <at> gnu.org
Cc: Eli Zaretskii <eliz <at> gnu.org>
Subject: Re: bug#12196: 24.1.50;
	setting cache-long-line-scans to non-nil freezes Emacs
Date: Mon, 17 Sep 2012 18:17:48 +0100 (BST)

Eli Zaretskii <eliz <at> gnu.org> writes:

>> I can try to come up with a recipe for a vanilla trunk build and Gnus
>> this weekend.
>
> A recipe without Gnus would be preferred.  If you can post a buffer of
> text which consistently causes the hang, I could use that here.

    emacs -q
    M-: (setq-default cache-long-line-scans t) RET
    M-: (setq gnus-select-method
            '(nntp "news.gmane.org"
                   (nntp-open-connection-function nntp-open-tls-stream)
                   (nntp-port-number "nntps"))) RET
    M-x gnus RET
    ^
    # Move point to "{nntp:news.gmane.org} (opened)"
    RET
    # Move point to "K  XXXXX: gmane.emacs.bugs"
    RET RET

I tried other, non-Gnus stuff, but it seems I can only get Emacs to hang
with Gnus.

In GNU Emacs 24.2.50.1 (x86_64-unknown-linux-gnu, GTK+ Version 2.24.10) of 2012-09-17
Bzr revision: 110075 cyd <at> gnu.org-20120917144551-qc9jxddwdgoizrud
Windowing system distributor `The X.Org Foundation', version 11.0.11203000
Configured using:
 `configure '--prefix=/usr/local/pkg/emacs-trunk' '--with-jpeg=no''

Important settings:
  value of $LANG: en_GB.UTF-8
  locale-coding-system: utf-8-unix
  default enable-multibyte-characters: t

Major mode: Fundamental

Minor modes in effect:
  tooltip-mode: t
  mouse-wheel-mode: t
  tool-bar-mode: t
  menu-bar-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  blink-cursor-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t
  buffer-read-only: t
  line-number-mode: t
  transient-mark-mode: t

Recent input:
M-x r e p o r t - e m a c s - b u g <return>

Recent messages:
For information about GNU Emacs and the GNU system, type C-h C-a.

Load-path shadows:
None found.

Features:
(shadow sort gnus-util mail-extr emacsbug message format-spec rfc822 mml
easymenu mml-sec mm-decode mm-bodies mm-encode mail-parse rfc2231
mailabbrev gmm-utils mailheader sendmail rfc2047 rfc2045 ietf-drums
mm-util mail-prsvr mail-utils time-date tooltip ediff-hook vc-hooks
lisp-float-type mwheel x-win x-dnd tool-bar dnd fontset image regexp-opt
fringe tabulated-list newcomment lisp-mode register page menu-bar
rfn-eshadow timer select scroll-bar mouse jit-lock font-lock syntax
facemenu font-core frame cham georgian utf-8-lang misc-lang vietnamese
tibetan thai tai-viet lao korean japanese hebrew greek romanian slovak
czech european ethiopic indian cyrillic chinese case-table epa-hook
jka-cmpr-hook help simple abbrev minibuffer loaddefs button faces
cus-face macroexp files text-properties overlay sha1 md5 base64 format
env code-pages mule custom widget hashtable-print-readable backquote
make-network-process dbusbind dynamic-setting system-font-setting
font-render-setting move-toolbar gtk x-toolkit x multi-tty emacs)

        Christopher

Message #47 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Christopher Schmidt <christopher <at> ch.ristopher.com>
Cc: bug-gnu-emacs <at> gnu.org
Subject: Re: bug#12196: 24.1.50;
	setting cache-long-line-scans to non-nil freezes Emacs
Date: Mon, 17 Sep 2012 21:38:35 +0300

> From: Christopher Schmidt <christopher <at> ch.ristopher.com>
> Cc: Eli Zaretskii <eliz <at> gnu.org>
> Date: Mon, 17 Sep 2012 18:17:48 +0100 (BST)
> 
>     emacs -q
>     M-: (setq-default cache-long-line-scans t) RET
>     M-: (setq gnus-select-method
>             '(nntp "news.gmane.org"
>                    (nntp-open-connection-function nntp-open-tls-stream)
>                    (nntp-port-number "nntps"))) RET
>     M-x gnus RET
>     ^
>     # Move point to "{nntp:news.gmane.org} (opened)"
>     RET
>     # Move point to "K  XXXXX: gmane.emacs.bugs"
>     RET RET

OK, I succeeded in reproducing this on one of the systems where I can
debug it, thanks.

But you also said you could reproduce this with "C-h i", didn't you?

Message #50 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Christopher Schmidt <christopher <at> ch.ristopher.com>
To: bug-gnu-emacs <at> gnu.org
Subject: Re: bug#12196: 24.1.50;
	setting cache-long-line-scans to non-nil freezes Emacs
Date: Mon, 17 Sep 2012 19:53:13 +0100 (BST)

Eli Zaretskii <eliz <at> gnu.org> writes:
> OK, I succeeded in reproducing this on one of the systems where I can
> debug it, thanks.
>
> But you also said you could reproduce this with "C-h i", didn't you?

Only with both of your patches (attached to <83d31tls6u.fsf <at> gnu.org> and
<83ligikuam.fsf <at> gnu.org>) applied.

        Christopher

Message #53 received at 12196 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: christopher <at> ch.ristopher.com
Cc: 12196 <at> debbugs.gnu.org
Subject: Re: bug#12196: 24.1.50;
	setting cache-long-line-scans to non-nil freezes Emacs
Date: Mon, 17 Sep 2012 23:18:16 +0300

> Date: Mon, 17 Sep 2012 21:38:35 +0300
> From: Eli Zaretskii <eliz <at> gnu.org>
> Cc: 12196 <at> debbugs.gnu.org
> 
> > From: Christopher Schmidt <christopher <at> ch.ristopher.com>
> > Cc: Eli Zaretskii <eliz <at> gnu.org>
> > Date: Mon, 17 Sep 2012 18:17:48 +0100 (BST)
> > 
> >     emacs -q
> >     M-: (setq-default cache-long-line-scans t) RET
> >     M-: (setq gnus-select-method
> >             '(nntp "news.gmane.org"
> >                    (nntp-open-connection-function nntp-open-tls-stream)
> >                    (nntp-port-number "nntps"))) RET
> >     M-x gnus RET
> >     ^
> >     # Move point to "{nntp:news.gmane.org} (opened)"
> >     RET
> >     # Move point to "K  XXXXX: gmane.emacs.bugs"
> >     RET RET
> 
> OK, I succeeded in reproducing this on one of the systems where I can
> debug it, thanks.

Should be fixed in trunk revision 110079, the patch is below for your
convenience.  Please test.

=== modified file 'src/ChangeLog'
--- src/ChangeLog	2012-09-17 07:56:20 +0000
+++ src/ChangeLog	2012-09-17 20:11:34 +0000
@@ -1,5 +1,9 @@
 2012-09-17  Eli Zaretskii  <eliz <at> gnu.org>
 
+	* search.c (scan_buffer): Use character positions in calls to
+	region_cache_forward and region_cache_backward, not byte
+	positions.  (Bug#12196)
+
 	* w32term.c (w32_read_socket): Set pending_signals to 1, like
 	xterm.c does.  Reported by Daniel Colascione <dancol <at> dancol.org>.
 

=== modified file 'src/search.c'
--- src/search.c	2012-09-15 07:06:56 +0000
+++ src/search.c	2012-09-17 20:11:34 +0000
@@ -674,7 +674,7 @@ scan_buffer (register int target, ptrdif
            obstacle --- the last character the dumb search loop should
            examine.  */
 	ptrdiff_t ceiling_byte = CHAR_TO_BYTE (end) - 1;
-	ptrdiff_t start_byte = CHAR_TO_BYTE (start);
+	ptrdiff_t start_byte;
 	ptrdiff_t tem;
 
         /* If we're looking for a newline, consult the newline cache
@@ -684,18 +684,22 @@ scan_buffer (register int target, ptrdif
             ptrdiff_t next_change;
             immediate_quit = 0;
             while (region_cache_forward
-                   (current_buffer, newline_cache, start_byte, &next_change))
-              start_byte = next_change;
+                   (current_buffer, newline_cache, start, &next_change))
+              start = next_change;
             immediate_quit = allow_quit;
 
+	    start_byte = CHAR_TO_BYTE (start);
+
             /* START should never be after END.  */
             if (start_byte > ceiling_byte)
               start_byte = ceiling_byte;
 
             /* Now the text after start is an unknown region, and
                next_change is the position of the next known region. */
-            ceiling_byte = min (next_change - 1, ceiling_byte);
+            ceiling_byte = min (CHAR_TO_BYTE (next_change) - 1, ceiling_byte);
           }
+	else
+	  start_byte = CHAR_TO_BYTE (start);
 
         /* The dumb loop can only scan text stored in contiguous
            bytes. BUFFER_CEILING_OF returns the last character
@@ -747,7 +751,7 @@ scan_buffer (register int target, ptrdif
       {
         /* The last character to check before the next obstacle.  */
 	ptrdiff_t ceiling_byte = CHAR_TO_BYTE (end);
-	ptrdiff_t start_byte = CHAR_TO_BYTE (start);
+	ptrdiff_t start_byte;
 	ptrdiff_t tem;
 
         /* Consult the newline cache, if appropriate.  */
@@ -756,18 +760,22 @@ scan_buffer (register int target, ptrdif
             ptrdiff_t next_change;
             immediate_quit = 0;
             while (region_cache_backward
-                   (current_buffer, newline_cache, start_byte, &next_change))
-              start_byte = next_change;
+                   (current_buffer, newline_cache, start, &next_change))
+              start = next_change;
             immediate_quit = allow_quit;
 
+	    start_byte = CHAR_TO_BYTE (start);
+
             /* Start should never be at or before end.  */
             if (start_byte <= ceiling_byte)
               start_byte = ceiling_byte + 1;
 
             /* Now the text before start is an unknown region, and
                next_change is the position of the next known region. */
-            ceiling_byte = max (next_change, ceiling_byte);
+            ceiling_byte = max (CHAR_TO_BYTE (next_change), ceiling_byte);
           }
+	else
+	  start_byte = CHAR_TO_BYTE (start);
 
         /* Stop scanning before the gap.  */
 	tem = BUFFER_FLOOR_OF (start_byte - 1);

Message #56 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Christopher Schmidt <christopher <at> ch.ristopher.com>
To: bug-gnu-emacs <at> gnu.org
Subject: Re: bug#12196: 24.1.50;
	setting cache-long-line-scans to non-nil freezes Emacs
Date: Tue, 18 Sep 2012 08:25:17 +0100 (BST)

Eli Zaretskii <eliz <at> gnu.org> writes:
> Should be fixed in trunk revision 110079, the patch is below for your
> convenience.  Please test.

Works great.  Thanks so much for you help!

        Christopher

Message #61 received at 12196-done <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Christopher Schmidt <christopher <at> ch.ristopher.com>
Cc: 12196-done <at> debbugs.gnu.org
Subject: Re: bug#12196: 24.1.50;
	setting cache-long-line-scans to non-nil freezes Emacs
Date: Tue, 18 Sep 2012 11:02:27 +0300

> From: Christopher Schmidt <christopher <at> ch.ristopher.com>
> Date: Tue, 18 Sep 2012 08:25:17 +0100 (BST)
> 
> Eli Zaretskii <eliz <at> gnu.org> writes:
> > Should be fixed in trunk revision 110079, the patch is below for your
> > convenience.  Please test.
> 
> Works great.  Thanks so much for you help!

Thanks for testing, closing the bug.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.