* 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).