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: