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

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

[Michael Heerdegen]

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''

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

[Eli Zaretskii]

> Date: Tue, 14 Aug 2012 06:54:28 +0200
> From: Michael Heerdegen <michael_heerdegen@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.

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

[Michael Heerdegen]

Eli Zaretskii <eliz@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.

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

[Eli Zaretskii]

> From: Michael Heerdegen <michael_heerdegen@web.de>
> Cc: 12196@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.

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

[Christopher Schmidt]

[-- Attachment #1: Type: text/plain, Size: 1617 bytes --]

Eli Zaretskii <eliz@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:

[-- Attachment #2: backtrace.txt --]
[-- Type: text/plain, Size: 19390 bytes --]

(gdb) backtrace
#0  find_cache_boundary (c=c@entry=0x418e6f0, pos=pos@entry=9711)
    at region-cache.c:185
#1  0x00000000005bcf9d in region_cache_forward (buf=0x3fee4c0, 
    c=c@entry=0x418e6f0, pos=pos@entry=9711, 
    next=next@entry=0x7fff92befe38) at region-cache.c:709
#2  0x0000000000546ce4 in scan_buffer (target=target@entry=10, 
    start=<optimized out>, start@entry=9648, end=9707, end@entry=0, 
    count=1, shortage=shortage@entry=0x7fff92befe88, 
    allow_quit=allow_quit@entry=1) at search.c:687
#3  0x0000000000547402 in find_before_next_newline (
    from=from@entry=9648, to=to@entry=0, cnt=<optimized out>)
    at search.c:945
#4  0x000000000056d78a in Fline_end_position (n=<optimized out>)
    at editfns.c:808
#5  0x0000000000539005 in Fend_of_line (n=<optimized out>)
    at cmds.c:201
#6  0x0000000000573057 in eval_sub (form=<optimized out>)
    at eval.c:2173
#7  0x00000000005733c5 in Fprogn (args=68740848, 
    args@entry=70064870) at eval.c:376
#8  0x0000000000575af8 in Fwhile (args=<optimized out>)
    at eval.c:955
#9  0x00000000005731d8 in eval_sub (form=70036598) at eval.c:2121
#10 0x00000000005733c5 in Fprogn (args=68740848) at eval.c:376
#11 0x0000000000576069 in Flet (args=70036678) at eval.c:933
#12 0x00000000005731d8 in eval_sub (form=70036758) at eval.c:2121
#13 0x00000000005733c5 in Fprogn (args=68740848) at eval.c:376
#14 0x0000000000573708 in funcall_lambda (fun=fun@entry=70127990, 
    nargs=nargs@entry=1, arg_vector=arg_vector@entry=0x7fff92bf02d0)
    at eval.c:3038
#15 0x0000000000572a2c in apply_lambda (fun=fun@entry=70127990, 
    args=<optimized out>) at eval.c:2922
#16 0x0000000000572dea in eval_sub (form=69980838) at eval.c:2249
#17 0x00000000005732c0 in Fsetq (args=<optimized out>) at eval.c:445
#18 0x00000000005731d8 in eval_sub (form=69980870) at eval.c:2121
#19 0x00000000005733c5 in Fprogn (args=68740848) at eval.c:376
#20 0x00000000005731d8 in eval_sub (form=form@entry=69310054)
    at eval.c:2121
#21 0x0000000000572f80 in eval_sub (form=<optimized out>)
    at eval.c:2245
#22 0x00000000005733c5 in Fprogn (args=68740848) at eval.c:376
#23 0x0000000000576069 in Flet (args=69980918) at eval.c:933
#24 0x00000000005731d8 in eval_sub (form=69710358) at eval.c:2121
#25 0x00000000005733c5 in Fprogn (args=68740848, 
    args@entry=69710374) at eval.c:376
#26 0x0000000000575af8 in Fwhile (args=<optimized out>)
    at eval.c:955
