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

Previous Next

Full log

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

Previous Next

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