There's not too much to go on from the stack, though it's interesting that we're scheduling decoding inside a 'AsyncReadPixelsCompletedQuery' stack.

Could you try logging more with instructions at: https://www.chromium.org/developers/how-tos/debugging-gpu-related-code  i.e --enable-gpu-debugging --enable-gpu-service-logging (latter works in debug builds only).

Do you think you could bisect the issue?

Oh, and would be curious what the unhandled reset status at https://cs.chromium.org/chromium/src/gpu/command_buffer/service/gles2_cmd_decoder.cc?q=gles2_cmd_decoder.cc&sq=package:chromium&l=16452 is.

Which platform is that? --use-gl=egl is not a supported configuration on Linux.

Also, the DCHECK is that the driver is returning an invalid value (see https://www.khronos.org/registry/OpenGL/extensions/KHR/KHR_robustness.txt), so it sounds like your driver is having issues

Looks like caused by https://www.khronos.org/registry/OpenGL/extensions/NV/NV_robustness_video_memory_purge.txt

#define GL_PURGED_CONTEXT_RESET_NV        0x92BB

The driver status is 37563 (0x92BB), but I don't see that in glext.h, do you know what it means?
I just had an NVIDIA driver update, maybe that's problematic? But Kyle hit the same thing.

I'm not sure how much of the logs you want, --enable-gpu-debugging is very verbose:

[22014:22014:0102/133752.647670:ERROR:gles2_cmd_decoder.cc(5504)] [.DisplayCompositor-0x2a3ada5afa00]cmd: kDeleteTexturesImmediate
[22014:22014:0102/133752.647816:ERROR:gles2_cmd_decoder.cc(5504)] [.DisplayCompositor-0x2a3ada5afa00]cmd: kBindTexture
[22014:22014:0102/133752.647887:ERROR:gles2_cmd_decoder.cc(5504)] [.DisplayCompositor-0x2a3ada5afa00]cmd: kTexParameteri
[22014:22014:0102/133752.647960:ERROR:gles2_cmd_decoder.cc(5504)] [.DisplayCompositor-0x2a3ada5afa00]cmd: kTexParameteri
[22014:22014:0102/133752.648029:ERROR:gles2_cmd_decoder.cc(5504)] [.DisplayCompositor-0x2a3ada5afa00]cmd: kDeleteTexturesImmediate
[22014:22014:0102/133752.648131:ERROR:gles2_cmd_decoder.cc(5504)] [.DisplayCompositor-0x2a3ada5afa00]cmd: kDeleteTexturesImmediate
[22014:22014:0102/133752.648182:ERROR:gles2_cmd_decoder.cc(5504)] [.DisplayCompositor-0x2a3ada5afa00]cmd: kFinish
[22014:22014:0102/133752.832697:ERROR:gles2_cmd_decoder.cc(16433)] Onscreen context lost via ARB/EXT_robustness. Reset status = 0x92bb
[22014:22014:0102/133752.832734:FATAL:gles2_cmd_decoder.cc(16452)] Check failed: false. Unhandled driver status 37563

I can try to bisect and to build debug to try the other flag if you think that'd help.

Various Mus team members have told me to use --use-gl=egl for linux-desktop Chrome OS builds when running with --mus.
When I don't supply --use-gl=egl I get similar errors and sometimes it crashes my Linux window manager...

Ah, I missed your earlier comment, does that shed some light on what's happening?

It's odd, because we never specify (EGL|GLX)_GENERATE_RESET_ON_VIDEO_MEMORY_PURGE_NV on context creation, so the driver should not be emitting this error code. Sounds like a driver bug.

We could explicitly enable it when the extension is present, and treat GL_PURGED_CONTEXT_RESET_NV just like GL_INNOCENT_CONTEXT_RESET_ARB.

But either way, the driver loses the context, nothing much we can do about that...


What does ctrl-shift-D do? Is it trying to change screen resolution and things?

The driver update is likely what made this happen suddenly.

ctrl-shift-D toggles the presence of a second display.

Should I try reinstalling my driver or loading a newer/older one?
I'm not actually sure how to do this on Linux/Goobuntu, I could try this:
http://www.linuxandubuntu.com/home/how-to-install-latest-nvidia-drivers-in-linux

How are driver bugs like this generally handled? --mus no longer implies --viz, so how come we only hit this with --mus and not classic chromeos?

I have no idea what --mus does at this point so I'm not sure why it affects one and not the other.

As to how we generally handle this bug: this is linux on a non-standard config, so we generally ignore. If it does affect the product, we either blacklist altogether, or if it affects a large population we try to find a workaround to the extent that it makes sense.
Losing contexts is not the end of the world, we generally handle this pretty well. In this case, because the driver reports a value that it shouldn't we go through a NOTREACHED() path, which asserts in debug, but goes through in release. In practice I believe we would ignore the lost context, which sounds like we would end up in a bad state (i.e. not recover), so we can fix that (as suggested in #8).

I have no idea what causes the lost context in the first place though - here's what the documentation says:

    The NVIDIA OpenGL driver architecture on Linux has a limitation:
    resources located in video memory are not persistent across certain
    events. VT switches, suspend/resume events, and mode switching
    events may erase the contents of video memory. Any resource that
    is located exclusively in video memory, such as framebuffer objects
    (FBOs), will be lost. As the OpenGL specification makes no mention
    of events where the video memory is allowed to be cleared, the
    driver attempts to hide this fact from the application, but cannot
    do it for all resources.

If you're doing modesetting on ctrl-shift-D (still not sure I understand what "toggles the presence of a second display" means when running on top of X11, but if this is something that crashes the WM, it sounds like it's doing much more than just creating/destroying X windows), then I guess that's why, and there's probably nothing we can do about it.

