Just had that happening again. Happens when I try to copy-and-paste stuff from firefox to terminal (urls to wget).

gtk3-3.22.15-2.fc25.x86_64
gtk3-3.22.15-2.fc25.i686
gnome-terminal-3.22.1-5.fc25.x86_64

Every time it froze, it was when I was using the right-click context menu to paste, and it is often half-drawn while gnome-terminal is stuck.

This looks a lot like a fair number of already reported problems - with patches - reported elsewhere about context menus or half-drawn menus receiving events:

http://trac.wxwidgets.org/ticket/15221
https://bugzilla.redhat.com/show_bug.cgi?id=856682
https://github.com/mate-desktop/mate-utils/issues/136

I am getting sick of gnome-terminal locking up, so after it locked up twice in a day, I looked at the source, and created the patch myself. and is using it now:

===
diff --git a/src/terminal-screen.c b/src/terminal-screen.c
index 017a38b..3376c63 100644
--- a/src/terminal-screen.c
+++ b/src/terminal-screen.c
@@ -1607,7 +1607,15 @@ terminal_screen_button_press (GtkWidget      *widget,
 
   /* default behavior is to let the terminal widget deal with it */
   if (button_press_event)
-    return button_press_event (widget, event);
+    {
+      if (gtk_widget_get_realized(widget))
+        return button_press_event (widget, event);
+
+      /* ungrab and drop the event from unrealized widget */
+      gtk_widget_hide(widget);
+      gtk_grab_remove(widget);
+      return TRUE;
+    }
 
   return FALSE;
 }
===


I think that the worst this patch does is waste some CPU cycles. If it does what I think it should do, when it detects event going to half-drawn widget, it would automatically hide the half-drawn menu widget and  ungrab focus from it. This is inspired mainly by http://trac.wxwidgets.org/ticket/15221 and also drawn on the discussions in  https://github.com/mate-desktop/mate-utils/issues/136 .

I am going to use it until it breaks, or until a proper fix comes out.

So far my patch does not seems to have any bad side effects.

My lock-up tends to happen when I use the 'right-click, hold and drag over to the "paste" entry in the popup menu' to do cut from firefox to paste into the terminal. The popup menu also tend to be half-drawn (i.e. it shows a
rectangular shape without any inside entries). So this seems to correspond closely with what those other report describes.

I hope the patch works, and perhaps some of the gnome people can comment
on it or on a better way of doing it.

The patch is wrong. This is the GtkWidget::button_press_event handler. If it gets called, that means that the widget IS realized for events; and the code in terminal_screen_button_press before this upcall shouldn't cause the terminal to be unrealized. If it does get unrealized, you need to find out where (get a backtrace on vte_terminal_unrealize(). 

> _gtk_widget_captured_event: assertion 'WIDGET_REALIZED_FOR_EVENT (widget, event)' failed

You should get a backtrace from this first warning, and find out which widget is getting it exactly.

No, I do not get any backtraces. All I get is that the whole screen is unresponive to mouse clicks, though it still updates (my network monitor still works), and the mouse cursor still moves. If I ctrl-alt-fN, I can see pils and piles of 

===
gnome-terminal-[23244]: _gtk_widget_captured_event: assertion 'WIDGET_REALIZED_FOR_EVENT (widget, event)' failed.
===

Actually looking at the logs, it always started with a single line

===
gdk_seat_grab: assertion 'GDK_IS_WINDOW (window)' failed!
===

I just haven't noticed due to the flood of 'WIDGET_REALIZED_FOR_EVENT (widget, event)' failed.

gdb on the hung gnome-terminal-server does not help:
----
(gdb) bt
#0  0x00007f2cf08e501d in poll () at /lib64/libc.so.6
#1  0x00007f2cf17ed166 in g_main_context_iterate.isra () at /lib64/libglib-2.0.so.0
#2  0x00007f2cf17ed27c in g_main_context_iteration () at /lib64/libglib-2.0.so.0
#3  0x00007f2cf1da5b9d in g_application_run () at /lib64/libgio-2.0.so.0
#4  0x0000561515d9050e in main (argc=<optimized out>, argv=<optimized out>) at server.c:180
(gdb) q
(gdb) frame 4
#4  0x0000561515d9050e in main (argc=<optimized out>, argv=<optimized out>) at server.c:180
180       return g_application_run (app, 0, NULL);
(gdb) bt
#0  0x00007f2cf08e501d in poll () at /lib64/libc.so.6
#1  0x00007f2cf17ed166 in g_main_context_iterate.isra () at /lib64/libglib-2.0.so.0
#2  0x00007f2cf17ed27c in g_main_context_iteration () at /lib64/libglib-2.0.so.0
#3  0x00007f2cf1da5b9d in g_application_run () at /lib64/libgio-2.0.so.0
#4  0x0000561515d9050e in main (argc=<optimized out>, argv=<optimized out>) at server.c:180
(gdb) frame 0
#0  0x00007f2cf08e501d in poll () from /lib64/libc.so.6
(gdb) bt
#0  0x00007f2cf08e501d in poll () at /lib64/libc.so.6
#1  0x00007f2cf17ed166 in g_main_context_iterate.isra () at /lib64/libglib-2.0.so.0
#2  0x00007f2cf17ed27c in g_main_context_iteration () at /lib64/libglib-2.0.so.0
#3  0x00007f2cf1da5b9d in g_application_run () at /lib64/libgio-2.0.so.0
#4  0x0000561515d9050e in main (argc=<optimized out>, argv=<optimized out>) at server.c:180
(gdb) q
A debugging session is active.