#27 0x00000000005731d8 in eval_sub (form=69710550) at eval.c:2121
#28 0x00000000005733c5 in Fprogn (args=68740848, 
    args@entry=69460182) at eval.c:376
#29 0x000000000056f1bd in Fsave_restriction (body=69460182)
    at editfns.c:3426
#30 0x00000000005731d8 in eval_sub (form=69710582) at eval.c:2121
#31 0x00000000005733c5 in Fprogn (args=68740848) at eval.c:376
#32 0x0000000000576069 in Flet (args=69710598) at eval.c:933
#33 0x00000000005731d8 in eval_sub (form=69681366) at eval.c:2121
#34 0x00000000005733c5 in Fprogn (args=68740848, 
    args@entry=74040470) at eval.c:376
#35 0x000000000056736d in Fsave_current_buffer (args=74040470)
    at editfns.c:954
#36 0x00000000005731d8 in eval_sub (form=form@entry=74040454)
    at eval.c:2121
#37 0x0000000000572f80 in eval_sub (form=<optimized out>)
    at eval.c:2245
#38 0x00000000005733c5 in Fprogn (args=68740848) at eval.c:376
#39 0x0000000000573708 in funcall_lambda (fun=fun@entry=70037046, 
    nargs=nargs@entry=2, arg_vector=arg_vector@entry=0x7fff92bf0f40)
    at eval.c:3038
#40 0x0000000000572a2c in apply_lambda (fun=fun@entry=70037046, 
    args=<optimized out>) at eval.c:2922
#41 0x0000000000572dea in eval_sub (form=69682070) at eval.c:2249
#42 0x00000000005733c5 in Fprogn (args=68740848) at eval.c:376
#43 0x0000000000573708 in funcall_lambda (fun=69681878, 
    nargs=nargs@entry=0, arg_vector=arg_vector@entry=0x7fff92bf11d8)
    at eval.c:3038
#44 0x00000000005739ab in Ffuncall (nargs=1, args=0x7fff92bf11d0)
    at eval.c:2874
#45 0x00000000005731a2 in eval_sub (form=<optimized out>)
    at eval.c:2145
#46 0x00000000005733c5 in Fprogn (args=68740848, 
    args@entry=63040262) at eval.c:376
#47 0x000000000056f1bd in Fsave_restriction (body=63040262)
    at editfns.c:3426
#48 0x00000000005731d8 in eval_sub (form=63040342) at eval.c:2121
#49 0x00000000005733c5 in Fprogn (args=68740848) at eval.c:376
#50 0x00000000005731d8 in eval_sub (form=74143078) at eval.c:2121
#51 0x00000000005731d8 in eval_sub (form=form@entry=74143030)
    at eval.c:2121
#52 0x0000000000572f80 in eval_sub (form=<optimized out>)
    at eval.c:2245
#53 0x00000000005733c5 in Fprogn (args=68740848, 
    args@entry=73849462) at eval.c:376
#54 0x0000000000575af8 in Fwhile (args=<optimized out>)
    at eval.c:955
#55 0x00000000005731d8 in eval_sub (form=73849430) at eval.c:2121
#56 0x00000000005733c5 in Fprogn (args=68740848) at eval.c:376
#57 0x0000000000576069 in Flet (args=73849398) at eval.c:933
#58 0x00000000005731d8 in eval_sub (form=form@entry=73849382)
    at eval.c:2121
#59 0x0000000000572f80 in eval_sub (form=<optimized out>)
    at eval.c:2245
#60 0x00000000005733c5 in Fprogn (args=68740848, 
    args@entry=73823350) at eval.c:376
#61 0x0000000000571e2b in internal_catch (tag=65271776, 
    func=0x5733a0 <Fprogn>, arg=73823350) at eval.c:1079
#62 0x00000000005731d8 in eval_sub (form=73823270) at eval.c:2121
#63 0x0000000000572ed4 in eval_sub (form=form@entry=73823238)
    at eval.c:2158
