Crash on Linux when starting a VR Session using SteamVR #92723

New Issue

Jens · 2021-11-01T18:47:25+01:00

Jens commented

2021-11-01 18:47:25 +01:00

System Information
Operating system: Linux-5.4.0-89-generic-x86_64-with-glibc2.27 64 Bits
Graphics card: NVIDIA GeForce RTX 2070 SUPER/PCIe/SSE2 NVIDIA Corporation 4.5.0 NVIDIA 495.44

OpenXR Runtime: SteamVR beta Version 1.20.4 (1634602223) Built Oct 19, 2021 at 02:10
HMD: Valve Index

Blender Version
Broken: version: 3.0.0 Beta, branch: master, commit date: 2021-10-31 11:08, hash: blender/blender@a06abbac92
Worked: unknown

Addon Information
Name: VR Scene Inspection (0, 10, 0)
Author: Julian Eisel (Severin), Sebastian Koenig, Peter Kim (muxed-reality)

Short description of error
Blender crashes on Linux when trying to start a VR Session using SteamVR

Exact steps for others to reproduce the error

Start SteamVR
In Blender now start a VR Session using the VR Scene Inspection Addon
Blender crashes with memory access violation

blender.crash.txt

**System Information** Operating system: Linux-5.4.0-89-generic-x86_64-with-glibc2.27 64 Bits Graphics card: NVIDIA GeForce RTX 2070 SUPER/PCIe/SSE2 NVIDIA Corporation 4.5.0 NVIDIA 495.44 OpenXR Runtime: SteamVR beta Version 1.20.4 (1634602223) Built Oct 19, 2021 at 02:10 HMD: Valve Index **Blender Version** Broken: version: 3.0.0 Beta, branch: master, commit date: 2021-10-31 11:08, hash: `blender/blender@a06abbac92` Worked: unknown **Addon Information** Name: VR Scene Inspection (0, 10, 0) Author: Julian Eisel (Severin), Sebastian Koenig, Peter Kim (muxed-reality) **Short description of error** Blender crashes on Linux when trying to start a VR Session using SteamVR **Exact steps for others to reproduce the error** - Start SteamVR - In Blender now start a VR Session using the VR Scene Inspection Addon - Blender crashes with memory access violation [blender.crash.txt](https://archive.blender.org/developer/F11662737/blender.crash.txt)

Jens commented

2021-11-01 18:47:25 +01:00

Added subscriber: @Jens.Ne

blender-admin commented

2021-11-01 18:47:25 +01:00

#98087 was marked as duplicate of this issue

Jens commented

2021-11-01 18:50:01 +01:00

The VR Scene Inspection never worked for me on Linux.
The last time I reported about that was in this Task: https://developer.blender.org/T78267
This was closed with a fix for Windows.

Now with Blender 3.0 in Beta I wanted to check again and it still crashes for me on Linux.
Though the crash log looks different now, not showing any XR components or SteamVR.
So I decided to make a new report for this here.

The VR Scene Inspection never worked for me on Linux. The last time I reported about that was in this Task: https://developer.blender.org/T78267 This was closed with a fix for Windows. Now with Blender 3.0 in Beta I wanted to check again and it still crashes for me on Linux. Though the crash log looks different now, not showing any XR components or SteamVR. So I decided to make a new report for this here.

Germano Cavalcante commented

2021-11-01 21:18:17 +01:00

Added subscriber: @mano-wii

Germano Cavalcante commented

2021-11-01 21:18:17 +01:00

In fact it's not #add-ons_community but it's #add-ons_bf-blender. So adding the tag.

Peter Kim commented

2021-11-02 13:20:50 +01:00

Added subscriber: @muxed-reality

Peter Kim commented

2021-11-02 13:20:50 +01:00

@Jens.Ne Thanks for the report, and good thinking for making a new one due to the different crash log.
Although the crash log does not show anything XR or SteamVR-related, I believe the underlying issue is still the same (using SteamVR with an NVIDIA graphics card in Blender).

To verify this, using a Windows debug build I disabled the workaround from blender/blender@cb578ca104 and got the following crash, which looks similar to the one you had on Linux:
blender-modified.crash.txt

The exact cause is difficult to pinpoint, but I'll keep investigating this and hopefully make some headway.

While it's unfortunate there's no similar workaround for Linux, as an alternative to SteamVR you can try using Monado .
It seems like Monado has some Valve Index support (although position tracking may or may not be reliable).

@Jens.Ne Thanks for the report, and good thinking for making a new one due to the different crash log. Although the crash log does not show anything XR or SteamVR-related, I believe the underlying issue is still the same (using SteamVR with an NVIDIA graphics card in Blender). To verify this, using a Windows debug build I disabled the workaround from blender/blender@cb578ca104 and got the following crash, which looks similar to the one you had on Linux: [blender-modified.crash.txt](https://archive.blender.org/developer/F11677751/blender-modified.crash.txt) The exact cause is difficult to pinpoint, but I'll keep investigating this and hopefully make some headway. While it's unfortunate there's no similar workaround for Linux, as an alternative to SteamVR you can try using [Monado ](https://docs.blender.org/manual/en/3.0/getting_started/configuration/hardware.html#monado). It seems like Monado has some [Valve Index support ](https://monado.freedesktop.org/#supported-hardware) (although position tracking may or may not be reliable).

Jens commented

2021-11-03 19:20:26 +01:00

@muxed-reality Thank you for looking into this.
And thank you for all the work you are doing for VR! :)

I will look into Monado.

@muxed-reality Thank you for looking into this. And thank you for all the work you are doing for VR! :) I will look into Monado.

