* bug#52446: 28.0.90; Infinite loop in add_row_entry
[not found] <87a6h61k0e.fsf.ref@yahoo.com>
@ 2021-12-12 5:15 ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors
2021-12-12 7:32 ` Eli Zaretskii
0 siblings, 1 reply; 10+ messages in thread
From: Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors @ 2021-12-12 5:15 UTC (permalink / raw)
To: 52446
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'.
^ permalink raw reply [flat|nested] 10+ messages in thread
* bug#52446: 28.0.90; Infinite loop in add_row_entry
2021-12-12 5:15 ` bug#52446: 28.0.90; Infinite loop in add_row_entry Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors
@ 2021-12-12 7:32 ` Eli Zaretskii
2021-12-12 7:36 ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors
0 siblings, 1 reply; 10+ messages in thread
From: Eli Zaretskii @ 2021-12-12 7:32 UTC (permalink / raw)
To: Po Lu; +Cc: 52446
> Resent-From: Po Lu <luangruo@yahoo.com>
> Original-Sender: "Debbugs-submit" <debbugs-submit-bounces@debbugs.gnu.org>
> Resent-CC: bug-gnu-emacs@gnu.org
> Resent-Sender: help-debbugs@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@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?
^ permalink raw reply [flat|nested] 10+ messages in thread
* bug#52446: 28.0.90; Infinite loop in add_row_entry
2021-12-12 7:32 ` Eli Zaretskii
@ 2021-12-12 7:36 ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors
2021-12-12 9:05 ` Eli Zaretskii
0 siblings, 1 reply; 10+ messages in thread
From: Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors @ 2021-12-12 7:36 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: 52446
Eli Zaretskii <eliz@gnu.org> writes:
>> Resent-From: Po Lu <luangruo@yahoo.com>
>> Original-Sender: "Debbugs-submit" <debbugs-submit-bounces@debbugs.gnu.org>
>> Resent-CC: bug-gnu-emacs@gnu.org
>> Resent-Sender: help-debbugs@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@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.
^ permalink raw reply [flat|nested] 10+ messages in thread
* bug#52446: 28.0.90; Infinite loop in add_row_entry
2021-12-12 7:36 ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors
@ 2021-12-12 9:05 ` Eli Zaretskii
2021-12-12 9:51 ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors
0 siblings, 1 reply; 10+ messages in thread
From: Eli Zaretskii @ 2021-12-12 9:05 UTC (permalink / raw)
To: Po Lu; +Cc: 52446
> From: Po Lu <luangruo@yahoo.com>
> Cc: 52446@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)?
^ permalink raw reply [flat|nested] 10+ messages in thread
* bug#52446: 28.0.90; Infinite loop in add_row_entry
2021-12-12 9:05 ` Eli Zaretskii
@ 2021-12-12 9:51 ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors
2021-12-12 10:10 ` Eli Zaretskii
0 siblings, 1 reply; 10+ messages in thread
From: Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors @ 2021-12-12 9:51 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: 52446
Eli Zaretskii <eliz@gnu.org> writes:
>> From: Po Lu <luangruo@yahoo.com>
>> Cc: 52446@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.
^ permalink raw reply [flat|nested] 10+ messages in thread
* bug#52446: 28.0.90; Infinite loop in add_row_entry
2021-12-12 9:51 ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors
@ 2021-12-12 10:10 ` Eli Zaretskii
2021-12-12 10:21 ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors
0 siblings, 1 reply; 10+ messages in thread
From: Eli Zaretskii @ 2021-12-12 10:10 UTC (permalink / raw)
To: Po Lu; +Cc: 52446
> From: Po Lu <luangruo@yahoo.com>
> Cc: 52446@debbugs.gnu.org
> Date: Sun, 12 Dec 2021 17:51:05 +0800
>
> Eli Zaretskii <eliz@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.
^ permalink raw reply [flat|nested] 10+ messages in thread
* bug#52446: 28.0.90; Infinite loop in add_row_entry
2021-12-12 10:10 ` Eli Zaretskii
@ 2021-12-12 10:21 ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors
2021-12-12 10:30 ` Eli Zaretskii
0 siblings, 1 reply; 10+ messages in thread
From: Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors @ 2021-12-12 10:21 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: 52446
Eli Zaretskii <eliz@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.
^ permalink raw reply [flat|nested] 10+ messages in thread
* bug#52446: 28.0.90; Infinite loop in add_row_entry
2021-12-12 10:21 ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors
@ 2021-12-12 10:30 ` Eli Zaretskii
2021-12-12 10:43 ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors
0 siblings, 1 reply; 10+ messages in thread
From: Eli Zaretskii @ 2021-12-12 10:30 UTC (permalink / raw)
To: Po Lu; +Cc: 52446
> From: Po Lu <luangruo@yahoo.com>
> Cc: 52446@debbugs.gnu.org
> Date: Sun, 12 Dec 2021 18:21:37 +0800
>
> Eli Zaretskii <eliz@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.
^ permalink raw reply [flat|nested] 10+ messages in thread
* bug#52446: 28.0.90; Infinite loop in add_row_entry
2021-12-12 10:30 ` Eli Zaretskii
@ 2021-12-12 10:43 ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors
2021-12-13 13:35 ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors
0 siblings, 1 reply; 10+ messages in thread
From: Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors @ 2021-12-12 10:43 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: 52446
Eli Zaretskii <eliz@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.
^ permalink raw reply [flat|nested] 10+ messages in thread
* bug#52446: 28.0.90; Infinite loop in add_row_entry
2021-12-12 10:43 ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors
@ 2021-12-13 13:35 ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors
0 siblings, 0 replies; 10+ messages in thread
From: Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors @ 2021-12-13 13:35 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: 52446-done
Po Lu <luangruo@yahoo.com> writes:
> Eli Zaretskii <eliz@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.
^ permalink raw reply [flat|nested] 10+ messages in thread
end of thread, other threads:[~2021-12-13 13:35 UTC | newest]
Thread overview: 10+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
[not found] <87a6h61k0e.fsf.ref@yahoo.com>
2021-12-12 5:15 ` bug#52446: 28.0.90; Infinite loop in add_row_entry Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors
2021-12-12 7:32 ` Eli Zaretskii
2021-12-12 7:36 ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors
2021-12-12 9:05 ` Eli Zaretskii
2021-12-12 9:51 ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors
2021-12-12 10:10 ` Eli Zaretskii
2021-12-12 10:21 ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors
2021-12-12 10:30 ` Eli Zaretskii
2021-12-12 10:43 ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors
2021-12-13 13:35 ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).