#64 0x0000000000572f80 in eval_sub (form=form@entry=73823398)
    at eval.c:2245
#65 0x0000000000572f80 in eval_sub (form=<optimized out>)
    at eval.c:2245
#66 0x00000000005733c5 in Fprogn (args=68740848) at eval.c:376
#67 0x0000000000576069 in Flet (args=63015958) at eval.c:933
#68 0x00000000005731d8 in eval_sub (form=63018070) at eval.c:2121
#69 0x00000000005733c5 in Fprogn (args=68740848) at eval.c:376
#70 0x0000000000573708 in funcall_lambda (fun=fun@entry=63040054, 
    nargs=nargs@entry=4, arg_vector=arg_vector@entry=0x7fff92bf21a0)
    at eval.c:3038
#71 0x0000000000572a2c in apply_lambda (fun=fun@entry=63040054, 
    args=<optimized out>) at eval.c:2922
#72 0x0000000000572dea in eval_sub (form=61562134) at eval.c:2249
#73 0x00000000005733c5 in Fprogn (args=68740848, 
    args@entry=61564742) at eval.c:376
#74 0x000000000056f1bd in Fsave_restriction (body=61564742)
    at editfns.c:3426
#75 0x00000000005731d8 in eval_sub (form=61564822) at eval.c:2121
#76 0x00000000005733c5 in Fprogn (args=68740848) at eval.c:376
#77 0x00000000005731d8 in eval_sub (form=61535622) at eval.c:2121
#78 0x00000000005733c5 in Fprogn (args=68740848) at eval.c:376
#79 0x0000000000576069 in Flet (args=61537910) at eval.c:933
#80 0x00000000005731d8 in eval_sub (form=61538182) at eval.c:2121
#81 0x00000000005733c5 in Fprogn (args=68740848) at eval.c:376
#82 0x00000000005731d8 in eval_sub (form=74158518) at eval.c:2121
#83 0x0000000000575df5 in Funwind_protect (args=74158502)
    at eval.c:1178
#84 0x00000000005731d8 in eval_sub (form=74158486) at eval.c:2121
#85 0x00000000005733c5 in Fprogn (args=68740848, 
    args@entry=74158470) at eval.c:376
#86 0x000000000056736d in Fsave_current_buffer (args=74158470)
    at editfns.c:954
#87 0x00000000005731d8 in eval_sub (form=74158454) at eval.c:2121
#88 0x00000000005733c5 in Fprogn (args=68740848) at eval.c:376
#89 0x0000000000576069 in Flet (args=74158422) at eval.c:933
#90 0x00000000005731d8 in eval_sub (form=form@entry=74158406)
    at eval.c:2121
#91 0x0000000000572f80 in eval_sub (form=<optimized out>)
    at eval.c:2245
#92 0x00000000005733c5 in Fprogn (args=68740848, 
    args@entry=61603558) at eval.c:376
#93 0x000000000056d9fd in Fsave_excursion (args=61603558)
    at editfns.c:939
#94 0x00000000005731d8 in eval_sub (form=61538726) at eval.c:2121
#95 0x00000000005733c5 in Fprogn (args=68740848) at eval.c:376
#96 0x0000000000573708 in funcall_lambda (fun=61601478, 
    nargs=nargs@entry=0, arg_vector=arg_vector@entry=0x7fff92bf2eb8)
    at eval.c:3038
#97 0x00000000005739ab in Ffuncall (nargs=1, args=0x7fff92bf2eb0)
    at eval.c:2874
#98 0x00000000005731a2 in eval_sub (form=<optimized out>)
    at eval.c:2145
#99 0x00000000005733c5 in Fprogn (args=68740848) at eval.c:376
#100 0x00000000005731d8 in eval_sub (form=74158710) at eval.c:2121
#101 0x00000000005731d8 in eval_sub (form=form@entry=74158662)
    at eval.c:2121
