Bug#909328: More information and new backtrace
Hi, I can also reproduce the problem under Wayland + gnome-shell (but not on X11). On Wayland the window is not forced to fit in the screen, on X11 it is (with gnome-shell). (I incorrectly thought I was testing with Wayland previously while I was actually on X11. I should've tried both, anyways, my bad.) The crash happens when the window size exceeds a constant somewhere slightly below 16384 pixels (about 100 pixels smaller or so) in either direction. Presence of the menu bar, tab bar also influence the number of maximum lines without crash, so it's the window size that matters, not the VTE widget size. - gnome-terminal-server requests some situation that gnome-shell could not > deliver, > therefore it should possibly avoid such a request. > Without having further studied what's exactly going on, I also assume it's something along these lines. We'd need to check if it's indeed gnome-terminal's responsibility to handle the error and try a smaller window size. Isn't it rather a bug somewhere in our underlying infrastructure: wayland, gnome-shell, gtk+ and friends? gnome-terminal, xfce4-terminal and roxterm (three native Wayland, VTE-based emulators that handle app-initiated resize) all crash with "Gdk-Message: 09:55:43.773: Error 71 (Protocol error) dispatching to Wayland display." - vim seems to have a problem to handle SIGHUPs while currently reacting to > user input. > Sending a SIGHUP while vim is idle does not produce a SIGSEGV. > Also I thought inside a signal handler should be done just the absolute > necessary, > at least stdio/printf or malloc is forbidden - does this apply to > sprintf too? > Sure, the less the signal handler does the better, to the extent that it could just flip a flag and do the rest from the app's main flow (check for the flag after the main pselect() which atomically blocks/unblocks the signals the app is interested in). I'm not sure about sprintf either. Vim is known not to handle correctly if two SIGWINCHes arrive quickly after each other. That is, something's not right with its main loop infrastructure. Knowing that, it's a bit less surprising that weird signal conditions can make it crash. cheers, egmont
Bug#909328: More information and new backtrace
Hello all, in my first attempt I assumed this happens with xorg. In this attempt I could reproduce the issue within a gnome wayland session inside a amd64 buster VM. As far as I see for both terminals there is just one process gnome-terminal-server - therefore if that fails both windows disappear. In "journalctl -f" appears following: gnome-shell[4936]: Could not import pending buffer: Failed to create texture 2d due to size/format constraints gnome-shell[4936]: WL: error in client communication (pid 5736) gnome-terminal-[5736]: Error 71 (Protokollfehler) dispatching to Wayland display. This I assume is kind of a "clean" shutdown of the gnome-terminal-server process. An attached debugger does not trap. Because of the terminal disasspearing the vim process receives now following signals: Program received signal SIGHUP, Hangup. Program received signal SIGCONT, Continued. Program received signal SIGSEGV, Segmentation fault. Program received signal SIGABRT, Aborted. Program received signal SIGSEGV, Segmentation fault. Program terminated with signal SIGSEGV, Segmentation fault. A core dump recorded by systemd-coredump shows just the last SIGSEGV. See attached file for the stacks on each signal. So I assume there are really two problems: - gnome-terminal-server requests some situation that gnome-shell could not deliver, therefore it should possibly avoid such a request. - vim seems to have a problem to handle SIGHUPs while currently reacting to user input. Sending a SIGHUP while vim is idle does not produce a SIGSEGV. Also I thought inside a signal handler should be done just the absolute necessary, at least stdio/printf or malloc is forbidden - does this apply to sprintf too? Kind regards, Bernhard apt update apt install mc htop weston systemd-coredump strace valgrind gdb debian-goodies lz4 dpkg-dev devscripts tmux vim gnome-session gnome-terminal systemctl start gdm3 mkdir vim/orig -p cdvim/orig apt source vim cd ../.. mkdir ncurses/orig -p cdncurses/orig apt source ncurses cd ../.. mkdir libc6/orig -p cdlibc6/orig apt source libc6 cd ../.. # login # open terminal # open second terminal root@debian:~# ps aux | grep -i gnome-term benutzer 5736 1.7 1.3 407636 42924 tty2 Sl+ 22:53 0:00 /usr/lib/gnome-terminal/gnome-terminal-server vim test.txt set lines=999 Sep 24 22:54:39 debian gnome-shell[4936]: Could not import pending buffer: Failed to create texture 2d due to size/format constraints Sep 24 22:54:39 debian gnome-shell[4936]: WL: error in client communication (pid 5736) Sep 24 22:54:39 debian gnome-terminal-[5736]: Error 71 (Protokollfehler) dispatching to Wayland display. Sep 24 22:54:39 debian systemd[1]: Started Process Core Dump (PID 5777/UID 0). Sep 24 22:54:39 debian systemd-coredump[5778]: Process 5776 (vim) of user 1000 dumped core. Stack trace of thread 5776: #0 0x7effd8d5a717 tcache_get (libc.so.6) #1 0x7effd8d45bbb __fopen_internal (libc.so.6) #2 0x56262a4b8c29 n/a (vim.basic) #3 0x56262a62cfec n/a (vim.basic) #4 0x56262a56964b n/a (vim.basic) #5 0x7effd8d0cfc0 __restore_rt (libc.so.6) #6 0x7effd8d0cf3b __GI_raise (libc.so.6) #7 0x7effd8d0e2f1 __GI_abort (libc.so.6) #8 0x7effd8d4f867 __libc_message (libc.so.6) #9 0x7effd8d55e0a malloc_printerr (libc.so.6) #10 0x7effd8d5636c munmap_chunk (libc.so.6) #11 0x7effd8d45ca2 __fopen_internal (libc.so.6) #12 0x56262a4b8c29 n/a (vim.basic) #13 0x56262a62cfec n/a (vim.basic) #14 0x7effd8d0cfc0 __restore_rt (libc.so.6) #15 0x7effd8d25356 _IO_vfprintf_internal (libc.so.6) #16 0x7effd8ddd94f ___vsprintf_chk (libc.so.6) cat /var/lib/systemd/coredump/core.vim.1000.64142658a3b9454598e120cd13728d3c.5776.153782247900.lz4 | unlz4 > /tmp/core.5776 root@debian:~# find-dbgsym-packages /tmp/core.5776 libacl1-dbgsym libattr1-dbgsym libgpm2-dbgsym libpcre3-dbg libselinux1-dbgsym libtinfo6-dbg vim-dbgsym apt install libacl1-dbgsym libattr1-dbgsym libgpm2-dbgsym libpcre3-dbg libselinux1-dbgsym libtinfo6-dbg
Bug#909328: More information and new backtrace
Hi Léon, It indeed looks like a gnome-terminal crash. If only vim crashed, you'd still have both of your terminal windows open. All your backtraces are about vim. Do you have a backtrace of gnome-terminal-server? That could help a lot. Without a backtrace, and without being able to reproduce, unfortunately it's pretty unlikely that I'll be able to find the problem. I'm honestly lost about the various contradicting vim backtraces. The one with SIGHUP, as you say, corresponds to the terminal disappearing, that's the expected behavior in vim if the terminal crashes. But at the other two occasions did vim really also segfault? (Now, it could be that vim doesn't always handle correctly the terminal disappearing, and instead of a clean SIGHUP exit it segfaults... who know.) It's a bit suspicious to me that two pieces of software segfault at the same time. Could it be a faulty hardware? Have you experienced any unusual behavior in other software? Is there anything suspicious in "dmesg" output? Could you please do the following for me: in gnome-terminal start "script -f" and inside that start "vim". Do the ":set lines=999". Does it crash? If it does, restart gnome-terminal and execute "cat typescript". Does it crash again? If so, could you please attach this typescript file? Thanks a lot, egmont
Bug#909328: More information and new backtrace
Hello, > 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. I typ them in interactively. Although if I put the command in my .vimrc the same crash occurs. > 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. I have a process called XWayland running so I suppose it's Wayland. > Does vim's startup always crash gnome-terminal for you? If not then > approximately how often? It's not Vim's startup that causes the crash. It's only when issuing the command ':set lines=999'. It does crash consistently, although I noticed if the terminal is already full screen the command is ignored so the terminals do not crash. Maybe that's the reason you can not reproduce it? > 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. > nowadays there are -dbg packages not very common. > Instead there is a different repository to deliver automatic -dbgsym packages. > e.g. "deb > http://debug.mirrors.debian.org/debian-debug/ > 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. I have done my best to collect the dbg packages. I included the new backtrace (it is called backtrace2.txt). It seems the symbols for the first few functions are not available but I do not know which debug packages are missing. > 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? Directly inside the terminal. Here you can see a screencast of me causing a crash: https://www.dropbox.com/s/h3bnsi4lbgymlk5/Screencast%20from%2009-23-2018%2004%3A35%3A13%20PM.webm?dl=0 > So what looks like the path like, at least how long is it? As you can see in the linked screencast I do not specify a filename. Although when I do, for example using 'vim test.txt' the problem persists. I have also tried to attach gdb debugger using another terminal program to the Vim executable. This results in the backtrace 'backtrace-vim.txt' which is also attached. I have found that my vim executable is a symbolic link to the vim.basic executable. This would mean the two backtraces contradict each other. The first, produced with 'coredumpctl gdb' talks about a segmentation fault. The backtrace produced by attaching gdb directly (backtrace-vim.txt) mentions a 'SIGHUP' signal, which makes sense since gnome-terminal does seem to crash. Also, I am not affected anymore by this problem, but of course other people might run into this so it's still worthwhile trying to find the root cause. Thanks again, Léon van Velzen PID: 11571 (vim) UID: 1000 (leonvv) GID: 1000 (leonvv) Signal: 11 (SEGV) Timestamp: Sun 2018-09-23 16:26:16 CEST (4min 22s ago) Command Line: vim Executable: /usr/bin/vim.basic Control Group: /user.slice/user-1000.slice/user@1000.service/gnome-terminal-server.service Unit: user@1000.service User Unit: gnome-terminal-server.service Slice: user-1000.slice Owner UID: 1000 (leonvv) Boot ID: 2f91eff7da0e4bc7b014ba9f2c5fe4b1 Machine ID: 95762e21d5dc42ee92e8868d27171676 Hostname: leonvv Storage: /var/lib/systemd/coredump/core.vim.1000.2f91eff7da0e4bc7b014ba9f2c5fe4b1.11571.153771277600.lz4 Message: Process 11571 (vim) of user 1000 dumped core. Stack trace of thread 11571: #0 0x7ffa1d340227 kill (libc.so.6) #1 0x55a5f9aa06fd may_core_dump (vim.basic) #2 0x55a5f9b62eec getout (vim.basic) #3 0x7ffa1d33ffc0 __restore_rt (libc.so.6) #4 0x7ffa1d41090d ___vsprintf_chk (libc.so.6) #5 0x7ffa1d41087a ___sprintf_chk (libc.so.6) #6 0x7ffa1db204a6 sprintf (libtinfo.so.6) #7 0x7ffa1db19889 _nc_setup_tinfo (libtinfo.so.6) #8 0x7ffa1db19bef _nc_setupterm (libtinfo.so.6) #9 0x7ffa1db1a0f3 tgetent_sp (libtinfo.so.6) #10 0x55a5f9b1e1be tgetent_error (vim.basic) #11 0x55a5f9b1e40b getlinecol (vim.basic) #12 0x00300010 n/a (n/a) #0
