Issue metadata
Sign in to add a comment
|
JavaScript execution flakily hangs after WebXR VR entry |
||||||||||||||||||||||||
Issue descriptionRarely (1% of the time?), shortly after entering a WebXR exclusive session, all JavaScript execution on the page hangs indefinitely. After some help and digging, it looks like this is being caused by a hang in XRFrameTransport, specifically the WaitForIncomingMethodCall in WaitForGpuFenceReceived. Log statements were added before, after, and inside the if check at [1], but only the log statement before gets hit when the issue reproduces (see attached logcat snippet, added logging is prefixed with "ASDF"). So far, I've only been able to reproduce on a Pixel 1 XL with N, and only on the bots. Combined with the low reproduce rate, it can take a while to get new information from builds, and the only way we'll be able to verify a fix is run the tests like 20 times and ensure it doesn't reproduce. [1] https://cs.chromium.org/chromium/src/third_party/blink/renderer/platform/graphics/gpu/xr_frame_transport.cc?sq=package:chromium&dr=C&g=0&l=256
,
Jun 26 2018
Bumping priority since it looks like this is causing some visible flakiness on the Nougat builder.
,
Jun 26 2018
,
Jun 26 2018
Proposed patch in https://chromium-review.googlesource.com/c/chromium/src/+/1115421
,
Jun 27 2018
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/c5eab600eaf6bfc73996964a7254ece8bf5b41d5 commit c5eab600eaf6bfc73996964a7254ece8bf5b41d5 Author: Klaus Weidner <klausw@chromium.org> Date: Wed Jun 27 18:12:13 2018 Avoid hang on rapid WebXR VR exit / re-entry The "GpuFence" and "SharedBuffer" WebXR render modes use a frame-separating GpuFence, the Renderer is supposed to do a server wait for that before the second and following frames. The "is this the first frame" status is tracked by xr_frame_transport, but the property wasn't being cleared correctly when exiting and re-entering VR, with the effect that it could end up erroneously waiting for a separating fence for the first frame. BUG= 855722 Cq-Include-Trybots: luci.chromium.try:linux_layout_tests_slimming_paint_v2;master.tryserver.blink:linux_trusty_blink_rel Change-Id: I5508f184e4687d1b0a20d3da543cbbaf2e8535c1 Reviewed-on: https://chromium-review.googlesource.com/1115421 Reviewed-by: Ian Vollick <vollick@chromium.org> Commit-Queue: Klaus Weidner <klausw@chromium.org> Cr-Commit-Position: refs/heads/master@{#570841} [modify] https://crrev.com/c5eab600eaf6bfc73996964a7254ece8bf5b41d5/third_party/blink/renderer/platform/graphics/gpu/xr_frame_transport.cc
,
Jun 27 2018
Issue 856546 has been merged into this issue.
,
Jun 27 2018
I was able to reproduce the issue locally. The patch from comment #5 didn't fix it, though I suspect it was also a potential source of similar issues. Second attempt in https://chromium-review.googlesource.com/c/chromium/src/+/1117770 . With that patch applied, the test succeeded 336 times so far.
,
Jun 28 2018
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/6446758da2636db1601a083ef6c9aeab07edeee7 commit 6446758da2636db1601a083ef6c9aeab07edeee7 Author: Klaus Weidner <klausw@chromium.org> Date: Thu Jun 28 01:09:04 2018 Don't submit exclusive WebXR frames without valid frame ID For the first frame of an exclusive WebXR session, the JS animation loop may try to submit a frame without having received an exclusive FrameData response. In that case, use SubmitFrameMissing to skip the submission. For example, in shared buffer mode, the application is supposed to draw into a texture mailbox supplied in the exclusive FrameData response, and if that is not available the submission will fail. BUG= 855722 Change-Id: I69966435520b294064164bfc970bf0f300d4ca39 Reviewed-on: https://chromium-review.googlesource.com/1117770 Reviewed-by: Brian Sheedy <bsheedy@chromium.org> Commit-Queue: Klaus Weidner <klausw@chromium.org> Cr-Commit-Position: refs/heads/master@{#570990} [modify] https://crrev.com/6446758da2636db1601a083ef6c9aeab07edeee7/third_party/blink/renderer/modules/xr/xr_frame_provider.cc
,
Jun 28 2018
Tentatively marking as fixed again. bsheedy@, can you verify that it works on the bots before re-enabling the test?
,
Jun 28 2018
The disabled test was also affected by some other flakiness, but I can keep an eye out to make sure this doesn't pop up again.
,
Jun 30 2018
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/fa0094b3d551f532f69267b3d1d5b5eceb6355a0 commit fa0094b3d551f532f69267b3d1d5b5eceb6355a0 Author: Klaus Weidner <klausw@chromium.org> Date: Sat Jun 30 01:47:24 2018 Don't submit WebXR missing frames with id=-1 The "Don't submit exclusive WebXR frames without valid frame ID" patch from https://crrev.com/1117770 was incomplete, it results in closing Mojo connections due to a sanity check that treats the received frame_id==-1 as invalid. Just ignore these on the Renderer side instead of attempting to submit as missing frames. BUG= 855722 , 858838 Change-Id: I5a5c70979be2bb9a2c9429b6efa78fdd6029d4db Reviewed-on: https://chromium-review.googlesource.com/1121344 Reviewed-by: Bill Orr <billorr@chromium.org> Reviewed-by: Brian Sheedy <bsheedy@chromium.org> Commit-Queue: Klaus Weidner <klausw@chromium.org> Cr-Commit-Position: refs/heads/master@{#571737} [modify] https://crrev.com/fa0094b3d551f532f69267b3d1d5b5eceb6355a0/third_party/blink/renderer/modules/xr/xr_frame_provider.cc
,
Aug 29
|
|||||||||||||||||||||||||
►
Sign in to add a comment |
|||||||||||||||||||||||||
Comment 1 by bsheedy@chromium.org
, Jun 26 2018