With my patch, it turned out to that the exo code still did not release the buffers as exo/layer_tree_frame_sink_holder.cc was doing a check that the resources were in last_frame_resources_ (which was true), and filtering them out.

I have a patch for that issue, but it requires having a nonzero presentation_token for all submitted frames so that there is a callback via LayerTreeFrameSinkHolder::DidDiscardCompositorFrame so that the immediate rejection can be detected, and the resources released.

Following that issue, the Wayland client assumed the surface commits would actually succeed, and that the buffer that was being displayed prior to the surface commit would be released after the commit changed the buffer. As that wasn't happening, the client (still) hung.

For the last I put together one possible solution, which is to display a blank/black frame, which does cause all the displayed buffers to be released. I think the forced release with a DCHECK is the way to proceed.

But alternatively we could signal an error on the Wayland client interface, but I think all such errors are really an internal failure, and signaling it through the interface isn't helpful as it isn't the client's fault.

I'll upload two more patches soon, along with addressing the feedback on the first one.

(Note, I also tracked down the reason for the frame being rejected ( issue 846169 ) in the first place -- these fixes are now preventing a similar hard to diagnose hang from reoccurring should there be some other issue causing frames to be rejected)

Ok, we are going to not complicate the exo code with additional logic for trying to release buffers properly if a frame is rejected. See discussion here:

https://chromium-review.googlesource.com/c/chromium/src/+/1087316

I still have the a patch to be more consistent in error handling in viz here:

https://chromium-review.googlesource.com/c/chromium/src/+/1070714

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

commit 8e2f3d3f4cc694638a9ee012759689db59e8fbf0
Author: Lloyd Pique <lpique@chromium.org>
Date: Mon Jun 11 20:35:37 2018

[viz] Release frame resources on frame rejection

If a frame is rejected for any reason, the resources for the rejected
frame still need to be released.

To enforce this, a ScopedClosureRunner is created by the frame sink, and
passed to the surface. The surface will reset the closure so the
callback is called once it has passed some sanity checks.

All existing (but inconsistently performed) cleanup code has been
unified in the new callback.

Bug:  844800 
Cq-Include-Trybots: luci.chromium.try:android_optional_gpu_tests_rel
Change-Id: Id07c89ac39c850d1e3603b0a6beee1787489181a
Reviewed-on: https://chromium-review.googlesource.com/1070714
Commit-Queue: Lloyd Pique <lpique@chromium.org>
Reviewed-by: Fady Samuel <fsamuel@chromium.org>
Cr-Commit-Position: refs/heads/master@{#566134}
[modify] https://crrev.com/8e2f3d3f4cc694638a9ee012759689db59e8fbf0/components/viz/service/frame_sinks/compositor_frame_sink_support.cc
[modify] https://crrev.com/8e2f3d3f4cc694638a9ee012759689db59e8fbf0/components/viz/service/frame_sinks/compositor_frame_sink_support.h
[modify] https://crrev.com/8e2f3d3f4cc694638a9ee012759689db59e8fbf0/components/viz/service/frame_sinks/compositor_frame_sink_support_unittest.cc
[modify] https://crrev.com/8e2f3d3f4cc694638a9ee012759689db59e8fbf0/components/viz/service/surfaces/surface.cc
[modify] https://crrev.com/8e2f3d3f4cc694638a9ee012759689db59e8fbf0/components/viz/service/surfaces/surface.h