On Mon, 12 Apr 2021 19:08:40 +0300, Erik Ruotsalainen wrote:
> I managed to replicate the bug, but not consistently. Anyway, the
> offender was a conditional statement in vs_refresh.c:
>
> 262: } else if (LNO > TMAP->lno) {
>
> which makes me suspect that either sp->lno or TMAP->lno aren't properly
> initialized when the bug occurs.
tl;dr OK millert@ or read on for more details.
I was able to reproduce this too (takes longer without optimization).
In my case, TMAP evaluates to the following:
(gdb) p ((VI_PRIVATE *)((sp)->vi_private))->t_smap
$6 = (SMAP *) 0xa897f129fd0
(gdb) p *((VI_PRIVATE *)((sp)->vi_private))->t_smap
Cannot access memory at address 0xa897f129fd0
So it seems that t_smap has a bogus value (h_smap seems to be OK).
(gdb) p ((VI_PRIVATE *)((sp)->vi_private))->h_smap
$8 = (SMAP *) 0xa897f12a000
(gdb) p *((VI_PRIVATE *)((sp)->vi_private))->h_smap
$10 = {lno = 1, coff = 0, soff = 1, c_sboff = 0, c_eboff = 0,
c_scoff = 0 '\000', c_eclen = 0 '\000', c_ecsize = 0 '\000'}
Note that there are multiple places that use "sp->t_rows - 1", e.g.:
TMAP = HMAP + (sp->t_rows - 1);
which will cause unexpected behavior when sp->t_rows == 0.
Requiring that window be non-zero seems like the simplest fix since
the vi code is clearly not prepared to handle the case where t_rows
is 0. It doesn't make sense to try to support a zero-row window
since there would be no room to actually edit.
- todd
