Segfault in dl_close when calling vr::VR_Init() on linux

[slowriot]

A very simple hello world program (on a system with no HMD) returns true for vr::VR_IsHmdPresent() but then segfaults in the call to vr::VR_Init().

System is linux, amd64, C++ test program built with GCC 5.3.1.

Test program that reproduces the error:

// Build with g++ -std=c++11 openvrtest.cpp -L. -lopenvr_api -Iinclude -o openvrtest
#include <iostream>
#include "openvr.h"

auto main()->int {
  if(vr::VR_IsHmdPresent()) {
    std::cout << "No head mounted display present." << std::endl;
    return EXIT_SUCCESS;
  }
  std::cout << "Head mounted display may be present, initialising..." << std::endl;
  vr::EVRInitError vr_error = vr::VRInitError_None;
  vr::IVRSystem *hmd_handle = vr::VR_Init(&vr_error, vr::VRApplication_Scene);
  std::cout << "Initialised successfully" << std::endl;
  return EXIT_SUCCESS;
}

Produces the output and segfault:

Head mounted display may be present, initialising...

Program received signal SIGSEGV, Segmentation fault.
_dl_close (_map=0x0) at dl-close.c:762
762 dl-close.c: No such file or directory.
(gdb) bt
#0  _dl_close (_map=0x0) at dl-close.c:762
#1  0x00007ffff7dea114 in _dl_catch_error (objname=0x613c30, errstring=0x613c38, mallocedp=0x613c28, 
    operate=0x7ffff6b43fd0 <dlclose_doit>, args=0x0) at dl-error.c:187
#2  0x00007ffff6b444d9 in _dlerror_run (operate=operate@entry=0x7ffff6b43fd0 <dlclose_doit>, args=0x0) at dlerror.c:163
#3  0x00007ffff6b43fff in __dlclose (handle=<optimized out>) at dlclose.c:46
#4  0x00007ffff7b92fcb in vr::VR_InitInternal (peError=0x7fffffffe62c, eApplicationType=vr::VRApplication_Scene)
    at openvr_api.cpp:45
#5  0x0000000000400d3b in vr::VR_Init(vr::EVRInitError*, vr::EVRApplicationType) ()
#6  0x0000000000400b5e in main ()

[fszeliga]

+1 any solutions to this?

[slowriot]

No reply to this critical issue after several months. It seems that with this, openvr is completely unusable on linux. What a joke to call it "open".

[shinyquagsire23]

Can also confirm having this issue, can't even get OpenVR to work at all with the hellovr example

[mnottale]

To fix this you need to install the steam VR SDK, it's listed in "library->tools" in the steam client. This should create the file ~/.openvr/openvrpaths.vrpath , which I had to copy in ~/.config/openvr/openvrpaths.vrpath

[slowriot]

Rather than copying, I suggest symlinking the directory: ln -s ~/.openvr/ ~/.config/openvr

As a user-side workaround, this does work, but it means that you cannot programmatically detect whether the system can safely run OpenVR or not - and you have no choice but to crash if the player doesn't have a VR setup installed, so you need to ship a separate binary for VR use.

It's not much use having an optionally initialisable component that can potentially fail if the user has no VR setup, if the closed-source part of the library causes a crash in that circumstance :/

[krux02]

yay almost a year, and no progress to this humiliating bug.

[madrang]

I hate the fact that i pre-ordered the Vive when it was showing the Linux icon on the Steam store and that i still never had a chance to try it.... http://www.vronlinux.com/articles/valve-when-can-i-use-my-vive-under-linux.16

It doesn't help that VR on Linux is working and only the Steam VR app seems to be crashing... http://www.vronlinux.com/articles/quake-iii-arena-maps-in-vr-under-linux-with-vive-vrui.38

At least it should be out soon.... http://www.vronlinux.com/articles/croteam-ready-with-serious-sam-vr-when-steamvr-for-linux-arrives.54

[Erdbeerenjanzi]

This Problem seems to be connected to #492 . The reason of the segmentation fault is a call of dlclose() with NULL as an argument (see the reference for further details). However the proposed fix will probably prevent your program from crashing but will not get it to work perfectly, because VR_LoadHmdSystemInternal() does not init properly. The returned EVRInitError will provide more information about what was going wrong.
Hopefully the fix will get merged soon...

[mdiluz]

Checking in - has there been any progress on resolving this issue?

[krux02]

@mdiluz well check it out, and post an update if this is still present. I am not developing on such a device anymore.

[mdiluz]

In my checks this was resolved in v1.0.7, in commit b6539291b88eaa65c58c076cafe4eacd0ae2e06, using the code in the original issue.

EDIT: Code change that likely would have fixed this is https://github.com/ValveSoftware/openvr/commit/b6539291b88eaa65c58c076cafe4eacd0ae2e062#diff-1d2cdb4955498a861106f78a9ef206d0R34

[kisak-valve]

Closing per the last comment.

[groovysnake]

This issue is actually still present in 2018.3.6.

[krux02]

@kisak-valve you just closed the issue without testing it? It's not like this is a hard to reproduce problem.

[mdiluz]

2018.3.6 is a Unity version, which still contains an older version of OpenVR with this bug. The bug is fixed in this repo, so I think there's a bit of confusion here.

[madrang]

I extremely regret supporting Valve/Steam and that VR door stopper...

I preordered at release and now more than 2 or 3 years later, still waiting for fixes so i can play a single VR game.

So much wasted money..... Should have asked for a refund long ago.....

Never again !!!