(gdb) info threads
  Id   Target Id         Frame
* 1    Thread 0x7f2cf4590680 (LWP 23244) "gnome-terminal-" 0x00007f2cf08e501d in poll () from /lib64/libc.so.6
  2    Thread 0x7f2ce0f14700 (LWP 23245) "gmain" 0x00007f2cf08e501d in poll () from /lib64/libc.so.6
  3    Thread 0x7f2cdbfff700 (LWP 23246) "gdbus" 0x00007f2cf08e501d in poll () from /lib64/libc.so.6
  4    Thread 0x7f2cdb7fe700 (LWP 23247) "dconf worker" 0x00007f2cf08e501d in poll () from /lib64/libc.so.6
(gdb) thread 2
[Switching to thread 2 (Thread 0x7f2ce0f14700 (LWP 23245))]
#0  0x00007f2cf08e501d in poll () from /lib64/libc.so.6
(gdb) bt
#0  0x00007f2cf08e501d in poll () at /lib64/libc.so.6
#1  0x00007f2cf17ed166 in g_main_context_iterate.isra () at /lib64/libglib-2.0.so.0
#2  0x00007f2cf17ed27c in g_main_context_iteration () at /lib64/libglib-2.0.so.0
#3  0x00007f2cf17ed2c1 in glib_worker_main () at /lib64/libglib-2.0.so.0
#4  0x00007f2cf1814b93 in g_thread_proxy () at /lib64/libglib-2.0.so.0
#5  0x00007f2cf0bb66ca in start_thread () at /lib64/libpthread.so.0
#6  0x00007f2cf08f0f7f in clone () at /lib64/libc.so.6
(gdb) thread 3
[Switching to thread 3 (Thread 0x7f2cdbfff700 (LWP 23246))]
#0  0x00007f2cf08e501d in poll () from /lib64/libc.so.6
(gdb) bt
#0  0x00007f2cf08e501d in poll () at /lib64/libc.so.6
#1  0x00007f2cf17ed166 in g_main_context_iterate.isra () at /lib64/libglib-2.0.so.0
#2  0x00007f2cf17ed4f2 in g_main_loop_run () at /lib64/libglib-2.0.so.0
#3  0x00007f2cf1dd1a76 in gdbus_shared_thread_func () at /lib64/libgio-2.0.so.0
#4  0x00007f2cf1814b93 in g_thread_proxy () at /lib64/libglib-2.0.so.0
#5  0x00007f2cf0bb66ca in start_thread () at /lib64/libpthread.so.0
#6  0x00007f2cf08f0f7f in clone () at /lib64/libc.so.6
(gdb) thread 4
[Switching to thread 4 (Thread 0x7f2cdb7fe700 (LWP 23247))]
#0  0x00007f2cf08e501d in poll () from /lib64/libc.so.6
(gdb) bt
#0  0x00007f2cf08e501d in poll () at /lib64/libc.so.6
#1  0x00007f2cf17ed166 in g_main_context_iterate.isra () at /lib64/libglib-2.0.so.0
#2  0x00007f2cf17ed27c in g_main_context_iteration () at /lib64/libglib-2.0.so.0
#3  0x00007f2ce0309fad in dconf_gdbus_worker_thread () at /usr/lib64/gio/modules/libdconfsettings.so
#4  0x00007f2cf1814b93 in g_thread_proxy () at /lib64/libglib-2.0.so.0
#5  0x00007f2cf0bb66ca in start_thread () at /lib64/libpthread.so.0
#6  0x00007f2cf08f0f7f in clone () at /lib64/libc.so.6
(gdb) q
---

where is vte_terminal_unrealize() ? Not in gnome-terminal...

Anyway, when it hangs, I can use gdb to get into the process in a vt, but I don't know what/where to look.

vte_terminal_unrealize is in vte (vte291 package) so you need to install its debug symbols. Would also be good to install debug symbols for glib, gtk+.