Simon Lenz commented

2021-11-10 15:58:33 +01:00

Added subscriber: @Amudtogal

Simon Lenz commented

2021-11-10 15:58:33 +01:00

I have been trying to setup the Valve Index on Linux as well (for some studio work).
While it took a bit of fiddling to get SteamVR loading the right shared libraries (is there a better way to just copying them over to /usr/lib?), I have run into the same crash.

Let me know if I can help to fix this!

I have been trying to setup the Valve Index on Linux as well (for some studio work). While it took a bit of fiddling to get SteamVR loading the right shared libraries (is there a better way to just copying them over to /usr/lib?), I have run into the same crash. Let me know if I can help to fix this!

Peter Kim commented

2021-11-11 08:39:10 +01:00

@Amudtogal Thanks for offering, any help would be greatly appreciated.
I believe the problem is that SteamVR's OpenGL swapchain/context (created to submit the VR images) interferes with Blender's own OpenGL context. However, this only seems to occur on NVIDIA GPUs (not AMD) so some driver or architecture difference is probably also a factor.

Not sure if any changes to Blender alone can solve this issue (might require assistance from Valve and/or NVIDIA on their end), however you might find something if you investigate the crash with a debugger.

In the code, the VR graphics binding type is set in GHOST_XrContext::determineGraphicsBindingTypeToUse(), and here you can see that for SteamVR + NVIDIA on Windows, it falls back to DirectX (not available on Linux though). The swapchain image drawing is performed by wm_xr_draw_view(), which is called by GHOST_XrSession::drawView().

@Amudtogal Thanks for offering, any help would be greatly appreciated. I believe the problem is that SteamVR's OpenGL swapchain/context (created to submit the VR images) interferes with Blender's own OpenGL context. However, this only seems to occur on NVIDIA GPUs (not AMD) so some driver or architecture difference is probably also a factor. Not sure if any changes to Blender alone can solve this issue (might require assistance from Valve and/or NVIDIA on their end), however you might find something if you investigate the crash with a debugger. In the code, the VR graphics binding type is set in `GHOST_XrContext::determineGraphicsBindingTypeToUse()`, and here you can see that for SteamVR + NVIDIA on Windows, it falls back to DirectX (not available on Linux though). The swapchain image drawing is performed by `wm_xr_draw_view()`, which is called by `GHOST_XrSession::drawView()`.

