[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#12196: 24.1.50; setting cache-long-line-scans to non-nil freezes Ema
bug#12196: 24.1.50; setting cache-long-line-scans to non-nil freezes Emacs
Sun, 26 Aug 2012 12:53:49 +0100 (BST)
Eli Zaretskii <address@hidden> 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
> I cannot reproduce any of this on my system. Emacs never freezes on
> 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 188.8.131.52
(x86_64-unknown-linux-gnu, GTK+ Version 2.24.10) of 2012-08-26, revno:
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:
Description: Text document
Do you want me to investigate?