#102 0x0000000000572f80 in eval_sub (form=<optimized out>)
    at eval.c:2245
#103 0x00000000005733c5 in Fprogn (args=68740848) at eval.c:376
#104 0x0000000000576069 in Flet (args=61041766) at eval.c:933
#105 0x00000000005731d8 in eval_sub (form=61041910) at eval.c:2121
#106 0x00000000005733c5 in Fprogn (args=68740848) at eval.c:376
#107 0x0000000000573708 in funcall_lambda (fun=fun@entry=61040678, 
    nargs=nargs@entry=0, arg_vector=arg_vector@entry=0x7fff92bf34a0)
    at eval.c:3038
#108 0x0000000000572a2c in apply_lambda (fun=fun@entry=61040678, 
    args=<optimized out>) at eval.c:2922
#109 0x0000000000572dea in eval_sub (form=61043750) at eval.c:2249
#110 0x00000000005733c5 in Fprogn (args=68740848) at eval.c:376
#111 0x00000000005731d8 in eval_sub (form=74118502) at eval.c:2121
#112 0x00000000005731d8 in eval_sub (form=form@entry=74118454)
    at eval.c:2121
#113 0x0000000000572f80 in eval_sub (form=<optimized out>)
    at eval.c:2245
#114 0x00000000005733c5 in Fprogn (args=68740848) at eval.c:376
#115 0x00000000005731d8 in eval_sub (form=61123718) at eval.c:2121
#116 0x00000000005733c5 in Fprogn (args=68740848) at eval.c:376
#117 0x00000000005731d8 in eval_sub (form=61125494) at eval.c:2121
#118 0x00000000005733c5 in Fprogn (args=68740848, 
    args@entry=61125990) at eval.c:376
#119 0x000000000056d9fd in Fsave_excursion (args=61125990)
    at editfns.c:939
#120 0x00000000005731d8 in eval_sub (form=61126022) at eval.c:2121
#121 0x00000000005733c5 in Fprogn (args=68740848) at eval.c:376
#122 0x0000000000576282 in FletX (args=61126038) at eval.c:863
#123 0x00000000005731d8 in eval_sub (form=61126678) at eval.c:2121
#124 0x00000000005733c5 in Fprogn (args=68740848, 
    args@entry=61126774) at eval.c:376
#125 0x000000000056d9fd in Fsave_excursion (args=61126774)
    at editfns.c:939
#126 0x00000000005731d8 in eval_sub (form=61127078) at eval.c:2121
#127 0x00000000005733c5 in Fprogn (args=68740848) at eval.c:376
#128 0x0000000000573708 in funcall_lambda (fun=fun@entry=61042134, 
    nargs=nargs@entry=2, arg_vector=arg_vector@entry=0x7fff92bf3ef0)
    at eval.c:3038
#129 0x0000000000572a2c in apply_lambda (fun=fun@entry=61042134, 
    args=<optimized out>) at eval.c:2922
#130 0x0000000000572dea in eval_sub (form=47227846) at eval.c:2249
#131 0x00000000005733c5 in Fprogn (args=68740848) at eval.c:376
#132 0x00000000005731d8 in eval_sub (form=47200358) at eval.c:2121
#133 0x0000000000573343 in Fprog1 (args=47227782) at eval.c:399
#134 0x00000000005731d8 in eval_sub (form=47200374) at eval.c:2121
#135 0x00000000005733c5 in Fprogn (args=68740848) at eval.c:376
#136 0x00000000005731d8 in eval_sub (form=47200662) at eval.c:2121
#137 0x00000000005733c5 in Fprogn (args=68740848) at eval.c:376
#138 0x0000000000573708 in funcall_lambda (fun=fun@entry=47226182, 
    nargs=nargs@entry=2, arg_vector=arg_vector@entry=0x7fff92bf43f0)
    at eval.c:3038
#139 0x0000000000572a2c in apply_lambda (fun=fun@entry=47226182, 
    args=<optimized out>) at eval.c:2922
#140 0x0000000000572dea in eval_sub (form=48447638) at eval.c:2249
#141 0x00000000005731d8 in eval_sub (form=48449990) at eval.c:2121
#142 0x00000000005733c5 in Fprogn (args=68740848) at eval.c:376
#143 0x00000000005731d8 in eval_sub (form=48452166) at eval.c:2121
#144 0x0000000000573343 in Fprog1 (args=48467126) at eval.c:399
#145 0x00000000005731d8 in eval_sub (form=48452214) at eval.c:2121
#146 0x00000000005733c5 in Fprogn (args=68740848) at eval.c:376
#147 0x0000000000573708 in funcall_lambda (fun=fun@entry=48485302, 
    nargs=nargs@entry=1, arg_vector=arg_vector@entry=0x7fff92bf48e0)
    at eval.c:3038
#148 0x0000000000572a2c in apply_lambda (fun=fun@entry=48485302, 
    args=<optimized out>) at eval.c:2922
#149 0x0000000000572dea in eval_sub (form=52155574) at eval.c:2249
#150 0x00000000005733c5 in Fprogn (args=68740848) at eval.c:376
#151 0x00000000005731d8 in eval_sub (form=form@entry=69231750)
    at eval.c:2121
#152 0x0000000000572f80 in eval_sub (form=<optimized out>)
    at eval.c:2245
#153 0x00000000005733c5 in Fprogn (args=68740848) at eval.c:376
#154 0x0000000000576069 in Flet (args=52155846) at eval.c:933
#155 0x00000000005731d8 in eval_sub (form=52155926) at eval.c:2121
#156 0x00000000005733c5 in Fprogn (args=68740848) at eval.c:376
#157 0x00000000005731d8 in eval_sub (form=52155942) at eval.c:2121
#158 0x00000000005731d8 in eval_sub (form=52156118) at eval.c:2121
#159 0x00000000005733c5 in Fprogn (args=68740848) at eval.c:376
#160 0x00000000005731d8 in eval_sub (form=52156838) at eval.c:2121
#161 0x00000000005733c5 in Fprogn (args=68740848) at eval.c:376
#162 0x00000000005731d8 in eval_sub (form=52164518) at eval.c:2121
#163 0x00000000005733c5 in Fprogn (args=68740848) at eval.c:376
#164 0x0000000000576282 in FletX (args=52164534) at eval.c:863
#165 0x00000000005731d8 in eval_sub (form=52135222) at eval.c:2121
#166 0x00000000005733c5 in Fprogn (args=68740848) at eval.c:376
#167 0x0000000000573708 in funcall_lambda (fun=fun@entry=52152886, 
    nargs=nargs@entry=6, arg_vector=arg_vector@entry=0x7fff92bf5380)
    at eval.c:3038
#168 0x0000000000572a2c in apply_lambda (fun=fun@entry=52152886, 
    args=<optimized out>) at eval.c:2922
#169 0x0000000000572dea in eval_sub (form=52138534) at eval.c:2249
#170 0x0000000000575ac4 in For (args=68740848) at eval.c:276
#171 0x00000000005731d8 in eval_sub (form=52138550) at eval.c:2121
#172 0x00000000005733c5 in Fprogn (args=68740848) at eval.c:376
#173 0x0000000000576069 in Flet (args=52138566) at eval.c:933
#174 0x00000000005731d8 in eval_sub (form=52138630) at eval.c:2121
#175 0x00000000005732c0 in Fsetq (args=<optimized out>)
    at eval.c:445
#176 0x00000000005731d8 in eval_sub (form=52138662) at eval.c:2121
#177 0x0000000000572ed4 in eval_sub (form=<optimized out>)
    at eval.c:2158