Simon Lenz commented

2021-11-11 11:28:52 +01:00

I am not entirely sure whether my SteamVR setup is complete (Steam is annoying me with missing libraries, although I am not sure whether this could be an issue with how steam is called from Blender...), but it seems to start from the Blender instance.
Blender however, crashes right away when starting the VR session (before SteamVR even starts logging/complaining).

So I have worked my way up, to see when Blender quits. This is what I got so far:

GHOST_XrSession::draw() is not called prior crashing
GHOST_XrSession::drawLayer() is not called prior crashing
GHOST_XrSession::drawView() is not called before crashing
drawing in wm_xr_draw_view() is not called before crashing

I couldn't see where XrSession::draw() is called, so I recompiled as debug and started gdbing...

Here is the stacktrace:

- 0  __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50
- 1  0x00007fffd8936859 in __GI_abort () at abort.c:79
- 2  0x0000000013818845 in _BLI_assert_abort () at /home/simon/projects/blender/source/blender/blenlib/intern/BLI_assert.c:61
- 3  0x0000000013450c4d in blender::gpu::GLImmediate::begin() (this=0x616000032d80) at /home/simon/projects/blender/source/blender/gpu/opengl/gl_immediate.cc:132
- 4  0x0000000013382243 in immBegin(GPUPrimType, uint) (prim_type=GPU_PRIM_LINES, vertex_len=8) at /home/simon/projects/blender/source/blender/gpu/intern/gpu_immediate.cc:223
- 5  0x000000001338243c in immBeginAtMost(GPUPrimType, uint) (prim_type=GPU_PRIM_LINES, vertex_len=8) at /home/simon/projects/blender/source/blender/gpu/intern/gpu_immediate.cc:230
- 6  0x00000000086865f3 in region_draw_emboss (region=0x614000004848, scirct=0x6140000048f0, sides=9) at /home/simon/projects/blender/source/blender/editors/screen/area.c:105
- 7  0x000000000868d000 in ED_region_do_draw (C=0x60e000026a08, region=0x614000004848) at /home/simon/projects/blender/source/blender/editors/screen/area.c:604
- 8  0x0000000005062466 in wm_draw_window_offscreen (C=0x60e000026a08, win=0x6130000b1188, stereo=false) at /home/simon/projects/blender/source/blender/windowmanager/intern/wm_draw.c:730
- 9  0x0000000005063698 in wm_draw_window (C=0x60e000026a08, win=0x6130000b1188) at /home/simon/projects/blender/source/blender/windowmanager/intern/wm_draw.c:880
- 10 0x0000000005064b08 in wm_draw_update (C=0x60e000026a08) at /home/simon/projects/blender/source/blender/windowmanager/intern/wm_draw.c:1081
- 11 0x0000000005051291 in WM_main (C=0x60e000026a08) at /home/simon/projects/blender/source/blender/windowmanager/intern/wm.c:658
#12 0x0000000003168e7b in main (argc=1, argv=0x7fffffffdaf8) at /home/simon/projects/blender/source/creator/creator.c:557

As you said @muxed-reality, there is no crash in the actual XR code, but the OpenGL drawing in the window manager...

