I tried attaching a debugger to the browser process when this was occuring, and set a breakpoint on device::OpenVRRenderLoop::SubmitFrameWithTextureHandle.  This breakpoint did not hit while the bug was occurring, but after a few minutes it fixed itself and the breakpoint hit.

We have an int16_t frame id counter that wraps around after frame 32767.

90fps * 60seconds/min * 6 min = 32,400 frames before we have a negative frame id.

In VRDisplay, we bail out without submitting frames when the frame id is negative.

I'm currently testing the fix.

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

commit 4e32317a0570c7878a2c017c81270408f1f76881
Author: Bill Orr <billorr@chromium.org>
Date: Fri Mar 09 23:09:59 2018

Fix bug where overflow caused us to stop submitting OpenVR frames

Approximately every 6 minutes VRDisplay would stop submitting frames
to OpenVRRenderLoop.  The reason for this is that VRDisplay won't
submit frames with a negative frame id.

Frame id is stored as a 16-bit signed int, overflowing after 32767.
32767 frames / (90fps*60sec/min) = 6.068 min before overflow

BUG= 820525 

Change-Id: Ie6131f3e246f7d38fa8790e1dd27cea7ff4cbb20
Reviewed-on: https://chromium-review.googlesource.com/957523
Reviewed-by: Klaus Weidner <klausw@chromium.org>
Commit-Queue: Bill Orr <billorr@chromium.org>
Cr-Commit-Position: refs/heads/master@{#542270}
[modify] https://crrev.com/4e32317a0570c7878a2c017c81270408f1f76881/device/vr/oculus/oculus_render_loop.cc
[modify] https://crrev.com/4e32317a0570c7878a2c017c81270408f1f76881/device/vr/openvr/openvr_render_loop.cc