My WM just crashed again using ctrl-shift-j, is there some logging I can provide?
ctrl-shift-D makes a new X window that ash uses as a second display.

Kyle found that mus [sometimes?] destroys the XWindow before the WindowTreeHostMus/ui::Compositor.
So, the problem is likely that the GPU is referencing something that's been deleted.
Oshima may know why we delay WindowTreeHost destruction for possible re-use.
We might need to delay the DisplaySynchronizer's ash/wm -> mus/ws display destruction notification.
There are probably multiple defects packed into this issue, but I'll try to follow up there.

Basically the ui::Compositors LayerTreeHost should be destroyed before XDestroyWindow() is called. Here are the lines in question:

Put a log after this one:
https://cs.chromium.org/chromium/src/ui/compositor/compositor.cc?l=234&rcl=a3360971dab6da9c2a28f9362dee531c1a1e2ffe

Put a log before this one:
https://cs.chromium.org/chromium/src/ui/platform_window/x11/x11_window_base.cc?l=60&rcl=a3360971dab6da9c2a28f9362dee531c1a1e2ffe

If they're happening in the wrong order that will be problematic.

We shouldn't be destroying an X window when adding a new display ... are we doing that for some reason?

This happens when removing displays (on ctrl-shift-d to remove an XWindow and simulate the destruction of a display, and *probably* on device when unplugging/disabling a display).

There is also existing quirky behavior that removes the displays and recreates them as part of the configuration to toggle unified and mirror mode. Those initial changes are reported from ash to mus by DisplaySynchronizer similar to removing a display.

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/5697939468e0812830e0362a3e6c1b44c352cfc6

commit 5697939468e0812830e0362a3e6c1b44c352cfc6
Author: Mike Wasserman <msw@chromium.org>
Date: Wed Jan 17 22:38:58 2018

mus: Fix gpu context lost errors and crashes on display removal

Destroy AshWindowTreeHostMus's compositor on shutdown.
(Mus async destroys the underlying platform window)

Destroy displays on root removal, not config changes.
(revert http://crrev.com/c/761764 to match cash dtor ordering)

Use a stub window for Ash's virtual unified display.
(matches cash to use an offscreen surface for rendering)

Bug:  798538 
Test: No errors/crashes removing displays with --mus, mirroring/unified works.
Change-Id: I064416cfc377bf19ec9afa214baa28a75846acf8
Reviewed-on: https://chromium-review.googlesource.com/862603
Commit-Queue: Michael Wasserman <msw@chromium.org>
Reviewed-by: Scott Violet <sky@chromium.org>
Cr-Commit-Position: refs/heads/master@{#529930}
[modify] https://crrev.com/5697939468e0812830e0362a3e6c1b44c352cfc6/ash/display/mirror_window_controller.cc
[modify] https://crrev.com/5697939468e0812830e0362a3e6c1b44c352cfc6/ash/host/ash_window_tree_host_mus.cc
[modify] https://crrev.com/5697939468e0812830e0362a3e6c1b44c352cfc6/ash/system/night_light/night_light_controller.cc
[modify] https://crrev.com/5697939468e0812830e0362a3e6c1b44c352cfc6/ash/system/night_light/night_light_controller_unittest.cc
[modify] https://crrev.com/5697939468e0812830e0362a3e6c1b44c352cfc6/services/ui/ws/display.cc
[modify] https://crrev.com/5697939468e0812830e0362a3e6c1b44c352cfc6/services/ui/ws/display_manager.cc
[modify] https://crrev.com/5697939468e0812830e0362a3e6c1b44c352cfc6/services/ui/ws/platform_display_default.cc
[modify] https://crrev.com/5697939468e0812830e0362a3e6c1b44c352cfc6/services/ui/ws/window_tree_unittest.cc