GNU bug report logs -
#21200
25.0.50; xdisp.c: infinite loop when using invisibility specs
Previous Next
Reported by: Pip Cet <pipcet <at> gmail.com>
Date: Thu, 6 Aug 2015 19:15:02 UTC
Severity: normal
Found in version 25.0.50
Done: Eli Zaretskii <eliz <at> gnu.org>
Bug is archived. No further changes may be made.
To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 21200 in the body.
You can then email your comments to 21200 AT debbugs.gnu.org in the normal way.
Toggle the display of automated, internal messages from the tracker.
Report forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#21200
; Package
emacs
.
(Thu, 06 Aug 2015 19:15:02 GMT)
Full text and
rfc822 format available.
Acknowledgement sent
to
Pip Cet <pipcet <at> gmail.com>
:
New bug report received and forwarded. Copy sent to
bug-gnu-emacs <at> gnu.org
.
(Thu, 06 Aug 2015 19:15:02 GMT)
Full text and
rfc822 format available.
Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
Hi,
with the current git tree (revision 0aec2aac), I'm running into
problems with an infinite loop in xdisp.c which I believe to be fixed
by this patch, which is reasonably obvious:
diff --git a/src/xdisp.c b/src/xdisp.c
index e45cb87..7b221d4 100644
--- a/src/xdisp.c
+++ b/src/xdisp.c
@@ -4221,6 +4221,8 @@ handle_invisible_prop (struct it *it)
if (invis == 2)
display_ellipsis_p = true;
}
+
+ charpos = end_charpos;
}
while (invis != 0 && endpos < len);
in this loop:
do
{
end_charpos = Fnext_single_property_change (charpos, Qinvisible,
it->string, limit);
if (INTEGERP (end_charpos))
{
endpos = XFASTINT (end_charpos);
charpos = end_charpos;
prop = Fget_text_property (end_charpos, Qinvisible, it->string);
invis = TEXT_PROP_MEANS_INVISIBLE (prop);
if (invis == 2)
display_ellipsis_p = true;
}
}
while (invis != 0 && endpos < len);
Without the patch, we keep calling Fnext_property_change with the same
arguments and expecting a different result, which obviously never
happens. In fact it seems to me we only need one of charpos and
end_charpos as the code currently stands, anyway. However, charpos =
f(..., charpos, ...) might cause confusion.
I can provide more detail if necessary, but as I said, it's a fairly
obvious bug.
[emacs-006.diff (text/plain, attachment)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#21200
; Package
emacs
.
(Thu, 06 Aug 2015 19:37:02 GMT)
Full text and
rfc822 format available.
Message #8 received at 21200 <at> debbugs.gnu.org (full text, mbox):
> Date: Thu, 6 Aug 2015 18:26:05 +0000
> From: Pip Cet <pipcet <at> gmail.com>
>
> with the current git tree (revision 0aec2aac), I'm running into
> problems with an infinite loop in xdisp.c which I believe to be fixed
> by this patch, which is reasonably obvious:
>
> diff --git a/src/xdisp.c b/src/xdisp.c
> index e45cb87..7b221d4 100644
> --- a/src/xdisp.c
> +++ b/src/xdisp.c
> @@ -4221,6 +4221,8 @@ handle_invisible_prop (struct it *it)
> if (invis == 2)
> display_ellipsis_p = true;
> }
> +
> + charpos = end_charpos;
> }
> while (invis != 0 && endpos < len);
>
> in this loop:
>
> do
> {
> end_charpos = Fnext_single_property_change (charpos, Qinvisible,
> it->string, limit);
> if (INTEGERP (end_charpos))
> {
> endpos = XFASTINT (end_charpos);
> charpos = end_charpos;
> prop = Fget_text_property (end_charpos, Qinvisible, it->string);
> invis = TEXT_PROP_MEANS_INVISIBLE (prop);
> if (invis == 2)
> display_ellipsis_p = true;
> }
> }
> while (invis != 0 && endpos < len);
>
> Without the patch, we keep calling Fnext_property_change with the same
> arguments and expecting a different result, which obviously never
> happens. In fact it seems to me we only need one of charpos and
> end_charpos as the code currently stands, anyway. However, charpos =
> f(..., charpos, ...) might cause confusion.
>
> I can provide more detail if necessary, but as I said, it's a fairly
> obvious bug.
Yes, please provide the details, and preferably also a recipe where
you see the loop.
Thanks.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#21200
; Package
emacs
.
(Thu, 06 Aug 2015 21:17:01 GMT)
Full text and
rfc822 format available.
Message #11 received at 21200 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
Dear Eli,
thank you for responding. I've attached the output of M-x
report-emacs-bug, including the gdb backtrace and a test script that
triggers the problem. If you need me to run further tests, please let
me know.
My apologies for sending an incomplete report at first.
Thanks!
On Thu, Aug 6, 2015 at 7:36 PM, Eli Zaretskii <eliz <at> gnu.org> wrote:
>> Date: Thu, 6 Aug 2015 18:26:05 +0000
>> From: Pip Cet <pipcet <at> gmail.com>
>>
>> with the current git tree (revision 0aec2aac), I'm running into
>> problems with an infinite loop in xdisp.c which I believe to be fixed
>> by this patch, which is reasonably obvious:
>>
>> diff --git a/src/xdisp.c b/src/xdisp.c
>> index e45cb87..7b221d4 100644
>> --- a/src/xdisp.c
>> +++ b/src/xdisp.c
>> @@ -4221,6 +4221,8 @@ handle_invisible_prop (struct it *it)
>> if (invis == 2)
>> display_ellipsis_p = true;
>> }
>> +
>> + charpos = end_charpos;
>> }
>> while (invis != 0 && endpos < len);
>>
>> in this loop:
>>
>> do
>> {
>> end_charpos = Fnext_single_property_change (charpos, Qinvisible,
>> it->string, limit);
>> if (INTEGERP (end_charpos))
>> {
>> endpos = XFASTINT (end_charpos);
>> charpos = end_charpos;
>> prop = Fget_text_property (end_charpos, Qinvisible, it->string);
>> invis = TEXT_PROP_MEANS_INVISIBLE (prop);
>> if (invis == 2)
>> display_ellipsis_p = true;
>> }
>> }
>> while (invis != 0 && endpos < len);
>>
>> Without the patch, we keep calling Fnext_property_change with the same
>> arguments and expecting a different result, which obviously never
>> happens. In fact it seems to me we only need one of charpos and
>> end_charpos as the code currently stands, anyway. However, charpos =
>> f(..., charpos, ...) might cause confusion.
>>
>> I can provide more detail if necessary, but as I said, it's a fairly
>> obvious bug.
>
> Yes, please provide the details, and preferably also a recipe where
> you see the loop.
>
> Thanks.
[emacs-bug-info-001.txt (text/plain, attachment)]
[emacs-bug-001.el (text/x-emacs-lisp, attachment)]
Reply sent
to
Eli Zaretskii <eliz <at> gnu.org>
:
You have taken responsibility.
(Fri, 07 Aug 2015 13:47:01 GMT)
Full text and
rfc822 format available.
Notification sent
to
Pip Cet <pipcet <at> gmail.com>
:
bug acknowledged by developer.
(Fri, 07 Aug 2015 13:47:02 GMT)
Full text and
rfc822 format available.
Message #16 received at 21200-done <at> debbugs.gnu.org (full text, mbox):
> Date: Thu, 6 Aug 2015 21:16:26 +0000
> From: Pip Cet <pipcet <at> gmail.com>
> Cc: 21200 <at> debbugs.gnu.org
>
> thank you for responding. I've attached the output of M-x
> report-emacs-bug, including the gdb backtrace and a test script that
> triggers the problem. If you need me to run further tests, please let
> me know.
Thanks. Your analysis was correct, of course. I fixed the bug with a
slightly different change (see commit 701484d on master), and also
added to the display engine's test suite a test case like the one you
presented.
> My apologies for sending an incomplete report at first.
No need to apologize.
bug archived.
Request was from
Debbugs Internal Request <help-debbugs <at> gnu.org>
to
internal_control <at> debbugs.gnu.org
.
(Sat, 05 Sep 2015 11:24:04 GMT)
Full text and
rfc822 format available.
This bug report was last modified 9 years and 292 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.