<div>Hello,<br></div><div><br></div><blockquote><pre class="message">How do you exactly set the size from vim? Do you put these lines in vimrc,
or you type these commands interactively, etc., how exactly? I'm asking
because let's say whether the two dimensions are modified in a single step
or in two consecutive steps might make a difference.<br></pre></blockquote><div><br></div><div>I typ them in interactively. Although if I put the command in my .vimrc the same crash occurs.<br></div><div><br></div><blockquote><pre class="message">What's your display server (X vs. Wayland), what graphical desktop and
window manager do you use? I'm asking because potentially all of them
behaves somewhat differently.<br></pre></blockquote><div>I have a process called XWayland running so I suppose it's Wayland.<br></div><div><br></div><blockquote><pre class="message">Does vim's startup always crash gnome-terminal for you? If not then
approximately how often?<br></pre></blockquote><div>It's not Vim's startup that causes the crash. It's only when issuing the command ':set lines=999'. <br></div><div>It does crash consistently, although I noticed if the terminal is already full screen the command<br></div><div>is ignored so the terminals do not crash. Maybe that's the reason you can not reproduce it?<br></div><div><br></div><blockquote><pre class="message">A backtrace would indeed be great, I'd add to Bernhard's response that
libvte-2.91-0 should also be compiled with debug symbols, since the crash
is most likely inside vte.<br></pre></blockquote><div><br></div><blockquote><pre class="message">nowadays there are -dbg packages not very common.
Instead there is a different repository to deliver automatic -dbgsym packages.
e.g. "deb <a href="http://debug.mirrors.debian.org/debian-debug/">http://debug.mirrors.debian.org/debian-debug/</a> testing-debug main"
as described in the link in the previous mail.
From there a package like "vim-dbgsym_8.1.0320-1_amd64.deb should be installable.<br></pre></blockquote><div><br></div><div>I have done my best to collect the dbg packages. I included the new backtrace (it is called backtrace2.txt). It seems the symbols<br></div><div>for the first few functions are not available but I do not know which debug packages are missing.<br></div><div><br></div><blockquote><pre class="message">So from your backtrace.txt it looks more like vim is crashing as gnome-terminal.
How have you started vim? Something like from a file explorer and open in vim?
Or have you stared directly inside the terminal?
I do not see currently any connection between all gnome-terminals closing and one
vim instance changing its size. Probably you can give some more details how
this can be reporoduced?<br></pre></blockquote><div><br></div><div>Directly inside the terminal. Here you can see a screencast of me causing a crash: <a href="https://www.dropbox.com/s/h3bnsi4lbgymlk5/Screencast%20from%2009-23-2018%2004%3A35%3A13%20PM.webm?dl=0">https://www.dropbox.com/s/h3bnsi4lbgymlk5/Screencast%20from%2009-23-2018%2004%3A35%3A13%20PM.webm?dl=0</a><br></div><div><br></div><blockquote><pre class="message">So what looks like the path like, at least how long is it?<br></pre></blockquote><div>As you can see in the linked screencast I do not specify a filename. Although when I do, for example<br></div><div>using 'vim test.txt' the problem persists.<br></div><div><br></div><div>I have also tried to attach gdb debugger using another terminal program to the Vim executable. This<br></div><div>results in the backtrace 'backtrace-vim.txt' which is also attached. I have found that my vim executable<br></div><div>is a symbolic link to the vim.basic executable. This would mean the two backtraces contradict each other.<br></div><div>The first, produced with 'coredumpctl gdb' talks about a segmentation fault. The backtrace produced <br></div><div>by attaching gdb directly (backtrace-vim.txt) mentions a 'SIGHUP' signal, which makes sense since <br></div><div>gnome-terminal does seem to crash.<br></div><div><br></div><div>Also, I am not affected anymore by this problem, but of course other people might run into this so it's still<br></div><div>worthwhile trying to find the root cause.<br></div><div><br></div><div>Thanks again,<br></div><div>Léon van Velzen<br></div><div><br></div><div><br></div>