I am not entirely sure whether my SteamVR setup is complete (Steam is annoying me with missing libraries, although I am not sure whether this could be an issue with how steam is called from Blender...), but it seems to start from the Blender instance. Blender however, crashes right away when starting the VR session (before SteamVR even starts logging/complaining). So I have worked my way up, to see when Blender quits. This is what I got so far: - `GHOST_XrSession::draw()` is not called prior crashing - `GHOST_XrSession::drawLayer()` is not called prior crashing - `GHOST_XrSession::drawView()` is not called before crashing - drawing in `wm_xr_draw_view()` is not called before crashing I couldn't see where `XrSession::draw()` is called, so I recompiled as debug and started gdbing... Here is the stacktrace: ``` - 0 __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50 - 1 0x00007fffd8936859 in __GI_abort () at abort.c:79 - 2 0x0000000013818845 in _BLI_assert_abort () at /home/simon/projects/blender/source/blender/blenlib/intern/BLI_assert.c:61 - 3 0x0000000013450c4d in blender::gpu::GLImmediate::begin() (this=0x616000032d80) at /home/simon/projects/blender/source/blender/gpu/opengl/gl_immediate.cc:132 - 4 0x0000000013382243 in immBegin(GPUPrimType, uint) (prim_type=GPU_PRIM_LINES, vertex_len=8) at /home/simon/projects/blender/source/blender/gpu/intern/gpu_immediate.cc:223 - 5 0x000000001338243c in immBeginAtMost(GPUPrimType, uint) (prim_type=GPU_PRIM_LINES, vertex_len=8) at /home/simon/projects/blender/source/blender/gpu/intern/gpu_immediate.cc:230 - 6 0x00000000086865f3 in region_draw_emboss (region=0x614000004848, scirct=0x6140000048f0, sides=9) at /home/simon/projects/blender/source/blender/editors/screen/area.c:105 - 7 0x000000000868d000 in ED_region_do_draw (C=0x60e000026a08, region=0x614000004848) at /home/simon/projects/blender/source/blender/editors/screen/area.c:604 - 8 0x0000000005062466 in wm_draw_window_offscreen (C=0x60e000026a08, win=0x6130000b1188, stereo=false) at /home/simon/projects/blender/source/blender/windowmanager/intern/wm_draw.c:730 - 9 0x0000000005063698 in wm_draw_window (C=0x60e000026a08, win=0x6130000b1188) at /home/simon/projects/blender/source/blender/windowmanager/intern/wm_draw.c:880 - 10 0x0000000005064b08 in wm_draw_update (C=0x60e000026a08) at /home/simon/projects/blender/source/blender/windowmanager/intern/wm_draw.c:1081 - 11 0x0000000005051291 in WM_main (C=0x60e000026a08) at /home/simon/projects/blender/source/blender/windowmanager/intern/wm.c:658 #12 0x0000000003168e7b in main (argc=1, argv=0x7fffffffdaf8) at /home/simon/projects/blender/source/creator/creator.c:557 ``` As you said @muxed-reality, there is no crash in the actual XR code, but the OpenGL drawing in the window manager...

Simon Lenz commented

2021-11-11 14:19:49 +01:00

The crash dump is caused by glMapBufferRange which is returning a null pointer.

In the respective line, we are trying to map a vertex attribute buffer at offset 576 for 64 needed bytes, with access flags (GL_MAP_WRITE_BIT | GL_MAP_UNSYNCHRONIZED_BIT | GL_MAP_FLUSH_EXPLICIT_BIT).

About the possible sources of this error: glGetError() returns 0, which is listed as GL_NO_ERROR, so I assume this is not an assignment issue in glMapBufferRange.

