@jkardatzke could you take a look at this?

I can't get this to reproduce in M72 on Pixelbook, must have been fixed since then.

If anybody can reproduce this on M72 on dev channel, please reply and we will re-open this bug.

I just hit this with Android Studio (at least it looks like the same issue). The mouse cursor is moving, but it's got the hand icon but nothing else is responsive. Happened by doing Help->Find Action. Then I entered 'resource file' and then I clicked on the result it hung up like this.

After reproducing it...the CPU usage of crosvm is pegged at 300% and chrome at 100%.  messages just complains about the browser hang, but in the UI log we have this:

[16663:16663:1126/164702.196639:ERROR:gles2_cmd_decoder.cc(17747)] [.BrowserCompositor-0x1c9eafd20000]GL ERROR :GL_INVALID_OPERATION : glCreateAndConsumeTextureCHROMIUM: invalid mailbox name
[16663:16663:1126/164702.197028:ERROR:gles2_cmd_decoder.cc(10302)] [.BrowserCompositor-0x1c9eafd20000]RENDER WARNING: texture bound to texture unit 0 is not renderable. It maybe non-power-of-2 and have incompatible texture filtering.

crosvm CPU usage did settle down after a few minutes...but Chrome CPU usage stays pegged.  It's not the GPU process that's using all the CPU, it's got this command line:

chronos  16521 33.1  1.7 784448 285256 ?       R<sl 16:29   8:01 /opt/google/chrome/chrome --ppapi-flash-path=/opt/google/chrome/pepper/libpepflashplayer.so --ppapi-flash-version=31.0.0.153 --ui-prioritize-in-gpu-process --use-gl=egl --enable-native-gpu-memory-buffers --enable-webgl-image-chromium --enable-features=Pepper3DImageChromium,PointerEvent,MachineLearningService,ChromeOSAssistant,EnableBackgroundBlur,Crostini,ExperimentalCrostiniUI --gpu-sandbox-failures-fatal=yes --enable-logging --log-level=1 --use-cras --enable-wayland-server --user-data-dir=/home/chronos --system-developer-mode --login-profile=user --has-chromeos-keyboard --enable-touchview --guest-wallpaper-large=/usr/share/chromeos-assets/wallpaper/guest_large.jpg --guest-wallpaper-small=/usr/share/chromeos-assets/wallpaper/guest_small.jpg --child-wallpaper-large=/usr/share/chromeos-assets/wallpaper/child_large.jpg --child-wallpaper-small=/usr/share/chromeos-assets/wallpaper/child_small.jpg --default-wallpaper-large=/usr/share/chromeos-assets/wallpaper/oem_large.jpg --default-wallpaper-small=/usr/share/chromeos-assets/wallpaper/oem_small.jpg --default-wallpaper-is-oem --arc-availability=officially-supported --enable-arc-oobe-optin --enable-arc-oobe-optin-no-skip --enterprise-enrollment-initial-modulus=15 --enterprise-enrollment-modulus-limit=19 --login-manager --vmodule=*arc/*=1,nss_cert_database_chromeos=1,*/assistant/*=1,*chromeos/login/*=1,auto_enrollment_controller=1,*/ui/ozone/*=1,*/ui/display/manager/chromeos/*=1,*night_light*=1,update_engine=1,component_updater_service=1,power_button_observer=2,webui_login_view=2,lock_state_controller=2,webui_screen_locker=2,screen_locker=2 --enable-features=Pepper3DImageChromium,PointerEvent,MachineLearningService,ChromeOSAssistant,EnableBackgroundBlur,Crostini,ExperimentalCrostiniUI

and interestingly enough...after a few more minutes the screen dimmed and then went black like it was going into the screensaver.

Reproduced it again and got a different kind of crash: 

tcmalloc: large alloc 1073741824 bytes == 0x12767f305000 @  0x58bf17140d0b 0x58bf16f7a090 0x58bf17028300 0x58bf1702802e 0x58bf172ee9c6 0x58bf1e61382c 0x58bf1b83e078 0x58bf1e6101e2 0x58bf1b067eae 0x58bf1b0677ea 0x58bf1e485416 0x58bf1e485a71 0x58bf1c7c7e46 0x58bf1b06aba3 0x58bf17b109c6 0x58bf17b10aad 0x58bf1b05b6c2 0x58bf1b2823fa 0x58bf17028d25 0x58bf1a19cfe7 0x58bf1a19d976 0x58bf17028511 0x58bf1a1c0364 0x58bf19d41420 0x58bf1800aae0 0x58bf1800e532 0x58bf18004236 0x58bf19d2fefb 0x58bf19d37b5a 0x58bf17133c7f 0x7eb9392cfa94
[23274:23274:1126/165933.892950:FATAL:memory_linux.cc(42)] Out of memory.

Chrome then just completely crashed and restarted rather than hanging.  Did the same repro steps again and that also happened...not entirely sure now if it's the same bug as the original one...so I'll open a new one for this.

Opened  crbug.com/908680  for the reproducible case I found in Android...in case it's not the same thing as this one.

 Issue 908680  has been merged into this issue.

The following revision refers to this bug:
  https://chromium.googlesource.com/chromiumos/platform2/+/267a68482a57fe2244f79bf068c33cdddfd02951

commit 267a68482a57fe2244f79bf068c33cdddfd02951
Author: Jeffrey Kardatzke <jkardatzke@google.com>
Date: Thu Nov 29 20:11:01 2018

vm_tools: sommelier: Do not use a window as a parent for itself

This fixes a crash where a floating window would end up setting itself
as its parent in a zxdg_toplevel_v6_set_parent call. When searching for
a window to use as a parent, it wasn't checking if it was selecting
itself.

BUG= chromium:907868 
TEST=Verified Android studio no longer crashes with test case

Change-Id: I0c24a19cc7a7d9912ae6df97819387a821a01f96
Reviewed-on: https://chromium-review.googlesource.com/1354183
Commit-Ready: Jeffrey Kardatzke <jkardatzke@google.com>
Tested-by: Jeffrey Kardatzke <jkardatzke@google.com>
Reviewed-by: David Reveman <reveman@chromium.org>

[modify] https://crrev.com/267a68482a57fe2244f79bf068c33cdddfd02951/vm_tools/sommelier/sommelier.c

Nice. I am not so familiar with process, in what version would I normally expect this fix to go trough?

This should be in M72; so if you go onto the dev channel you should see it once we push an updated VM image (I'll ask them to do one soon).  I was not able to replicate the problem in VSCode myself...but based on what I fixed to correct the problem in Android Studio, it's very likely this will fix that problem as well.

Nice job Jeffrey! Impressive response time. 

Okay, as soon as I know of the updated VM image, I will test the behaviour on VSCode in dev and report.