Closed Bug 1373279 Opened 7 years ago Closed 6 years ago

"Unable to read VR Path Registry ..." warning at startup

Categories

(Core :: WebVR, defect, P4)

Product:
Core
Component:
WebVR
Type:
defect

Tracking

()

Status:
RESOLVED FIXED
Milestone:
mozilla62
Tracking Flags:
Tracking Status
firefox62 --- fixed

People

(Reporter: ray_engelking, Assigned: kip)

References

(Blocks 1 open bug)

Details

(Keywords: reproducible)

Attachments

(1 file)

Bug 1373279 - Avoid checking for OpenVR runtime until hitting WebVR content
59 bytes, text/x-review-board-request
rbarker
: review+
Details 
Getting 2 new errors with the latest Firefox update 53, and on 54;
Unable to read VR Path Registry from C:\Users\rengelking\AppData\Local\openvr\openvrpaths.vrpath
JavaScript error: chrome://pin4ever/content/pin4ever.js, line 421: TypeError: Components.classes['@mozilla.org/satchel/form-history;1'] is undefined
The second error appears to be from an extension, you should contact the extnesion author directly about that.
Re-labeling and re-classifying this for the first message (which I believe is a warning and not an error, but it is noisy...)

For the WebVR folks, I see that same message even during xpcshell tests that don't do anything related to WebVR...
Component: WebExtensions: Untriaged → WebVR
Product: Toolkit → Core
Summary: Missing functionality: <add summary here> → "Unable to read VR Path Registry ..." warning at startup
Severity: blocker → normal
(In reply to Andrew Swan [:aswan] from comment #1)
> The second error appears to be from an extension, you should contact the
> extnesion author directly about that.
> Re-labeling and re-classifying this for the first message (which I believe
> is a warning and not an error, but it is noisy...)
> 
> For the WebVR folks, I see that same message even during xpcshell tests that
> don't do anything related to WebVR...

Thank you; I guess the form-history has been deprecated for 3 to 4 years, and it was just removed. The replacement is FormHistory.jsm, although just learned that all "Legacy" extensions are being replaced with Chrome-like WebExtensions; if I wanted to write extensions like Chrome, I would just use Chrome, and not Firefox.. not sure about the rational behind eliminating all XUL type extensions, but there will be even less reason to use Firefox, when version 57 goes live on November 14th.
The real issue seems to be that WebVR is probing for the OpenVR runtime before hitting WebVR content.

Can we narrow this down to a particular test that is triggering the message from WebVR, or does it happen on all of the xpcshell tests?
Flags: needinfo?(aswan)
(In reply to :kip (Kearwood Gilbert) from comment #3)
> Can we narrow this down to a particular test that is triggering the message
> from WebVR, or does it happen on all of the xpcshell tests?

Dunno, I don't see it in recent test output, but I remember it being quite frequent.  Perhaps its been fixed in the ~3 months since comment 1?
Flags: needinfo?(aswan)
status-firefox57: --- → affected
Priority: -- → P4
Status: UNCONFIRMED → NEW
Ever confirmed: true
Started nightly firefox using "firefox --console" and got:
"Unable to read VR Path Registry from C:\Users\Henrik Gemal\AppData\Local\openvr\openvrpaths.vrpath"
This happens on every startup on OS X and is quite annoying for debugging since it happens later on too (maybe for each new process startup?):

$ /Applications/FirefoxNightly.app/Contents/MacOS/firefox --profile /tmp/vrspam
Unable to read VR Path Registry from /Users/matthew/Library/Application Support/OpenVR/.openvr/openvrpaths.vrpath
Unable to read VR Path Registry from /Users/matthew/Library/Application Support/OpenVR/.openvr/openvrpaths.vrpath

The general policy is that console logging shouldn't be output in official builds either and this happens on a stock Nightly.
Has STR: --- → yes
Keywords: reproducible
I would say more important than the console noise is the fact that this work is happening at startup at all.  Lots of people have worked very hard recently to remove unnecessary work from startup.  However fast reading a vr path registry is, these sorts of things all add up.
I have reproduced it in the current nightly, thanks!  We should indeed not be firing up OpenVR until visiting a WebVR site.

Stay tuned for a patch.
Assignee: nobody → kgilbert
If this is causing main thread I/O, it's much more severe than just the noise caused by the warning. kip, are you still intending to produce a patch soon? :-)
Flags: needinfo?(kgilbert)
(In reply to Florian Quèze [:florian] from comment #10)
> If this is causing main thread I/O, it's much more severe than just the
> noise caused by the warning. kip, are you still intending to produce a patch
> soon? :-)
I've confirmed that after the tty spam, there is no more I/O on the main thread, but this shouldn't be initializing for that thread -- it should only be running in the GPU process.

I suspect the regression is that VRManager::ManagerInit() is being called twice:

- In GPUParent::RecvInit
- In gfxPlatform::gfxPlatform()

It should be only called once, with the location dependent on if e10s is enabled or not.

If we only support WebVR with e10s enabled, we may be able to simply delete one of these calls.  We need to be careful to test all the platforms [eg for Android/GeckoView] after removing it, or add conditions if needed.

This may be to late to fix for FF60, but can I land the fix shortly after.
Flags: needinfo?(kgilbert)
In bug 1414495 we are seeing intermittent browser startup hangs during Windows tests. At least some of those appear to be hung on the VRLOG call producing the warning of this bug: see https://bugzilla.mozilla.org/show_bug.cgi?id=1414495#c66 and https://bugzilla.mozilla.org/show_bug.cgi?id=1414495#c68.

:kip -- Do you expect to resolve this bug soon?
Flags: needinfo?(kgilbert)
(In reply to Geoff Brown [:gbrown] from comment #12)
> In bug 1414495 we are seeing intermittent browser startup hangs during
> Windows tests. At least some of those appear to be hung on the VRLOG call
> producing the warning of this bug: see
> https://bugzilla.mozilla.org/show_bug.cgi?id=1414495#c66 and
> https://bugzilla.mozilla.org/show_bug.cgi?id=1414495#c68.
> 
> :kip -- Do you expect to resolve this bug soon?

I will try some fixes later this week.  There is a chance that fixing the redundant initialization in multiple processes may also solve some other issues I've seen reported.
Flags: needinfo?(kgilbert)
Sorry to pester you :kip, but do you have an update?
Flags: needinfo?(kgilbert)
It looks like that the attached patch broke all builds and nearly all test jobs. A common crash signature is:

> [@ mozilla::gfx::VRManagerParent::RegisterVRManagerInVRListenerThread(mozilla::gfx::VRManagerParent*)]
(In reply to Henrik Skupin (:whimboo) from comment #19)
> It looks like that the attached patch broke all builds and nearly all test
> jobs. A common crash signature is:
> 
> > [@ mozilla::gfx::VRManagerParent::RegisterVRManagerInVRListenerThread(mozilla::gfx::VRManagerParent*)]

Indeed.  It appears that there are some accesses to the redundantly initialized VRManager.  I'll track these down and update the patch.
Flags: needinfo?(kgilbert)
After some deeper inspection, it appears that the redundantly initialized VRManager is not connecting to any VR API's once started.  It early-exits during vsync refreshes and is only checking for presence of the OpenVR runtime files at startup.

I'll clean up the redundantly initialized VR Manager, but to fix this particular TTY spam bug, I can defer the checking for the OpenVR runtime files until actually hitting WebVR content.

Updated patch incoming...
Cleanup of the additional VRManager will be done as part of Bug 1362578 (Move VRManager to its own process)
Attachment #8973073 - Flags: review?(rbarker)
Comment on attachment 8973073 [details]
Bug 1373279 - Avoid checking for OpenVR runtime until hitting WebVR content

https://reviewboard.mozilla.org/r/241610/#review248984
Attachment #8973073 - Flags: review?(rbarker) → review+
Pushed by kgilbert@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/0f11165c90a1
Avoid checking for OpenVR runtime until hitting WebVR content r=rbarker
https://hg.mozilla.org/mozilla-central/rev/0f11165c90a1
Status: NEW → RESOLVED
Closed: 6 years ago
status-firefox62: --- → fixed
Resolution: --- → FIXED
Target Milestone: --- → mozilla62
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: