| 2021-05-06 07:47:11 |
Sean Sullivan |
description |
I'm running libvterm with a screen callback on damage that reads the damaged rectangle into a buffer. When the screen is resized from tall and skinny to wide and short (e.g. 100 rows x 50 cols to 50 rows x 100 cols), I get a segfault, that seems to come from trying to access a null cell on screen.c:700. From what I can tell, this cell is null because the screen is damaged with a rectangle that has dimensions (0, old_rows, old_cols, new_cols) on screen.c:532 after the screen has already been realloced to support only new_rows rows. Since new_rows < old_rows, and the damaged rectangle includes rows 0-old_rows, trying to access rows > new_rows results in a null cell.
Unfortunately, there is no way to identify that the size of the screen has already decreased before this damage because the number of new rows and columns are updated on the screen object after the realloc, but not on the VTerm object (which is the only place get_size is exposed)
It would be nice to either have a way to tell that the screen is smaller when this damagerect occurs or change the ordering of/logic of the realloc + damaging that occurs during a screen resizing to accommodate this resize. |
I'm running libvterm with a screen callback on damage that reads the damaged rectangle into a buffer. When the screen is resized from tall and skinny to wide and short (e.g. 100 rows x 50 cols to 50 rows x 100 cols), I get a segfault, that seems to come from trying to access a null cell on screen.c:700 (https://github.com/neovim/libvterm/blob/nvim/src/screen.c#L700). From what I can tell, this cell is null because the screen is damaged with a rectangle that has dimensions (0, old_rows, old_cols, new_cols) on screen.c:532 (https://github.com/neovim/libvterm/blob/nvim/src/screen.c#L532) after the screen has already been realloced to support only new_rows rows. Since new_rows < old_rows, and the damaged rectangle includes rows 0-old_rows, trying to access rows > new_rows results in a null cell.
Unfortunately, there is no way to identify that the size of the screen has already decreased before this damage because the number of new rows and columns are updated on the screen object after the realloc, but not on the VTerm object (which is the only place get_size is exposed)
It would be nice to either have a way to tell that the screen is smaller when this damagerect occurs or change the ordering of/logic of the realloc + damaging that occurs during a screen resizing to accommodate this resize. |
|
