Page MenuHomePhabricator

Terminology receives a SIGSEGV when resized down and neovim running
Closed, ResolvedPublic



Terminology crashes (SIGSEGV) when resized down when running neovim.

How to reproduce

  1. Open terminology (I'm on commit 99da684d8159462e2b8980c56f2400525aeebe40)
  2. From the interactive shell, open something like vim or neovim (I can systematically reproduce with neovim)
  3. Resize down to (0,0).


Thread 1 "terminology" received signal SIGSEGV, Segmentation fault.
0x00005555555b74d5 in term_link_refcount_dec (ty=0x555556025b90, link_id=21990, count=1) at ../src/bin/termpty.h:369
369        link->refcount -= count;
(gdb) bt
#0  0x00005555555b74d5 in term_link_refcount_dec (ty=0x555556025b90, link_id=21990, count=1) at ../src/bin/termpty.h:369
#1  0x00005555555b7605 in termpty_cell_fill (ty=0x555556025b90, src=0x7fffffff64ac, dst=0x5555564887f8, n=45) at ../src/bin/termpty.h:404
#2  0x00005555555b784f in termpty_cells_fill (ty=0x555556025b90, codepoint=0 L'\000', cells=0x5555564887f8, count=45) at ../src/bin/termptyops.c:33
#3  0x00005555555b7891 in termpty_cells_clear (ty=0x555556025b90, cells=0x5555564887f8, count=45) at ../src/bin/termptyops.c:39
#4  0x00005555555b7a97 in termpty_text_scroll (ty=0x555556025b90, clear=1 '\001') at ../src/bin/termptyops.c:67
#5  0x00005555555b832b in termpty_text_scroll_test (ty=0x555556025b90, clear=1 '\001') at ../src/bin/termptyops.c:150
#6  0x00005555555aabb4 in _handle_cursor_control
    (ty=0x555556025b90, cc=0x7fffffff6a6c L"\n", ' ' <repeats 45 times>, "\r\n", ' ' <repeats 45 times>, "\r\n", ' ' <repeats 45 times>, "\r\n", ' ' <repeats 45 times>, "\r\n", ' ' <repeats 11 times>...) at ../src/bin/termptyesc.c:211
#7  0x00005555555b6dd9 in termpty_handle_seq
    (ty=0x555556025b90, c=0x7fffffff6a6c L"\n", ' ' <repeats 45 times>, "\r\n", ' ' <repeats 45 times>, "\r\n", ' ' <repeats 45 times>, "\r\n", ' ' <repeats 45 times>, "\r\n", ' ' <repeats 11 times>..., ce=0x7fffffff78e8 L"")
    at ../src/bin/termptyesc.c:3865
#8  0x00005555555a430d in termpty_handle_buf
    (ty=0x555556025b90, codepoints=0x7fffffff66d0 L"\033[?25l\033[1 q\033[1 q\033(B\033[m\033[38;5;223m\033[48;5;235m", ' ' <repeats 45 times>, "\r\n", ' ' <repeats 45 times>, "\r\n", ' ' <repeats 45 times>, "\r\n", ' ' <repeats 15 times>..., len=1158) at ../src/bin/termpty.c:176
#9  0x00005555555a4a7d in _fd_read_do (ty=0x555556025b90, fd_handler=0x555555611390, false_on_empty=0 '\000') at ../src/bin/termpty.c:334
#10 0x00005555555a4b1b in _cb_fd_read (data=0x555556025b90, fd_handler=0x555555611390) at ../src/bin/termpty.c:361
#11 0x00007ffff71fdcc4 in _ecore_call_fd_cb (func=0x5555555a4af3 <_cb_fd_read>, data=0x555556025b90, fd_handler=0x555555611390) at ../src/lib/ecore/ecore_private.h:520
#12 0x00007ffff7200eb1 in _ecore_main_fd_handlers_call (obj=0x4000000000e8, pd=0x55555560b6b0) at ../src/lib/ecore/ecore_main.c:2080
#13 0x00007ffff7201708 in _ecore_main_loop_iterate_internal (obj=0x4000000000e8, pd=0x55555560b6b0, once_only=0) at ../src/lib/ecore/ecore_main.c:2453
#14 0x00007ffff71fec5f in _ecore_main_loop_begin (obj=0x4000000000e8, pd=0x55555560b6b0) at ../src/lib/ecore/ecore_main.c:1191
#15 0x00007ffff720681f in _efl_loop_begin (obj=0x4000000000e8, pd=0x55555560b6b0) at ../src/lib/ecore/efl_loop.c:83
#16 0x00007ffff72090d4 in efl_loop_begin (obj=0x4000000000e8) at src/lib/ecore/efl_loop.eo.c:28
#17 0x00007ffff71fedd4 in ecore_main_loop_begin () at ../src/lib/ecore/ecore_main.c:1274
#18 0x00007ffff765a84c in elm_run () at ../src/lib/elementary/elm_main.c:1333
#19 0x00005555555765ec in elm_main (argc=1, argv=0x7fffffffdc98) at ../src/bin/main.c:971
#20 0x000055555557670a in main (argc=1, argv=0x7fffffffdc98) at ../src/bin/main.c:1009

link is invalid memory, because:

(gdb) p ty->hl.links
$12 = (Term_Link *) 0x0

Related Objects

jayji created this task.Jan 3 2019, 12:27 PM

I can't reproduce your issue :'(

billiob added a comment.EditedJan 3 2019, 12:36 PM

Could you please reproduce the issue under valgrind?

jayji added a comment.Jan 3 2019, 12:56 PM

Here is valgrind's log:

Funny, I cannot reproduce with nano/vim. But systematically with neovim (nvim -u NONE).

You just run the command (so no file opened) and resize down?

I've pushed a commit. Should probably change nothing.

jayji added a comment.Jan 3 2019, 1:47 PM

yes. I made sure with -u NONE that it was not a fancy plugin that caused the problem. I'm using NVIM v0.3.1 by the way

Do you really manage to resize to (0,0) ?

jayji added a comment.Jan 3 2019, 1:51 PM

I can confirm it changes nothing ;)

Actually, it depends. Sometimes, I can go the to minimum possible, then resize up, down, ... etc. and it ends up crashing.
Sometimes, it crashes around 30/40 cols and 20/30 rows.

Ok, I managed to reproduce it on enlightenment (but not on i3…).

I'll look into it tomorrow.