kak -c <pid> is supposed to start kakoune, joining it to an existing session, identified by <pid>. If this is run with xfce4-terminal -x, it doesn't work, exiting immediately. So, to reproduce: 1. In one window, open any non-empty text file with kak. (The non-empty test file isn't necessary. It just makes testing easier.) Note the PID, displayed in the bottom right. 2. In another window, run kak -c <pid> from an interactive shell. This should work and you'll see the same text file that is already open. Any edits made in one will be immediately visible in the other. 3. Close this second kak instance and open it again, this time with xfce4-terminal: xfce4-terminal -x kak -c <pid>. Expected results: You see a new window with the same text file open. Actual results: The new window closes immediately. Further diagnosis: If instead of the command in step 3 above, you run xfce4-terminal -x sh -c 'sleep 1; kak -c <pid>', this will work. Therefore it is some kind of race condition. If I add the -H switch, I get segfaults sometimes and warnings all the time. This is the warning: (xfce4-terminal:118602): VTE-WARNING **: 19:27:54.168: Error reading from child: Bad file descriptor. The segfaults happen in 3 different places, or not at all, depending on luck. These are the backtraces: [New Thread 0x7ffff2e8e700 (LWP 118356)] (xfce4-terminal:118321): VTE-WARNING **: 18:18:51.751: Error reading from child: Bad file descriptor. [Thread 0x7ffff2e8e700 (LWP 118356) exited] [Detaching after fork from child process 118370] [New Thread 0x7ffff2e8e700 (LWP 118371)] (xfce4-terminal:118321): GLib-GObject-WARNING **: 18:19:00.480: invalid uninstantiatable type '(null)' in cast to 'GObject' (xfce4-terminal:118321): GLib-GObject-CRITICAL **: 18:19:00.480: g_object_freeze_notify: assertion 'G_IS_OBJECT (object)' failed (xfce4-terminal:118321): GLib-GObject-CRITICAL **: 18:19:00.480: g_object_ref: assertion 'G_IS_OBJECT (object)' failed (xfce4-terminal:118321): GLib-GObject-CRITICAL **: 18:19:00.480: g_object_thaw_notify: assertion 'G_IS_OBJECT (object)' failed Thread 1 "xfce4-terminal" received signal SIGSEGV, Segmentation fault. 0x00007ffff7e2f9b9 in vte::terminal::Terminal::emit_eof (this=<optimized out>) at ../vte/src/vte.cc:782 782 ../vte/src/vte.cc: No such file or directory. (gdb) bt #0 0x00007ffff7e2f9b9 in vte::terminal::Terminal::emit_eof() (this=<optimized out>) at ../vte/src/vte.cc:782 #1 0x00007ffff7e2f9b9 in vte::terminal::emit_eof_idle_cb(VteTerminal*) (terminal=0x0) at ../vte/src/vte.cc:768 #2 0x00007ffff71722cf in g_main_context_dispatch () at /usr/lib/libglib-2.0.so.0 #3 0x00007ffff7174211 in () at /usr/lib/libglib-2.0.so.0 #4 0x00007ffff7175123 in g_main_loop_run () at /usr/lib/libglib-2.0.so.0 #5 0x00007ffff797d62f in gtk_main () at /usr/lib/libgtk-3.so.0 #6 0x0000555555563478 in main (argc=<optimized out>, argv=<optimized out>) at main.c:352 (xfce4-terminal:118078): VTE-WARNING **: 18:16:49.780: Error reading from child: Bad file descriptor. [Thread 0x7ffff2e8e700 (LWP 118125) exited] [Thread 0x7ffff1245700 (LWP 118092) exited] [New Thread 0x7ffff1245700 (LWP 118140)] [Detaching after fork from child process 118141] [New Thread 0x7ffff2e8e700 (LWP 118142)] Thread 1 "xfce4-terminal" received signal SIGSEGV, Segmentation fault. 0x00007ffff7e29743 in std::__uniq_ptr_impl<vte::base::Chunk, vte::base::Chunk::Recycler>::_M_ptr (this=0x1010) at /usr/include/c++/9.2.0/bits/unique_ptr.h:352 352 get() const noexcept (gdb) bt #0 0x00007ffff7e29743 in std::__uniq_ptr_impl<vte::base::Chunk, vte::base::Chunk::Recycler>::_M_ptr() const (this=0x1010) at /usr/include/c++/9.2.0/bits/unique_ptr.h:352 #1 0x00007ffff7e29743 in std::unique_ptr<vte::base::Chunk, vte::base::Chunk::Recycler>::get() const (this=0x1010) at /usr/include/c++/9.2.0/bits/unique_ptr.h:353 #2 0x00007ffff7e29743 in vte::terminal::Terminal::pty_io_read(_GIOChannel*, GIOCondition) (this=0x555555d08450, channel=<optimized out>, condition=<optimized out>) at ../vte/src/vte.cc:4082 #3 0x00007ffff7e29974 in vte::terminal::io_read_cb(GIOChannel*, GIOCondition, vte::terminal::Terminal*) (channel=<optimized out>, condition=<optimized out>, that=<optimized out>) at ../vte/src/vte.cc:3339 #4 0x00007ffff71722cf in g_main_context_dispatch () at /usr/lib/libglib-2.0.so.0 #5 0x00007ffff7174211 in () at /usr/lib/libglib-2.0.so.0 #6 0x00007ffff7175123 in g_main_loop_run () at /usr/lib/libglib-2.0.so.0 #7 0x00007ffff797d62f in gtk_main () at /usr/lib/libgtk-3.so.0 #8 0x0000555555563478 in main (argc=<optimized out>, argv=<optimized out>) at main.c:352 (xfce4-terminal:117751): VTE-WARNING **: 18:13:13.440: Error reading from child: Bad file descriptor. [Thread 0x7ffff1245700 (LWP 117795) exited] [Thread 0x7ffff2e8e700 (LWP 117798) exited] [New Thread 0x7ffff2e8e700 (LWP 117880)] [Detaching after fork from child process 117881] [New Thread 0x7ffff1245700 (LWP 117882)] Thread 1 "xfce4-terminal" received signal SIGSEGV, Segmentation fault. 0x00007ffff7242e46 in g_type_check_instance_cast () from /usr/lib/libgobject-2.0.so.0 (gdb) bt #0 0x00007ffff7242e46 in g_type_check_instance_cast () at /usr/lib/libgobject-2.0.so.0 #1 0x00007ffff7e24ed8 in vte::terminal::Terminal::pty_channel_eof() (this=0x555555d02d90) at ../vte/src/vte.cc:3576 #2 0x00007ffff7e29692 in vte::terminal::Terminal::pty_io_read(_GIOChannel*, GIOCondition) (this=0x555555d02d90, channel=<optimized out>, condition=<optimized out>) at ../vte/src/vte.cc:4204 #3 0x00007ffff7e29974 in vte::terminal::io_read_cb(GIOChannel*, GIOCondition, vte::terminal::Terminal*) (channel=<optimized out>, condition=<optimized out>, that=<optimized out>) at ../vte/src/vte.cc:3339 #4 0x00007ffff71722cf in g_main_context_dispatch () at /usr/lib/libglib-2.0.so.0 #5 0x00007ffff7174211 in () at /usr/lib/libglib-2.0.so.0 #6 0x00007ffff7175123 in g_main_loop_run () at /usr/lib/libglib-2.0.so.0 #7 0x00007ffff797d62f in gtk_main () at /usr/lib/libgtk-3.so.0 #8 0x0000555555563478 in main (argc=<optimized out>, argv=<optimized out>) at main.c:352 So looks like it might be a VTE thing upstream.
Hi, thanks for the report! What version of vte are you using? I do not see any crashes or warnings with vte 0.59.1 here. However, what I do see is that 'kak -c <pid>' returns with error code 255 if run from xfce4-terminal or gnome-terminal with the "hold" option. This does seem to be a vte thing. Egmont, do you have any ideas?
What I get is the following error in the terminal with the staircase effect, as well as in an xmessage window (the two are slightly differnet, the difference is minimal, I'm just copy-pasting and reformatting from the terminal): assert failed: 'assert failed "m_window" at ncurses_ui.cc:505' pid: 1796 callstack: kak(_ZN7Kakoune9BacktraceC1Ev+0x18) [0x55fa4d4db308] kak(_ZN7Kakoune16on_assert_failedEPKc+0x3c) [0x55fa4d4daf6c] kak(_ZN7Kakoune9NCursesUI12check_resizeEb+0x42c) [0x55fa4d5cde4c] kak(_ZN7Kakoune9NCursesUIC1Ev+0x587) [0x55fa4d5d0b47] kak(_ZN7Kakoune7make_uiENS_6UITypeE+0x85) [0x55fa4d5b9345] kak(_ZN7Kakoune10run_clientENS_10StringViewES0_S0_NS_8OptionalINS_11BufferCoordEEENS_6UITypeEb+0x7a) [0x55fa4d5b979a] kak(main+0x1b91) [0x55fa4d4d8f51] /lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xf3) [0x7ff1640391e3] kak(_start+0x2a) [0x55fa4d4d968a] Same in xfce4-terminal and gnome-terminal. The terminal has already enabled mouse, plus it's probably ncurses that causes the staircase effect, so it's absolutely sure that kak starts up, it's just that something (but what??) is not ready yet. Same in gnome-terminal if the 'kak -c <pid>' command is specified in the profile's settings as custom command, rather than in the command line. It's a bit heuristic for me: Either starts up properly, or gives the error message above, roughly fifty-fifty. At this moment I have no idea what it could be. Most likely a race condition in VTE, but what the heck could it be that's not always ready? I don't know. It's a nasty heisenbug: if I run 'strace -o /tmp/kak kak -c <pid>' instead to see what kak does when it's successful vs. when it fails, it always starts up successfully. I guess I'll need to dive into kak's source...
(I've compiled the same version as shipped by my Ubuntu 19.10, namely kakoune 2019.01.20.) Whenever it works as expected, ioctl(..., TIOCGWINSZ, ...) on the controlling terminal (/dev/tty) gives 80x24 or whatever reasonable value. Whenever it crashes, this ioctl gives a 0x0, but apparently returns success because execution goes on to the aforementioned failing assertion a few lines below. This is at https://github.com/mawww/kakoune/blob/v2019.01.20/src/ncurses_ui.cc#L493.
A simpler reproducer is either of these two commands: xfce4-terminal -x sh -c 'stty size > /tmp/foo' gnome-terminal -- sh -c 'stty size > /tmp/foo' and then check this file, it varies between 24 80 and 0 0. My _guess_ at this point is that VTE needs a GTK UI update cycle (to be mapped, size-allocated, whatever) to set the kernel's belief about the terminal size. Maybe because it needs such a cycle to know it itself. Or something like this.
Let's continue upstream at https://gitlab.gnome.org/GNOME/vte/issues/188.
Thank you, Egmont! I'm closing this bug.
@etoombs What is your VTE version? I'm wondering if the VTE crash bits have been fixed, or it's another real issue that Igor and me couldn't yet reproduce.
(In reply to Egmont Koblinger from comment #7) > @etoombs What is your VTE version? > > I'm wondering if the VTE crash bits have been fixed, or it's another real > issue that Igor and me couldn't yet reproduce. >$ pacman -Qi xfce4-terminal vte3 xorg-server linux | egrep 'Name|Version' >Name : xfce4-terminal >Version : 0.8.8-2 >Name : vte3 >Version : 0.58.2-1 >Name : xorg-server >Version : 1.20.5-2 >Name : linux >Version : 5.3.6.arch1-1
etoombs, since you're on Arch, can you try the vte3-git AUR package? I'm using it on my Arch machine and don't see any crashes.
Yes, I can confim. No crashes. Still broken, but at least no crashes.
Christian refactored some PTY code on Oct 12. I assume the crash was fixed there.