#178 0x0000000000575a84 in Fand (args=68740848) at eval.c:300
#179 0x00000000005731d8 in eval_sub (form=form@entry=52138710)
    at eval.c:2121
#180 0x0000000000575b00 in Fwhile (args=<optimized out>)
    at eval.c:952
#181 0x00000000005731d8 in eval_sub (form=52138726) at eval.c:2121
#182 0x00000000005733c5 in Fprogn (args=68740848) at eval.c:376
#183 0x0000000000576069 in Flet (args=52138742) at eval.c:933
#184 0x00000000005731d8 in eval_sub (form=52138774) at eval.c:2121
#185 0x00000000005733c5 in Fprogn (args=68740848) at eval.c:376
#186 0x0000000000573708 in funcall_lambda (fun=fun@entry=52136086, 
    nargs=nargs@entry=7, arg_vector=arg_vector@entry=0x7fff92bf5da0)
    at eval.c:3038
#187 0x0000000000572a2c in apply_lambda (fun=fun@entry=52136086, 
    args=<optimized out>) at eval.c:2922
#188 0x0000000000572dea in eval_sub (form=51237414) at eval.c:2249
#189 0x00000000005733c5 in Fprogn (args=68740848) at eval.c:376
#190 0x0000000000576069 in Flet (args=51238406) at eval.c:933
#191 0x00000000005731d8 in eval_sub (form=51238118) at eval.c:2121
#192 0x00000000005733c5 in Fprogn (args=68740848) at eval.c:376
#193 0x0000000000573708 in funcall_lambda (fun=fun@entry=51236246, 
    nargs=nargs@entry=3, arg_vector=arg_vector@entry=0x7fff92bf6160)
    at eval.c:3038
#194 0x0000000000572a2c in apply_lambda (fun=fun@entry=51236246, 
    args=<optimized out>) at eval.c:2922
#195 0x0000000000572dea in eval_sub (form=49455654) at eval.c:2249
#196 0x00000000005733c5 in Fprogn (args=68740848) at eval.c:376
#197 0x00000000005731d8 in eval_sub (form=49460166) at eval.c:2121
#198 0x00000000005733c5 in Fprogn (args=68740848) at eval.c:376
#199 0x0000000000573708 in funcall_lambda (fun=49532326, 
    nargs=nargs@entry=1, arg_vector=arg_vector@entry=0x7fff92bf6548)
    at eval.c:3038
#200 0x00000000005739ab in Ffuncall (nargs=nargs@entry=2, 
    args=args@entry=0x7fff92bf6540) at eval.c:2874
#201 0x00000000005700f5 in Fcall_interactively (function=50510242, 
    record_flag=11981378, keys=12016597) at callint.c:853
#202 0x0000000000573b1f in Ffuncall (nargs=nargs@entry=4, 
    args=args@entry=0x7fff92bf66e0) at eval.c:2820
#203 0x0000000000573d54 in call3 (fn=<optimized out>, 
    arg1=<optimized out>, arg2=<optimized out>, 
    arg3=<optimized out>) at eval.c:2638
#204 0x00000000004fe13d in Fcommand_execute (cmd=<optimized out>, 
    record_flag=<optimized out>, keys=<optimized out>, 
    special=<optimized out>) at keyboard.c:10375
#205 0x000000000050bd6c in command_loop_1 () at keyboard.c:1639
#206 0x0000000000571f33 in internal_condition_case (
    bfun=bfun@entry=0x50b9d0 <command_loop_1>, handlers=12033154, 
    hfun=hfun@entry=0x500610 <cmd_error>) at eval.c:1322
#207 0x00000000004fec4e in command_loop_2 (
    ignore=ignore@entry=11981378) at keyboard.c:1204
#208 0x0000000000571e2b in internal_catch (tag=65271776, 
    func=func@entry=0x4fec30 <command_loop_2>, arg=11981378)
    at eval.c:1079