The crash dump is caused by [glMapBufferRange ](https://www.khronos.org/registry/OpenGL-Refpages/gl4/html/glMapBufferRange.xhtml) which is returning a null pointer. In the respective line, we are trying to map a vertex attribute buffer at offset `576` for `64` needed bytes, with access flags (`GL_MAP_WRITE_BIT | GL_MAP_UNSYNCHRONIZED_BIT | GL_MAP_FLUSH_EXPLICIT_BIT`). About the possible sources of this error: `glGetError()` returns `0`, which is listed as `GL_NO_ERROR`, so I assume this is not an assignment issue in `glMapBufferRange`.

Simon Lenz commented

2021-11-11 14:34:21 +01:00

Unfortunately, I do not know how Blender's OpenGL context works...
I assume someone with more knowledge about the OpenGL implementation needs to look into this, I do not really know where to continue from here...

how can I debug OpenGL in Blender (beyond gdb)?
is there a link anywhere which Nvidia API or documentation was used?

Unfortunately, I do not know how Blender's OpenGL context works... I assume someone with more knowledge about the OpenGL implementation needs to look into this, I do not really know where to continue from here... - how can I debug OpenGL in Blender (beyond gdb)? - is there a link anywhere which Nvidia API or documentation was used?

Christoph Haag commented

2021-11-11 22:22:04 +01:00

Added subscriber: @haagch

Christoph Haag commented

2021-11-11 22:22:04 +01:00

I can confirm that blender crashes immAttr2f on AMD too with SteamVR. But it works fine with Monado.

My guess is that it is due to this bug https://github.com/ValveSoftware/SteamVR-for-Linux/issues/421. Workaround to that is to make the original OpenGL context current after each OpenXR swapchain interaction.

I can confirm that blender crashes immAttr2f on AMD too with SteamVR. But it works fine with Monado. My guess is that it is due to this bug https://github.com/ValveSoftware/SteamVR-for-Linux/issues/421. Workaround to that is to make the original OpenGL context current after each OpenXR swapchain interaction.

Peter Kim commented

2021-11-12 05:28:55 +01:00

@haagch Thanks a lot for the information!
Using your workaround, I was able to get SteamVR+OpenGL+NVIDIA working on Windows (actually SteamVR+OpenGL+AMD already worked on Windows, but it's good to know that this combination has issues on Linux).

Solution for me was to add DRW_opengl_context_activate(false); in wm_xr_session_create_cb() before L72.

@Amudtogal If you get the chance, can you please test this with your setup?

@haagch Thanks a lot for the information! Using your workaround, I was able to get SteamVR+OpenGL+NVIDIA working on Windows (actually SteamVR+OpenGL+AMD already worked on Windows, but it's good to know that this combination has issues on Linux). Solution for me was to add `DRW_opengl_context_activate(false);` in `wm_xr_session_create_cb()` before L72. @Amudtogal If you get the chance, can you please test this with your setup?

Simon Lenz commented

2021-11-12 12:35:15 +01:00

Added subscriber: @sebastian_k

Simon Lenz commented

2021-11-12 12:35:15 +01:00

Hey @haagch & @muxed-reality ,

indeed Blender does not crash anymore with this workaround!
However, a new problem emerges:

When starting SteamVR before activating the session in Blender I get:

the VR session is not working
the cmdline spams: ERROR (wm.xr): source/blender/windowmanager/xr/intern/wm_xr_session.c:1398 wm_xr_session_surface_offscreen_ensure: Failed to get buffer, GPUTexture: Texture allocation failed.
the SteamVR status shows "Now playing: Blender"
the UI still works, but once I stop the session, SteamVR shows an error dialog (Unable to load 'libpangoft2-1.0.so'. [...]) and once I close this info, Blender is full-on frozen.
steamtours.sh segfaults

I assume some of this could be a faulty setup of SteamVR on my side...
Maybe I need to do test this with a clean Linux install, I will discuss it with @sebastian_k.
A simple purge & reinstall of steam did not solve the issue...

Hey @haagch & @muxed-reality , indeed Blender does not crash anymore with this workaround! However, a new problem emerges: When starting SteamVR before activating the session in Blender I get: - the VR session is not working - the cmdline spams: `ERROR (wm.xr): source/blender/windowmanager/xr/intern/wm_xr_session.c:1398 wm_xr_session_surface_offscreen_ensure: Failed to get buffer, GPUTexture: Texture allocation failed.` - the SteamVR status shows "Now playing: Blender" - the UI still works, but once I stop the session, SteamVR shows an error dialog (`Unable to load 'libpangoft2-1.0.so'. [...]`) and once I close this info, Blender is full-on frozen. - `steamtours.sh` segfaults I assume some of this could be a faulty setup of SteamVR on my side... Maybe I need to do test this with a clean Linux install, I will discuss it with @sebastian_k. A simple purge & reinstall of steam did not solve the issue...

James Hogan commented

2021-11-22 09:31:15 +01:00

Added subscriber: @amalon

James Hogan commented

2021-11-22 09:31:15 +01:00

While developing osgXR, I found the best way to debug SteamVR's GL context messing was using ltrace, i.e.:

ltrace -f -e 'xr*' -e glXMakeCurrent $COMMAND

(the -f makes it follow forks to child threads). That way you can see what SteamVR is doing. In the example below you can see vrclient.so messing with the context, then the workaround sets it back:

[pid 258359] libosgXR.so.4->xrAcquireSwapchainImage(0x2e8698f7bf0, 0, 0x6d07fc939804, 1 <unfinished ...>
[pid 258359] vrclient.so->glXMakeCurrent(0x2e83dad3830, 0x5000003, 0x2e83de9d1d8, 0)                                                                                   = 1
[pid 258359] vrclient.so->glXMakeCurrent(0x2e83dad3830, 0, 0, 0x2e862d4f040)                                                                                           = 1
[pid 258359] <... xrAcquireSwapchainImage resumed> )                                                                                                                   = 0
[pid 258359] libosgViewerrd.so.161->glXMakeCurrent(0x2e83dad3830, 0x5000003, 0x2e83de9d1d8, 0)                                                                         = 1

For osgXR I found the following need the workaround (regardless of success/failure of the call):

xrEndFrame
* xrCreateSwapchain (for this, SteamVR linux_v1.14 seemed to change context without changing back, so I had to also release context if not previously set, since for me it needs calling by a non-render thread)
xrAcquireSwapchainImage
xrWaitSwapchainImage
xrReleaseSwapchainImage

Hope that helps

While developing osgXR, I found the best way to debug SteamVR's GL context messing was using ltrace, i.e.: ``` ltrace -f -e 'xr*' -e glXMakeCurrent $COMMAND ``` (the `-f` makes it follow forks to child threads). That way you can see what SteamVR is doing. In the example below you can see vrclient.so messing with the context, then the workaround sets it back: ``` [pid 258359] libosgXR.so.4->xrAcquireSwapchainImage(0x2e8698f7bf0, 0, 0x6d07fc939804, 1 <unfinished ...> [pid 258359] vrclient.so->glXMakeCurrent(0x2e83dad3830, 0x5000003, 0x2e83de9d1d8, 0) = 1 [pid 258359] vrclient.so->glXMakeCurrent(0x2e83dad3830, 0, 0, 0x2e862d4f040) = 1 [pid 258359] <... xrAcquireSwapchainImage resumed> ) = 0 [pid 258359] libosgViewerrd.so.161->glXMakeCurrent(0x2e83dad3830, 0x5000003, 0x2e83de9d1d8, 0) = 1 ``` For osgXR I found the following need the workaround (regardless of success/failure of the call): * `xrEndFrame` *` xrCreateSwapchain` (for this, SteamVR linux_v1.14 seemed to change context without changing back, so I had to also release context if not previously set, since for me it needs calling by a non-render thread) * `xrAcquireSwapchainImage` * `xrWaitSwapchainImage` * `xrReleaseSwapchainImage` Hope that helps

Simon Lenz commented

2021-12-14 13:47:08 +01:00

So here is an update:

clean PopOS installation
installed Steam (from the PopOS shop)
logged into steam, installed SteamVR
started SteamVR, did the room setup
went to the SteamVR settings (https://docs.blender.org/manual/en/latest/getting_started/configuration/hardware.html#hardware-head-mounted-displays) and set SteamVR as default OpenXR
compiled Blender from newest master, with (https://developer.blender.org/D13568) applied (let me know whether that is what you had in mind @muxed-reality
starting Blender, enable the VR scene inspection plugin
try to start a VR session, Blender fails: Failed to query OpenXR runtime information. Do you have an active runtime set up?
after some trying around, I found that it is best to test OpenXR with hello_xr -g OpenGL. This shows me that the SteamVR could not open because failed to load with message "libSDL2-2.0.so.0: cannot open shared object file: No such file or directory"
installed libsdl2-2.0-0, reran hello_xr, now it seems to work
TODO can we forward this error message to Blender? Alternatively, maybe we could add the hello_xr -g OpenGL debugging to the documentation...
reopened Blender, started a VR session, this time it seems to find the OpenXR runtime, but Blender crashes with:

Connected to OpenXR runtime: SteamVR/OpenXR (Version 0.1.0)
ERROR (wm.xr): source/blender/windowmanager/xr/intern/wm_xr_session.c:1386 wm_xr_session_surface_offscreen_ensure: Failed to get buffer, GPUTexture: Texture allocation failed.
ERROR (wm.xr): source/blender/windowmanager/xr/intern/wm_xr_session.c:1386 wm_xr_session_surface_offscreen_ensure: Failed to get buffer, GPUTexture: Texture allocation failed.
ERROR (wm.xr): source/blender/windowmanager/xr/intern/wm_xr_session.c:1386 wm_xr_session_surface_offscreen_ensure: Failed to get buffer, GPUTexture: Texture allocation failed.
ERROR (wm.xr): source/blender/windowmanager/xr/intern/wm_xr_session.c:1386 wm_xr_session_surface_offscreen_ensure: Failed to get buffer, GPUTexture: Texture allocation failed.

/tmp/blender.crash.txt:

# Blender 3.1.0, Commit date: 2021-12-14 11:13, Hash f18eb6e0ee74

# backtrace
./blender(BLI_system_backtrace+0x37) [0xb158b67]
./blender() [0x10ac7b7]
/lib/x86_64-linux-gnu/libc.so.6(+0x41040) [0x7f189a19d040]
/home/simon/.steam/debian-installation/steamapps/common/SteamVR/bin/linux64/vrclient.so(+0x222648) [0x7f184cb49648]
/home/simon/.steam/debian-installation/steamapps/common/SteamVR/bin/linux64/vrclient.so(+0x18683a) [0x7f184caad83a]
/home/simon/.steam/debian-installation/steamapps/common/SteamVR/bin/linux64/vrclient.so(+0x200db9) [0x7f184cb27db9]
/lib/x86_64-linux-gnu/libpthread.so.0(+0x9450) [0x7f189a69c450]
/lib/x86_64-linux-gnu/libc.so.6(clone+0x43) [0x7f189a273d53]

# Python backtrace

At least I got rid of the libpangoft error above, but it seems still to fail at creating the GPU buffer... Any ideas?

So here is an update: - clean PopOS installation - installed Steam (from the PopOS shop) - logged into steam, installed SteamVR - started SteamVR, did the room setup - went to the SteamVR settings (https://docs.blender.org/manual/en/latest/getting_started/configuration/hardware.html#hardware-head-mounted-displays) and set SteamVR as default OpenXR - compiled Blender from newest master, with (https://developer.blender.org/D13568) applied (let me know whether that is what you had in mind @muxed-reality - starting Blender, enable the VR scene inspection plugin - try to start a VR session, Blender fails: `Failed to query OpenXR runtime information. Do you have an active runtime set up?` - after some trying around, I found that it is best to test OpenXR with `hello_xr -g OpenGL`. This shows me that the SteamVR could not open because `failed to load with message "libSDL2-2.0.so.0: cannot open shared object file: No such file or directory"` - installed `libsdl2-2.0-0`, reran `hello_xr`, now it seems to work **TODO** can we forward this error message to Blender? Alternatively, maybe we could add the `hello_xr -g OpenGL` debugging to the documentation... - reopened Blender, started a VR session, this time it seems to find the OpenXR runtime, but Blender crashes with: ``` Connected to OpenXR runtime: SteamVR/OpenXR (Version 0.1.0) ERROR (wm.xr): source/blender/windowmanager/xr/intern/wm_xr_session.c:1386 wm_xr_session_surface_offscreen_ensure: Failed to get buffer, GPUTexture: Texture allocation failed. ERROR (wm.xr): source/blender/windowmanager/xr/intern/wm_xr_session.c:1386 wm_xr_session_surface_offscreen_ensure: Failed to get buffer, GPUTexture: Texture allocation failed. ERROR (wm.xr): source/blender/windowmanager/xr/intern/wm_xr_session.c:1386 wm_xr_session_surface_offscreen_ensure: Failed to get buffer, GPUTexture: Texture allocation failed. ERROR (wm.xr): source/blender/windowmanager/xr/intern/wm_xr_session.c:1386 wm_xr_session_surface_offscreen_ensure: Failed to get buffer, GPUTexture: Texture allocation failed. ``` `/tmp/blender.crash.txt`: ``` # Blender 3.1.0, Commit date: 2021-12-14 11:13, Hash f18eb6e0ee74 # backtrace ./blender(BLI_system_backtrace+0x37) [0xb158b67] ./blender() [0x10ac7b7] /lib/x86_64-linux-gnu/libc.so.6(+0x41040) [0x7f189a19d040] /home/simon/.steam/debian-installation/steamapps/common/SteamVR/bin/linux64/vrclient.so(+0x222648) [0x7f184cb49648] /home/simon/.steam/debian-installation/steamapps/common/SteamVR/bin/linux64/vrclient.so(+0x18683a) [0x7f184caad83a] /home/simon/.steam/debian-installation/steamapps/common/SteamVR/bin/linux64/vrclient.so(+0x200db9) [0x7f184cb27db9] /lib/x86_64-linux-gnu/libpthread.so.0(+0x9450) [0x7f189a69c450] /lib/x86_64-linux-gnu/libc.so.6(clone+0x43) [0x7f189a273d53] # Python backtrace ``` At least I got rid of the `libpangoft` error above, but it seems still to fail at creating the GPU buffer... Any ideas?

Julian Eisel commented

2021-12-14 21:54:39 +01:00

Added subscriber: @JulianEisel

Julian Eisel commented

2021-12-14 21:54:39 +01:00

Here is a more or less experimental, Linux-only fix for this: D13576: Fix #92723: Crash on Linux when starting a VR Session using SteamVR. The basic rendering seems to work now, but I see other issues, e.g.:

I have to start the session twice for SteamVR to start it properly
Restarting the session or loading files makes it go nuts
The rendering is too dark, most likely missing display space sRGB transform / gamma-correction. Think this is the 4th time some runtime has this issue, I thought it was finally gone for good...

Here is a more or less experimental, Linux-only fix for this: [D13576: Fix #92723: Crash on Linux when starting a VR Session using SteamVR](https://archive.blender.org/developer/D13576). The basic rendering seems to work now, but I see other issues, e.g.: - I have to start the session twice for SteamVR to start it properly - Restarting the session or loading files makes it go nuts - The rendering is too dark, most likely missing display space sRGB transform / gamma-correction. Think this is the 4th time some runtime has this issue, I thought it was finally gone for good...

Julian Eisel commented

2021-12-14 21:56:04 +01:00

Thanks BTW to everybody helping out here, the conversation was quite useful.

Also good to know that others have this problem too, including Godot (https://github.com/ValveSoftware/SteamVR-for-Linux/issues/421).

Thanks BTW to everybody helping out here, the conversation was quite useful. Also good to know that others have this problem too, including Godot (https://github.com/ValveSoftware/SteamVR-for-Linux/issues/421).

Christoph Haag commented

2021-12-14 22:28:57 +01:00

Btw if you ever call xrDestroyInstance you will probably get a hang because of https://github.com/ValveSoftware/SteamVR-for-Linux/issues/422