Older Unity builds segmentation fault (SteamVR Room Setup & Tutorial, Munch Demo, ...)

steamvrclosed

ValveSoftware/SteamVR-for-Linux#105 · opened 2018-05-03 by ChristophHaag · updated 2018-11-01 · 19 comments · github

CChristophHaag 2018-05-03 github

radv 967aabca06f + direct mode patches in direct mode on RX 480.
steamvr_system_report.txt

Thread 24 "Munch.x86_64" received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x7fff959d3700 (LWP 1278)]
0x0000000000000000 in ?? ()
(gdb) bt
#0  0x0000000000000000 in  ()
#1  0x00007fff09460154 in CSharedSemaphoreLinux::ImportVulkanSemaphore(unsigned long, unsigned long) () at /home/chris/.local/share/Steam/SteamApps/common/SteamVR/bin/linux64/vrclient.so
#2  0x00007fff093428e0 in CVRCompositorSharedTextures::UpdateTextureSet(CVRCompositorSharedTextures::Params const*, VRCompositorState_TextureSet_t*) ()
    at /home/chris/.local/share/Steam/SteamApps/common/SteamVR/bin/linux64/vrclient.so
#3  0x00007fff093396eb in CVRCompositorClient::Submit(vr::EVREye, vr::Texture_t const*, vr::VRTextureBounds_t const*, vr::EVRSubmitFlags) ()
    at /home/chris/.local/share/Steam/SteamApps/common/SteamVR/bin/linux64/vrclient.so