You should attach gdb before this happens, set a breakpoint for that "gdk_seat_grab: assertion 'GDK_IS_WINDOW (window)' failed!" assertion, trigger the bug and get a backtrace when it happens.

Created attachment 1285620 [details]
gdb log of backtrace of the gdb_seat_grab assertion

# rpm -qf /usr/src/debug/*
glib2-debuginfo-2.50.3-1.fc25.x86_64
gnome-terminal-debuginfo-3.22.1-5p.fc25.x86_64
gtk3-debuginfo-3.22.15-2.fc25.x86_64
mono-debuginfo-4.8.0-6p.fc25.x86_64
glib2-debuginfo-2.50.3-1.fc25.x86_64
vte291-debuginfo-0.46.2-1.fc25.x86_64

It looks like it is a gtk bug. it is seat_grab'bing on a null :

===
...
#2  0x00007f068ac0a459 in gdk_seat_grab (seat=0x561764497280 [GdkSeatDefault], window=0x0, capabilities=GDK_SEAT_CAPABILITY_ALL, owner_events=1
, cursor=0x0, event=0x0, prepare_func=0x0, prepare_func_data=0x0) at gdkseat.c:302
#3  0x00007f068b0f634b in popup_grab_on_window (window=0x0, pointer=pointer@entry=0x5617644a9810 [GdkX11DeviceXI2]) at gtkmenu.c:1771
...
====

I'll have a look and see if I understand what's going on, but please feel free to beat me to it...

I am thinking of putting a check for null in popup_grab_on_window(), but possibly further up...

Around frame 4 also seems to be spectaculaly wrong:

====
#4  0x00007f068b0fa7df in gtk_menu_popup_internal (menu=0x5617647bc2b0 [GtkMenu], device=<optimized out>, parent_menu_shell=<optimized out>, pa
rent_menu_item=<optimized out>, func=<optimized out>, data=<optimized out>, destroy=<optimized out>, button=<optimized out>, activate_time=<opt
imized out>) at gtkmenu.c:1992
====

popup_grab_on_window() is doing a blind gdk_seat_grab() with window=0 without checking;

and in gtk_menu_popup_internal(), near line 1992:

===
  if (xgrab_shell == widget)
    popup_grab_on_window (gtk_widget_get_window (widget), pointer); /* Should always succeed */

  gtk_grab_add (GTK_WIDGET (menu));
====

I think that gtk_grab_add() is what causes the pile of assertions later.

shouldn't it do this instead?
===
if (gtk_widget_get_realized (memu))
    gtk_grab_add (GTK_WIDGET (menu));
====

just have the problem under fc26 also. (upgraded ahead of GA).

gtk3-3.22.16-1.fc26.x86_64
gtk3-3.22.16-1.fc26.i686
gnome-terminal-3.24.2-1.fc26.x86_64
gnome-session-3.24.1-2.fc26.x86_64

Looks like a problem in gtk+, not gnome-terminal.

Someone please report this upstream against gtk+: https://bugzilla.gnome.org/enter_bug.cgi?product=gtk%2B

Filed upstream as https://bugzilla.gnome.org/show_bug.cgi?id=786683

This message is a reminder that Fedora 26 is nearing its end of life.
Approximately 4 (four) weeks from now Fedora will stop maintaining
and issuing updates for Fedora 26. It is Fedora's policy to close all
bug reports from releases that are no longer maintained. At that time
this bug will be closed as EOL if it remains open with a Fedora  'version'
of '26'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version'
to a later Fedora version.

Thank you for reporting this issue and we are sorry that we were not
able to fix it before Fedora 26 is end of life. If you would still like
to see this bug fixed and are able to reproduce it against a later version
of Fedora, you are encouraged  change the 'version' to a later Fedora
version prior this bug is closed as described in the policy above.

Although we aim to fix as many bugs as possible during every release's
lifetime, sometimes those efforts are overtaken by events. Often a
more recent Fedora release includes newer upstream software that fixes
bugs or makes them obsolete.

I think I have seen it on fc27.

This message is a reminder that Fedora 27 is nearing its end of life.
On 2018-Nov-30  Fedora will stop maintaining and issuing updates for
Fedora 27. It is Fedora's policy to close all bug reports from releases
that are no longer maintained. At that time this bug will be closed as
EOL if it remains open with a Fedora  'version' of '27'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora 27 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora, you are encouraged  change the 'version' to a later Fedora 
version prior this bug is closed as described in the policy above.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

Fedora 27 changed to end-of-life (EOL) status on 2018-11-30. Fedora 27 is
no longer maintained, which means that it will not receive any further
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of
Fedora please feel free to reopen this bug against that version. If you
are unable to reopen this bug, please file a new report against the
current release. If you experience problems, please add a comment to this
bug.

Thank you for reporting this bug and we are sorry it could not be fixed.