GNU bug report logs -
#52446
28.0.90; Infinite loop in add_row_entry
Previous Next
Reported by: Po Lu <luangruo <at> yahoo.com>
Date: Sun, 12 Dec 2021 05:16:01 UTC
Severity: normal
Found in version 28.0.90
Done: Po Lu <luangruo <at> yahoo.com>
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 52446 in the body.
You can then email your comments to 52446 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#52446; Package
emacs.
(Sun, 12 Dec 2021 05:16:01 GMT)
Full text and
rfc822 format available.
Acknowledgement sent
to
Po Lu <luangruo <at> yahoo.com>:
New bug report received and forwarded. Copy sent to
bug-gnu-emacs <at> gnu.org.
(Sun, 12 Dec 2021 05:16:02 GMT)
Full text and
rfc822 format available.
Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):
Emacs froze while I was scrolling through a large image with `C-n'. The
source of the freeze was an infinite loop in this part of
`add_row_entry':
while (entry && !row_equal_p (entry->row, row, 1))
---> entry = entry->next;
The problem seems to be that `entry' points to the same address as
`entry->next'.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#52446; Package
emacs.
(Sun, 12 Dec 2021 07:33:02 GMT)
Full text and
rfc822 format available.
Message #8 received at 52446 <at> debbugs.gnu.org (full text, mbox):
> Resent-From: Po Lu <luangruo <at> yahoo.com>
> Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
> Resent-CC: bug-gnu-emacs <at> gnu.org
> Resent-Sender: help-debbugs <at> gnu.org
> Date: Sun, 12 Dec 2021 13:15:29 +0800
> From: Po Lu via "Bug reports for GNU Emacs,
> the Swiss army knife of text editors" <bug-gnu-emacs <at> gnu.org>
>
> Emacs froze while I was scrolling through a large image with `C-n'. The
> source of the freeze was an infinite loop in this part of
> `add_row_entry':
>
> while (entry && !row_equal_p (entry->row, row, 1))
> ---> entry = entry->next;
>
> The problem seems to be that `entry' points to the same address as
> `entry->next'.
Are you sure? This more-or-less "can't happen". How did you see that
this was the problem?
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#52446; Package
emacs.
(Sun, 12 Dec 2021 07:37:01 GMT)
Full text and
rfc822 format available.
Message #11 received at 52446 <at> debbugs.gnu.org (full text, mbox):
Eli Zaretskii <eliz <at> gnu.org> writes:
>> Resent-From: Po Lu <luangruo <at> yahoo.com>
>> Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
>> Resent-CC: bug-gnu-emacs <at> gnu.org
>> Resent-Sender: help-debbugs <at> gnu.org
>> Date: Sun, 12 Dec 2021 13:15:29 +0800
>> From: Po Lu via "Bug reports for GNU Emacs,
>> the Swiss army knife of text editors" <bug-gnu-emacs <at> gnu.org>
>>
>> Emacs froze while I was scrolling through a large image with `C-n'. The
>> source of the freeze was an infinite loop in this part of
>> `add_row_entry':
>>
>> while (entry && !row_equal_p (entry->row, row, 1))
>> ---> entry = entry->next;
>>
>> The problem seems to be that `entry' points to the same address as
>> `entry->next'.
> Are you sure? This more-or-less "can't happen". How did you see that
> this was the problem?
I did `p entry' and `p entry->next' in gdb. Both pointed to the same
address.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#52446; Package
emacs.
(Sun, 12 Dec 2021 09:06:02 GMT)
Full text and
rfc822 format available.
Message #14 received at 52446 <at> debbugs.gnu.org (full text, mbox):
> From: Po Lu <luangruo <at> yahoo.com>
> Cc: 52446 <at> debbugs.gnu.org
> Date: Sun, 12 Dec 2021 15:36:30 +0800
>
> >> while (entry && !row_equal_p (entry->row, row, 1))
> >> ---> entry = entry->next;
> >>
> >> The problem seems to be that `entry' points to the same address as
> >> `entry->next'.
>
> > Are you sure? This more-or-less "can't happen". How did you see that
> > this was the problem?
>
> I did `p entry' and `p entry->next' in gdb. Both pointed to the same
> address.
At which point in the code did you print those?
And what were the values of entry->row (you can display them with
pgrowx)?
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#52446; Package
emacs.
(Sun, 12 Dec 2021 09:52:01 GMT)
Full text and
rfc822 format available.
Message #17 received at 52446 <at> debbugs.gnu.org (full text, mbox):
Eli Zaretskii <eliz <at> gnu.org> writes:
>> From: Po Lu <luangruo <at> yahoo.com>
>> Cc: 52446 <at> debbugs.gnu.org
>> Date: Sun, 12 Dec 2021 15:36:30 +0800
>>
>> >> while (entry && !row_equal_p (entry->row, row, 1))
>> >> ---> entry = entry->next;
>> >>
>> >> The problem seems to be that `entry' points to the same address as
>> >> `entry->next'.
>>
>> > Are you sure? This more-or-less "can't happen". How did you see that
>> > this was the problem?
>>
>> I did `p entry' and `p entry->next' in gdb. Both pointed to the same
>> address.
>
> At which point in the code did you print those?
Inside the infinite loop.
> And what were the values of entry->row (you can display them with
> pgrowx)?
It prints the following text:
RIGHT: 54 glyphs
0 0: CHAR[0x0] pos=-734003200 blev=0,btyp=UNDEF w=0 a+d=9216+-18611
1 0: CHAR[0xec000000] pos=0 blev=0,btyp=UNDEF w=0 a+d=-7424+909 face=119 vof=1
2 0: CHAR[0x2500007f] pos=452984959 blev=0,btyp=UNDEF w=0 a+d=0+0
3 0: CHAR[0x0] pos=-318766977 blev=0,btyp=UNDEF w=0 a+d=8704+0 face=1
4 0: pos=-1392508928 w=127 a+d=1280+-16534 face=828327 vof=-20 MB OVL [ ]
5 127: CHAR[0x0] pos=805306368 blev=0,btyp=UNDEF w=0 a+d=0+0
6 127: CHAR[0x30000000] pos=805306368 blev=0,btyp=UNDEF w=0 a+d=0+0
7 127: CHAR[0x0] pos=0 blev=0,btyp=UNDEF w=0 a+d=12288+0
8 127: CHAR[0x0] pos=0 blev=0,btyp=UNDEF w=0 a+d=0+0
9 127: CHAR[0x0] pos=33554432 blev=0,btyp=UNDEF w=0 a+d=512+0
10 127: CHAR[0x0] pos=0 blev=0,btyp=UNDEF w=0 a+d=12288+0
11 127: CHAR[0x30000000] pos=2063597568 blev=0,btyp=UNDEF w=127 a+d=0+0
12 254: CHAR[0x1000000] pos=0 blev=0,btyp=UNDEF w=0 a+d=-4096+743 vof=1
13 254: CHAR[0x1000000] pos=16777216 blev=0,btyp=UNDEF w=0 a+d=256+0
14 254: CHAR[0x0] pos=16777216 blev=0,btyp=UNDEF w=0 a+d=0+0
15 254: CHAR[0x1000000] pos=0 blev=0,btyp=UNDEF w=0 a+d=-26624+11687 vof=1
16 254: CHAR[0x0] pos=16777216 blev=0,btyp=UNDEF w=0 a+d=256+0
17 254: CHAR[0x0] pos=0 blev=0,btyp=UNDEF w=0 a+d=0+0
18 254: pos=0 w=-1 a+d=-1+-1 vof=-1 MB PAD N/A OVL AVOID [ ]
19 253: CHAR[0x0] pos=16777216 blev=0,btyp=UNDEF w=0 a+d=0+0
20 253: CHAR[0x74000000] pos=0 blev=0,btyp=UNDEF w=0 a+d=0+0 face=655360
21 253: CHAR[0x80000000] pos=-1929379713 blev=0,btyp=UNDEF w=0 a+d=0+16 face=91794 vof=1
22 253: pos=0 w=0 a+d=-16384+-5898 face=655360 vof=-21 MB OVL [ ]
23 253: CHAR[0xf000007f] pos=1560281088 blev=0,btyp=UNDEF w=0 a+d=-19712+-19263
24 253: pos=33554432 w=0 a+d=-16384+-6069 face=655360 vof=-21 MB OVL [ ]
25 253: CHAR[0x90000000] pos=-1258291200 blev=0,btyp=UNDEF w=0 a+d=8960+-19263
26 253: CHAR[0xa400000] pos=-1543503872 blev=0,btyp=UNDEF w=0 a+d=-16384+-17738 face=47798
27 253: CHAR[0xa0000000] pos=-1006632960 blev=0,btyp=UNDEF w=0 a+d=9728+0 face=46272
28 253: CHAR[0x5000000] pos=-1879048192 blev=0,btyp=UNDEF w=0 a+d=16384+-17736 face=47735
29 253: CHAR[0x5000000] pos=171966464 blev=0,btyp=UNDEF w=0 a+d=32000+11690 vof=1
30 253: CHAR[0x6000000] pos=171966464 blev=0,btyp=UNDEF w=0 a+d=9472+26277 vof=1
31 253: CHAR[0xc0000000] pos=-268435456 blev=0,btyp=UNDEF w=127 a+d=0+0
32 380: CHAR[0xd0000000] pos=33554559 blev=0,btyp=UNDEF w=0 a+d=12288+0
33 380: CHAR[0xd0000000] pos=-805306368 blev=0,btyp=UNDEF w=0 a+d=-12288+245 face=245
34 380: CHAR[0xd0000000] pos=-805306368 blev=0,btyp=UNDEF w=0 a+d=-12288+245 face=245
35 380: pos=-805306368 w=0 a+d=15104+-25445 face=245 vof=-20 MB OVL [ ]
36 380: CHAR[0x0] pos=805306368 blev=0,btyp=UNDEF w=0 a+d=8448+0 face=724146
37 380: CHAR[0x18000000] pos=553648128 blev=0,btyp=UNDEF w=-7102 a+d=22749+0
38 -6722: CHAR[0x6f00006d] pos=0 blev=0,btyp=UNDEF w=0 a+d=8448+0 face=221549
39 -6722: CHAR[0x2f000000] pos=553648243 blev=0,btyp=UNDEF w=25645 a+d=31073+0
40 18923: pos=1918986355 w=29801 a+d=97+28528 face=156265 vof=27693 N/A OVL AVOID [ ]
41 48724: IMAGE[1] slice=8706,50290,47091,5475 pos=358856691 w=1 a+d=0+8706 face=1 vof=-15246 PAD N/A OVL AVOID [ ]
42 48725: IMAGE[0] slice=0,24832,0,0 pos=358856691 w=1 a+d=0+8706 face=1 vof=-15246 PAD N/A OVL AVOID [ ]
43 48726: pos=-1811939201 w=0 a+d=0+25024 face=78033 vof=-36 MB OVL [ ]
44 48726: CHAR[0xc0000000] pos=127 blev=0,btyp=UNDEF w=0 a+d=0+0
45 48726: CHAR[0x0] pos=1073741824 blev=0,btyp=UNDEF w=0 a+d=0+11868 face=77407 vof=1
46 48726: CHAR[0xfd000000] pos=-251658240 blev=0,btyp=UNDEF w=0 a+d=0+0 face=58281
47 48726: CHAR[0x0] pos=0 blev=0,btyp=UNDEF w=0 a+d=0+0
48 48726: CHAR[0x0] pos=16777216 blev=0,btyp=UNDEF w=0 a+d=0+0
49 48726: CHAR[0x0] pos=0 blev=0,btyp=UNDEF w=0 a+d=0+0
50 48726: CHAR[0x0] pos=0 blev=0,btyp=UNDEF w=0 a+d=0+0
51 48726: CHAR[0x21000000] pos=553648128 blev=0,btyp=UNDEF w=0 a+d=0+0 face=50249
52 48726: CHAR[0x40000000] pos=1023422208 blev=0,btyp=UNDEF w=0 a+d=16640+0 face=42283
53 48726: CHAR[0x1000000] pos=1073741824 blev=0,btyp=UNDEF w=0 a+d=0+0 face=69034 vof=1536
Does this make sense? I think it's starting to smell like a memory
problem of sorts.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#52446; Package
emacs.
(Sun, 12 Dec 2021 10:12:02 GMT)
Full text and
rfc822 format available.
Message #20 received at 52446 <at> debbugs.gnu.org (full text, mbox):
> From: Po Lu <luangruo <at> yahoo.com>
> Cc: 52446 <at> debbugs.gnu.org
> Date: Sun, 12 Dec 2021 17:51:05 +0800
>
> Eli Zaretskii <eliz <at> gnu.org> writes:
>
> > At which point in the code did you print those?
>
> Inside the infinite loop.
And if you go over the row_table[] array, how many such entries doi
you see there? And what is the value of row_table_size?
> RIGHT: 54 glyphs
> 0 0: CHAR[0x0] pos=-734003200 blev=0,btyp=UNDEF w=0 a+d=9216+-18611
> 1 0: CHAR[0xec000000] pos=0 blev=0,btyp=UNDEF w=0 a+d=-7424+909 face=119 vof=1
> 2 0: CHAR[0x2500007f] pos=452984959 blev=0,btyp=UNDEF w=0 a+d=0+0
> 3 0: CHAR[0x0] pos=-318766977 blev=0,btyp=UNDEF w=0 a+d=8704+0 face=1
> 4 0: pos=-1392508928 w=127 a+d=1280+-16534 face=828327 vof=-20 MB OVL [ ]
> 5 127: CHAR[0x0] pos=805306368 blev=0,btyp=UNDEF w=0 a+d=0+0
> 6 127: CHAR[0x30000000] pos=805306368 blev=0,btyp=UNDEF w=0 a+d=0+0
> 7 127: CHAR[0x0] pos=0 blev=0,btyp=UNDEF w=0 a+d=12288+0
> 8 127: CHAR[0x0] pos=0 blev=0,btyp=UNDEF w=0 a+d=0+0
> 9 127: CHAR[0x0] pos=33554432 blev=0,btyp=UNDEF w=0 a+d=512+0
> 10 127: CHAR[0x0] pos=0 blev=0,btyp=UNDEF w=0 a+d=12288+0
> 11 127: CHAR[0x30000000] pos=2063597568 blev=0,btyp=UNDEF w=127 a+d=0+0
> 12 254: CHAR[0x1000000] pos=0 blev=0,btyp=UNDEF w=0 a+d=-4096+743 vof=1
> 13 254: CHAR[0x1000000] pos=16777216 blev=0,btyp=UNDEF w=0 a+d=256+0
> 14 254: CHAR[0x0] pos=16777216 blev=0,btyp=UNDEF w=0 a+d=0+0
> 15 254: CHAR[0x1000000] pos=0 blev=0,btyp=UNDEF w=0 a+d=-26624+11687 vof=1
> 16 254: CHAR[0x0] pos=16777216 blev=0,btyp=UNDEF w=0 a+d=256+0
> 17 254: CHAR[0x0] pos=0 blev=0,btyp=UNDEF w=0 a+d=0+0
> 18 254: pos=0 w=-1 a+d=-1+-1 vof=-1 MB PAD N/A OVL AVOID [ ]
> 19 253: CHAR[0x0] pos=16777216 blev=0,btyp=UNDEF w=0 a+d=0+0
> 20 253: CHAR[0x74000000] pos=0 blev=0,btyp=UNDEF w=0 a+d=0+0 face=655360
> 21 253: CHAR[0x80000000] pos=-1929379713 blev=0,btyp=UNDEF w=0 a+d=0+16 face=91794 vof=1
> 22 253: pos=0 w=0 a+d=-16384+-5898 face=655360 vof=-21 MB OVL [ ]
> 23 253: CHAR[0xf000007f] pos=1560281088 blev=0,btyp=UNDEF w=0 a+d=-19712+-19263
> 24 253: pos=33554432 w=0 a+d=-16384+-6069 face=655360 vof=-21 MB OVL [ ]
> 25 253: CHAR[0x90000000] pos=-1258291200 blev=0,btyp=UNDEF w=0 a+d=8960+-19263
> 26 253: CHAR[0xa400000] pos=-1543503872 blev=0,btyp=UNDEF w=0 a+d=-16384+-17738 face=47798
> 27 253: CHAR[0xa0000000] pos=-1006632960 blev=0,btyp=UNDEF w=0 a+d=9728+0 face=46272
> 28 253: CHAR[0x5000000] pos=-1879048192 blev=0,btyp=UNDEF w=0 a+d=16384+-17736 face=47735
> 29 253: CHAR[0x5000000] pos=171966464 blev=0,btyp=UNDEF w=0 a+d=32000+11690 vof=1
> 30 253: CHAR[0x6000000] pos=171966464 blev=0,btyp=UNDEF w=0 a+d=9472+26277 vof=1
> 31 253: CHAR[0xc0000000] pos=-268435456 blev=0,btyp=UNDEF w=127 a+d=0+0
> 32 380: CHAR[0xd0000000] pos=33554559 blev=0,btyp=UNDEF w=0 a+d=12288+0
> 33 380: CHAR[0xd0000000] pos=-805306368 blev=0,btyp=UNDEF w=0 a+d=-12288+245 face=245
> 34 380: CHAR[0xd0000000] pos=-805306368 blev=0,btyp=UNDEF w=0 a+d=-12288+245 face=245
> 35 380: pos=-805306368 w=0 a+d=15104+-25445 face=245 vof=-20 MB OVL [ ]
> 36 380: CHAR[0x0] pos=805306368 blev=0,btyp=UNDEF w=0 a+d=8448+0 face=724146
> 37 380: CHAR[0x18000000] pos=553648128 blev=0,btyp=UNDEF w=-7102 a+d=22749+0
> 38 -6722: CHAR[0x6f00006d] pos=0 blev=0,btyp=UNDEF w=0 a+d=8448+0 face=221549
> 39 -6722: CHAR[0x2f000000] pos=553648243 blev=0,btyp=UNDEF w=25645 a+d=31073+0
> 40 18923: pos=1918986355 w=29801 a+d=97+28528 face=156265 vof=27693 N/A OVL AVOID [ ]
> 41 48724: IMAGE[1] slice=8706,50290,47091,5475 pos=358856691 w=1 a+d=0+8706 face=1 vof=-15246 PAD N/A OVL AVOID [ ]
> 42 48725: IMAGE[0] slice=0,24832,0,0 pos=358856691 w=1 a+d=0+8706 face=1 vof=-15246 PAD N/A OVL AVOID [ ]
> 43 48726: pos=-1811939201 w=0 a+d=0+25024 face=78033 vof=-36 MB OVL [ ]
> 44 48726: CHAR[0xc0000000] pos=127 blev=0,btyp=UNDEF w=0 a+d=0+0
> 45 48726: CHAR[0x0] pos=1073741824 blev=0,btyp=UNDEF w=0 a+d=0+11868 face=77407 vof=1
> 46 48726: CHAR[0xfd000000] pos=-251658240 blev=0,btyp=UNDEF w=0 a+d=0+0 face=58281
> 47 48726: CHAR[0x0] pos=0 blev=0,btyp=UNDEF w=0 a+d=0+0
> 48 48726: CHAR[0x0] pos=16777216 blev=0,btyp=UNDEF w=0 a+d=0+0
> 49 48726: CHAR[0x0] pos=0 blev=0,btyp=UNDEF w=0 a+d=0+0
> 50 48726: CHAR[0x0] pos=0 blev=0,btyp=UNDEF w=0 a+d=0+0
> 51 48726: CHAR[0x21000000] pos=553648128 blev=0,btyp=UNDEF w=0 a+d=0+0 face=50249
> 52 48726: CHAR[0x40000000] pos=1023422208 blev=0,btyp=UNDEF w=0 a+d=16640+0 face=42283
> 53 48726: CHAR[0x1000000] pos=1073741824 blev=0,btyp=UNDEF w=0 a+d=0+0 face=69034 vof=1536
>
> Does this make sense? I think it's starting to smell like a memory
> problem of sorts.
This glyph row is clearly garbage. So yes, the question is how did
that got into the table.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#52446; Package
emacs.
(Sun, 12 Dec 2021 10:22:02 GMT)
Full text and
rfc822 format available.
Message #23 received at 52446 <at> debbugs.gnu.org (full text, mbox):
Eli Zaretskii <eliz <at> gnu.org> writes:
> And if you go over the row_table[] array, how many such entries doi
> you see there? And what is the value of row_table_size?
row_table_size is 269. All 269 elements of row_table are NULL.
Thanks.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#52446; Package
emacs.
(Sun, 12 Dec 2021 10:31:02 GMT)
Full text and
rfc822 format available.
Message #26 received at 52446 <at> debbugs.gnu.org (full text, mbox):
> From: Po Lu <luangruo <at> yahoo.com>
> Cc: 52446 <at> debbugs.gnu.org
> Date: Sun, 12 Dec 2021 18:21:37 +0800
>
> Eli Zaretskii <eliz <at> gnu.org> writes:
>
> > And if you go over the row_table[] array, how many such entries doi
> > you see there? And what is the value of row_table_size?
>
> row_table_size is 269. All 269 elements of row_table are NULL.
Now I'm confused: if row_table[i] is NULL for each i, then how did we
enter that loop? Its condition checks for entry being non-NULL.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#52446; Package
emacs.
(Sun, 12 Dec 2021 10:44:02 GMT)
Full text and
rfc822 format available.
Message #29 received at 52446 <at> debbugs.gnu.org (full text, mbox):
Eli Zaretskii <eliz <at> gnu.org> writes:
> Now I'm confused: if row_table[i] is NULL for each i, then how did we
> enter that loop? Its condition checks for entry being non-NULL.
The disassembly checks out, so that condition is not being mis-compiled.
But that doesn't rule out the possibility of a miscompilation elsewhere.
I will try to reproduce this under a memory checker, and with
optimizations turned off.
Reply sent
to
Po Lu <luangruo <at> yahoo.com>:
You have taken responsibility.
(Mon, 13 Dec 2021 13:37:02 GMT)
Full text and
rfc822 format available.
Notification sent
to
Po Lu <luangruo <at> yahoo.com>:
bug acknowledged by developer.
(Mon, 13 Dec 2021 13:37:02 GMT)
Full text and
rfc822 format available.
Message #34 received at 52446-done <at> debbugs.gnu.org (full text, mbox):
Po Lu <luangruo <at> yahoo.com> writes:
> Eli Zaretskii <eliz <at> gnu.org> writes:
>
>> Now I'm confused: if row_table[i] is NULL for each i, then how did we
>> enter that loop? Its condition checks for entry being non-NULL.
>
> The disassembly checks out, so that condition is not being mis-compiled.
> But that doesn't rule out the possibility of a miscompilation elsewhere.
>
> I will try to reproduce this under a memory checker, and with
> optimizations turned off.
It is a miscompilation of scrolling_window, which disappeared after
updating GCC. Closing this bug, and thanks for the help.
bug archived.
Request was from
Debbugs Internal Request <help-debbugs <at> gnu.org>
to
internal_control <at> debbugs.gnu.org.
(Tue, 11 Jan 2022 12:24:05 GMT)
Full text and
rfc822 format available.
This bug report was last modified 3 years and 158 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.