Bug 1590537

Have you restarted your session (Alt+F2 r <Enter>)? Or rather reboot to be sure?

I saw that too but after session restart it works fine.

OK it is back, seems vte is incredible slow in displaying prompt.

When this occurs, the folowing message is logged in /var/log/messages:

Jun 13 15:43:54 localhost journal: void vte_terminal_watch_child(VteTerminal*, GPid): assertion 'impl->m_pty != NULL' failed

Just to narrow things down a bit, what happens if you install the vte291-devel package and try the toy /usr/bin/vte-2.91 program? Does it give you working shell prompt?

Installed vte291-devel, tried some simple commands. Seems to be working well for me.

In my case it behaves randomly, so the same behaviour as the gnome-terminal

(In reply to Michal Odehnal from comment #6)
> Installed vte291-devel, tried some simple commands. Seems to be working well
> for me.

And as I thought it was working, few restarts later it is not working again. Few restarts later it is working again.

Still hard failure for me.

I installed vte291-devel (and all the other packages it depends on) and rebooted.


I'm also seeing the following in /var/log/messages: 

Jun 13 11:09:38 rhel-vm01 journal: void vte_terminal_watch_child(VteTerminal*, GPid): assertion 'impl->m_pty != NULL' failed

                                 -Lenny.

(In reply to Debarshi Ray from comment #5)
> Just to narrow things down a bit, what happens if you install the
> vte291-devel package and try the toy /usr/bin/vte-2.91 program? Does it give
> you working shell prompt?

Sorry, I missed the part about /usr/bin/vte-2.91

Indeed /usr/bin/vte-2.91 works and gets me a shell prompt.

I do get this message though:

(Terminal:3803): GLib-GIO-CRITICAL **: 11:44:33.549: g_dbus_proxy_new_sync: assertion 'G_IS_DBUS_CONNECTION (connection)' failed

                               -Lenny.

(In reply to Lenny Szubowicz from comment #10)
> (In reply to Debarshi Ray from comment #5)
> > Just to narrow things down a bit, what happens if you install the
> > vte291-devel package and try the toy /usr/bin/vte-2.91 program? Does it give
> > you working shell prompt?
> 
> Sorry, I missed the part about /usr/bin/vte-2.91
> 
> Indeed /usr/bin/vte-2.91 works and gets me a shell prompt.
> 
> I do get this message though:
> 
> (Terminal:3803): GLib-GIO-CRITICAL **: 11:44:33.549: g_dbus_proxy_new_sync:
> assertion 'G_IS_DBUS_CONNECTION (connection)' failed
> 
>                                -Lenny.

I also see the same intermittent behavior as reported in comment 7.

/usr/bin/vte-2.91 sometimes also ends up with a window with no shell prompt.
When that happens, I see the following:

Terminal:3330): Vte-CRITICAL **: 09:41:58.736: void vte_terminal_watch_child(VteTerminal*, GPid): assertion 'impl->m_pty != NULL' failed

                                 -Lenny.

Just a quick update.  I can reproduce it too, and I am looking into it.  It seems related to the gnome-pty-helper code, because it doesn't happen if you build without --enable-gnome-pty-helper.

(--enable-gnome-pty-helper needs to be explicitly passed because it's not there by default. That's why I didn't notice it when testing the rebased patches.  Sorry about that.)

For some reason, VteTerminal was getting a "hang up" (ie. G_IO_HUP) while polling the pseudo-terminal master device (ie. the end of the pseudo-terminal pipe / device pair that's in the UI process), and this was only happening when using gnome-pty-helper and vte_terminal_spawn_async. Not using gnome-pty-helper or using vte_terminal_spawn_sync would not cause this bug.

The move from vte_terminal_spawn_sync to vte_terminal_spawn_async happened between RHEL 7.4 and 7.6. So running gnome-terminal from RHEL < 7.6 with newer vte291 would not cause this bug.

The reason for this is that the asynchronous code path starts polling the pseudo-terminal master device a little too early in the sequence. When gnome-pty-helper is used, the helper is in charge of creating the pseudo-terminal device pair, and it closes its copies of the file descriptors after sending them to the main UI process. I believe that polling the master device immediately after receiving it from the helper can leave it vulnerable to a race condition where the helper closes its copies after the poll has been initiated.

Instead, we should start polling after the child process has been forked and exec-ed. Since the child would keep its copy of the pseudo-terminal slave device open, having the helper close its copy after that wouldn't matter. This is also what the synchronous code path does, which we have been using without any problem so far.

Scratch build:
https://brewweb.engineering.redhat.com/brew/taskinfo?taskID=16831663

Building vte291-0.52.2-2.el7:
https://brewweb.engineering.redhat.com/brew/taskinfo?taskID=16831853

(In reply to Debarshi Ray from comment #15)
> Building vte291-0.52.2-2.el7:
> https://brewweb.engineering.redhat.com/brew/taskinfo?taskID=16831853

quickly tested in wm, works fine for me, thanks rishi

Works for me as well. Thanks! -Lenny.

gnome-terminal-3.28.2-2.el7.x86_64
vte291-0.52.2-2.el7.x86_64

terminal works fine for long time, moving to VERIFIED

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHSA-2018:3140