#209 0x00000000005000e7 in command_loop () at keyboard.c:1183
#210 recursive_edit_1 () at keyboard.c:804
#211 0x0000000000500415 in Frecursive_edit () at keyboard.c:868
#212 0x000000000041525d in main (argc=2, argv=<optimized out>)
    at emacs.c:1654

Lisp Backtrace:
"end-of-line" (0x92beff30)
"while" (0x92bf0018)
"let" (0x92bf0198)
"gnus-article-foldable-buffer" (0x92bf02d0)
"setq" (0x92bf0498)
"if" (0x92bf0598)
"unless" (0x92bf0688)
"let" (0x92bf0818)
"while" (0x92bf0938)
"save-restriction" (0x92bf0a58)
"let" (0x92bf0bf8)
"save-current-buffer" (0x92bf0d18)
"with-current-buffer" (0x92bf0e08)
"gnus-article-fill-cited-article" (0x92bf0f40)
"gnus-article-fill-cited-long-lines" (0x92bf11d8)
"funcall" (0x92bf11d0)
"save-restriction" (0x92bf1338)
"progn" (0x92bf1438)
"if" (0x92bf1528)
"when" (0x92bf1618)
"while" (0x92bf1738)
"let" (0x92bf18b8)
"cl--dolist" (0x92bf19a8)
"catch" (0x92bf1be8)
"cl--block-wrapper" (0x92bf1cd8)
"cl-block" (0x92bf1dc8)
"dolist" (0x92bf1eb8)
"let" (0x92bf2068)
"gnus-treat-article" (0x92bf21a0)
"save-restriction" (0x92bf2388)
"if" (0x92bf2488)
"let" (0x92bf2618)
"progn" (0x92bf2718)
"unwind-protect" (0x92bf2828)
"save-current-buffer" (0x92bf2948)
"let" (0x92bf2ac8)
"save-selected-window" (0x92bf2bb8)
"save-excursion" (0x92bf2cd8)
"gnus-display-mime" (0x92bf2eb8)
"funcall" (0x92bf2eb0)
"progn" (0x92bf2ff8)
"if" (0x92bf30e8)
"when" (0x92bf31d8)
"let" (0x92bf3368)
"gnus-article-prepare-display" (0x92bf34a0)
"progn" (0x92bf3648)
"if" (0x92bf3738)
"when" (0x92bf3828)
"if" (0x92bf3928)
"if" (0x92bf3a28)
"save-excursion" (0x92bf3b48)
"let*" (0x92bf3c98)
"save-excursion" (0x92bf3db8)
"gnus-article-prepare" (0x92bf3ef0)
"if" (0x92bf40a8)
"prog1" (0x92bf41b8)
"if" (0x92bf42b8)
"gnus-summary-display-article" (0x92bf43f0)
"if" (0x92bf4598)
"if" (0x92bf4698)
"prog1" (0x92bf47a8)
"gnus-summary-goto-article" (0x92bf48e0)
"if" (0x92bf4a98)
"unless" (0x92bf4b88)
"let" (0x92bf4d08)
"progn" (0x92bf4e08)
"if" (0x92bf4ef8)
"if" (0x92bf4ff8)
"cond" (0x92bf50f8)
"let*" (0x92bf5248)
"gnus-summary-read-group-1" (0x92bf5380)
"or" (0x92bf5558)
"let" (0x92bf56d8)
"setq" (0x92bf57e8)
"null" (0x92bf58d8)
"and" (0x92bf59d8)
"while" (0x92bf5ae8)
"let" (0x92bf5c68)
"gnus-summary-read-group" (0x92bf5da0)
"let" (0x92bf6028)
"gnus-group-read-group" (0x92bf6160)
"if" (0x92bf6328)
"gnus-topic-read-group" (0x92bf6548)
"call-interactively" (0x92bf66e8)