#4  0x000000000112ad7d in  ()
#5  0x000000000110c3b6 in  ()
#6  0x0000000001239fc6 in  ()
#7  0x0000000001242b3b in  ()
#8  0x0000000001237ee7 in  ()
#9  0x00000000008db8f8 in  ()
[#10](/issue/ValveSoftware/SteamVR-for-Linux/10) 0x00007ffff79bd075 in start_thread () at /usr/lib/libpthread.so.0
[#11](/issue/ValveSoftware/SteamVR-for-Linux/11) 0x00007ffff6bb453f in clone () at /usr/lib/libc.so.6

CChristophHaag 2018-05-08 github

SteamVR Room Setup and SteamVR Tutorial probably have the same problem.

Hh1z1 2018-05-15 github

Is that not Windows only or did they pull the Linux version? AFAIK the tutorial and setup is based on mono.

LLyle-Tafoya 2018-06-23 github

I am unable to run Room Setup on a fully updated Ubuntu 16.04 computer. This makes it impossible for me to play VR games as SteamVR insists on running Room Setup first. I am using a GTX 1080ti with nvidia 396.24.02. I have tried using the beta and non-beta versions of both Steam client and SteamVR. The problem I experience is exactly as described in #109 which has been marked as a duplicate of this issue.

ZZamundaaa 2018-07-23 github

Room Setup and SteamVR Tutorial both crash instantly on startup. Using Kubuntu 18.04 with upgraded kernel (4.17.9). Graphics card: rx 580. Tracking and viewing work correctly

VVash63 2018-10-04 github

Same problem here on Arch w/ Nvidia 410.57 drivers. Can't open room setup.

Rryao 2018-10-04 github

Try setting STEAM_RUNTIME_PREFER_HOST_LIBRARIES=0 in your environment.

Rryao 2018-10-04 github

I also vaguely recall having trouble setting things up until I installed lsusb, installed dbus and started dbus.

Rryao 2018-10-04 github

Someone in discord who could not get the SteamVR setup to launch on Arch Linux told me that setting STEAM_RUNTIME=1 STEAM_RUNTIME_PREFER_HOST_LIBRARIES=0 in his environment made this work for him.

VVash63 2018-10-04 github

Yeah, that was me. It's working with those vars set.

Rryao 2018-10-04 github

Small world. ;)

Ssilelmot 2018-10-27 github

unfortunately this doesnt work for me. on nvidia 396.54 i can start room-setup but it gets very stuttering and i am not able to enter my room-size.

VVash63 2018-10-27 github

Yeah, this stopped working for me as well... not sure when but I changed my room layout a bit and can no longer make it through the room setup. It doesn't crash at boot anymore but it always crashes before I can get to the end, usually before I even start measuring the room.

FFictionX 2018-10-28 github

Same. Segmentation fault 30 seconds after starting Room Setup, no matter how far I've gotten in the process at that point. It happens even if I just stay on the initial screen (selecting room-scale / Standing Only).

Llostgoat 2018-10-29 github

I've opened issue #150 for feedback on room setup crashing mid-setup.

Regarding this issue, old versions of unity fail to query SteamVR for the appropriate list of extensions. This used to be okay in old versions of the graphics drivers that enabled extension entrypoints even if the extension was not requested.

New versions of vulkan drivers will hide the entryppoints if the corresponding extension was not requested. To fix the issue the offending apps need to be ported to a new unity version.

To workaround the issue for old apps, the envextensions vulkan layer can be used to enable the necessary extensions through environment variables. This layer ships with steamvr.

CCheeseness 2018-10-31 github

New versions of vulkan drivers will hide the entryppoints if the corresponding extension was not requested. To fix the issue the offending apps need to be ported to a new unity version.

To workaround the issue for old apps, the envextensions vulkan layer can be used to enable the necessary extensions through environment variables. This layer ships with steamvr.

I'm having trouble finding information on envextensions. If it ships with SteamVR, does that mean that anything launched via SteamVR should have those extensions enabled automatically (if not, maybe that is the right solution for looking after people who're targeting SteamVR for Linux as early adopters - the people who'll go on to set the initial narratives about whether supporting Linux is worthwhile)? Would you be able to point me toward some documentation?

Llostgoat 2018-10-31 github

Hey @Cheeseness

The correct approach is for applications to query GetVulkanInstanceExtensionsRequired()/GetVulkanDeviceExtensionsRequired() through the openvr api and use the results to initialize their openvr vulkan instance/device:
https://github.com/ValveSoftware/openvr/blob/master/headers/openvr.h#L2892

We don't want to enable the extra layer for all apps, as we'd be altering their instance/device creation parameter for all instance/devices, not just the ones specific to openvr.

More info on the envextensions layer:
https://github.com/lostgoat/VulkanTools/commit/7735db4fbc53f02841af47b9d8e8926d66db7207

CCheeseness 2018-11-01 github

Sure, correct for future stuff, but that's 100% not what we're talking about here. There's a level of responsibility to the positive experiences of early adopters that I think needs to be taken seriously, even if that means eating the consequences of third party bugs.

What I'm most interested in right now is what options I can recommend to other developers who've found themselves in a situation where their games no longer function that doesn't involve migrating to newer tech (or anything else that incurs more than an hour or so's worth of work).

The launch options section of the Steam partner site doesn't allow for environment variables to be set, and so far as I can see, there's nothing special or additional that can be set for VR apps. As a practical solution for developers, this layer feels kinda lacking, but a bash script that gives those env vars appropriate values is a lot less work than shifting a project to a newer version of Unity.

I was hoping for more documentation than a terse commit message - I definitely don't feel comfortable pointing other developers toward that alone. It'd be nice to not have to write an app to call GetVulkanInstanceExtensionsRequired() and GetVulkanDeviceExtensionsRequired() in order to get a list of what people are going to need to stick in those environment variables.

PPlagman 2018-11-01 github

The documentation for Vulkan OpenVR clients is there, and linked from openvr.h:

https://github.com/ValveSoftware/openvr/wiki/Vulkan

Calling GetVulkanInstanceExtensionsRequired() / GetVulkanDeviceExtensionsRequired() at runtime is a required step for proper operation of Vulkan OpenVR clients. It's important to call it at runtime and not just store a list of extensions to enable, at these extensions will keep changing over time.

CCheeseness 2018-11-01 github

It's important to call it at runtime and not just store a list of extensions to enable, at these extensions will keep changing over time.

I'm definitely not advocating against that. I'm trying to look at ways that developers who aren't in a position to do that can keep their games running without significant overheads that are likely to (and likely to have already) have them come away with a "Supporting Linux is too much hassle" type narrative.

Nothing extracted yet.