libvterm segfaults on window resize

Bug #1927320 reported by Sean Sullivan
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
libvterm
New
Undecided
Unassigned

Bug 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 (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.

description: updated
Revision history for this message
Sean Sullivan (ssullivann) wrote :

See minimal breaking example here: https://github.com/sullivan-sean/vterm_resize

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.