Warnings are unrelated. Can you ssh into your computer from a different computer? If so, run gnome-shell from the ssh session with the -g flag:

 gnome-shell --replace -g
 (gdb) run
 <... reproduce crash ...>
 (gdb) bt

And attach the backtrace here.

Created attachment 156659 [details]
Backtrace

Here is the backtrace. This time it crashed while moving the pointer to the activities button.

you need to type "bt" when it crashes, to get the full backtrace of what it was doing when it crashed.

also, not sure if it's related, but:

        JS ERROR: !!!     stack = 'Error("0x2010 is not a valid value for flags GdkModifierType")@:0
    ("0x2010 is not a valid value for flags GdkModifierType")@gjs_throw:0
    @:0
    ([object Object])@/home/amrlima/gnome-shell/source/gnome-shell/js/ui/workspace.js:488

workspace.js:448 is:

        let [child, x, y, mask] = Gdk.Screen.get_default().get_root_window().get_pointer();

I don't think there's an equivalent in either gdk or clutter that doesn't include a mask value so we'll need a shell wrapper.

Created attachment 156691 [details]
Complete backtrace

Here goes the backtrace, this time (hopefully) complete. I noticed that I only managed to crash gnome-shell with openoffice running and I thing I started to notice the crashes while I was using eclipse...

Created attachment 157222 [details] [review]
Add shell_global_get_pointer(), fix warnings in overview with XKB

This fixes the warning I pointed out. I don't have any reason to believe
it also fixes the crash, though it's possible that the crash was caused
by some sort of "can't happen" state caused by one of these methods
throwing an error halfway though, in which case this patch would fix it

Review of attachment 157222 [details] [review]:

The get_pointer() changes look good. The has_pointer changes it's hard to tell, since we've at various times inserted workarounds for clutter not-repicking on scene graph changes. I don't see anything obviously wrong, so if it passes some testing - if the state of the window controls looks good after zooming, after dropping successfully, after drop snap-backs, then it's probably good. And simpler is better than undocumented or faultily documented workarounds that we no longer understand.

::: js/ui/workspace.js
@@ -306,3 @@
-        // better to have the label mysteriously missing than
-        // mysteriously present
-        this._havePointer = false;

By removing this, you've removed a workaround for the described symptoms - the reason for 'not cause a leave-event' is not the grab, but rather the lack of repicking on scene graph changes. The label is no longer shown/hidden on enter leave, but you should check if  you can get a stuck close button (if we hide the close button when dragging anyways, then it doesn't matter.)

@@ +426,2 @@
     show: function() {
+        if (this._windowClone.actor.has_pointer) {

This is subtly different from the previous code, because it's checking whether the clone had the point at last motion event, rather than now. So any intermediate scene changes (from animations or whatever) won't be taken into account.

Not sure if this matters - it's a pervasive problem in any Clutter program.

(In reply to comment #6)
> -        this._havePointer = false;
> 
> By removing this, you've removed a workaround for the described symptoms

No, it was dead code. All of the code that actually looked at the value of _havePointer got removed in some earlier rewrite, so we were just tracking it for no reason now.

committed, with the dead-code-removal part separate, and without the
has_pointer changes, which did break show-close-after-snapback.
("without the has_pointer changes" meaning I just made those parts use
global.get_pointer() instead of gdk_window_get_pointer(), and left the
picking in.)

oops, I shouldn't have marked this FIXED... but let's hope it did fix the bug and leave it that way. :) reopen it if it didn't