[-- Attachment #3: Type: text/plain, Size: 53 bytes --]


Do you want me to investigate?

        Christopher

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

[Michael Heerdegen]

Eli Zaretskii <eliz@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@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@entry=32027) at marker.c:168
#1  0x08185005 in scan_buffer (target=target@entry=10, start=32027, start@entry=27007, end=32089, 
    end@entry=0, count=count@entry=1, shortage=shortage@entry=0xbf9e418c, 
    allow_quit=allow_quit@entry=1) at search.c:677
#2  0x08185777 in find_before_next_newline (from=27007, to=to@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@entry=4, 
    arg_vector=arg_vector@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@entry=5, 
    arg_vector=arg_vector@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@entry=0, 
    arg_vector=arg_vector@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@entry=0, 
    arg_vector=arg_vector@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@entry=2, 
    arg_vector=arg_vector@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@entry=2, 
    arg_vector=arg_vector@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@entry=2, 
    arg_vector=arg_vector@entry=0xbf9e4d94) at eval.c:3003
#25 0x081afaca in Ffuncall (nargs=nargs@entry=3, args=args@entry=0xbf9e4d90) at eval.c:2898
#26 0x081b0b33 in Fapply (nargs=nargs@entry=2, args=args@entry=0xbf9e4e08) at eval.c:2343
#27 0x081b007f in apply1 (fn=fn@entry=140543522, arg=arg@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@entry=4, args=args@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@entry=0x814a930 <command_loop_1>, 
    handlers=138889274, hfun=hfun@entry=0x8140970 <cmd_error>) at eval.c:1322
#34 0x0813f745 in command_loop_2 (ignore=ignore@entry=138855706) at keyboard.c:1204
#35 0x081ae15b in internal_catch (tag=138887250, func=func@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.

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

[Eli Zaretskii]

> From: Christopher Schmidt <christopher@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.

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

[Christopher Schmidt]

Eli Zaretskii <eliz@gnu.org> writes:
>> From: Christopher Schmidt <christopher@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@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

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

[Eli Zaretskii]

> From: Christopher Schmidt <christopher@ch.ristopher.com>
> Cc: bug-gnu-emacs@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;
 

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

[Christopher Schmidt]

Eli Zaretskii <eliz@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

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

[Eli Zaretskii]

> From: Christopher Schmidt <christopher@ch.ristopher.com>
> Cc: bug-gnu-emacs@gnu.org
> Date: Mon, 10 Sep 2012 14:19:00 +0100 (BST)
> 
> Eli Zaretskii <eliz@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

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

[Christopher Schmidt]

Eli Zaretskii <eliz@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

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

[Eli Zaretskii]

> From: Christopher Schmidt <christopher@ch.ristopher.com>
> Cc: bug-gnu-emacs@gnu.org
> Date: Mon, 10 Sep 2012 18:31:00 +0100 (BST)
> 
> Eli Zaretskii <eliz@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.

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

[Christopher Schmidt]

Eli Zaretskii <eliz@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@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

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

[Eli Zaretskii]

> From: Christopher Schmidt <christopher@ch.ristopher.com>
> Cc: Eli Zaretskii <eliz@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?

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

[Christopher Schmidt]

Eli Zaretskii <eliz@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@gnu.org> and
<83ligikuam.fsf@gnu.org>) applied.

        Christopher

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

[Eli Zaretskii]

> Date: Mon, 17 Sep 2012 21:38:35 +0300
> From: Eli Zaretskii <eliz@gnu.org>
> Cc: 12196@debbugs.gnu.org
> 
> > From: Christopher Schmidt <christopher@ch.ristopher.com>
> > Cc: Eli Zaretskii <eliz@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@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@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);

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

[Christopher Schmidt]

Eli Zaretskii <eliz@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

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

[Eli Zaretskii]

> From: Christopher Schmidt <christopher@ch.ristopher.com>
> Date: Tue, 18 Sep 2012 08:25:17 +0100 (BST)
> 
> Eli Zaretskii <eliz@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.