I’ve built a Manjaro VM under VMWare. It works reliably, and the bug doesn’t happen there. I also have 3D acceleration enabled, which was recommended by the Manjaro installation instructions.
Does that mean it’s now working well for all of us?
Not for me. I’ve restored my Arch timeshift snapshot and have just gone through the arch wiki’s hardware acceleration guide but Rack is still not working. I don’t really know anything about graphics so I’m not sure what else to look at.
Weirdly, Rack works now whether 3D is enabled or not in virtualbox/endeavour.
Same for me, despite the fact that I followed the Archwiki too. I would be grateful if you could give us any clue on how to fix it directly on our system, because we obviously can’t use VM to produce music everyday 
At least, we know that it’s related to graphics. My laptop has two cards, Intel and Nvidia. On that subject, are you aware of any config limitations between Rack and Linux ? Should we use the integrated or the discrete card when using the vst version ?
And if you try to disable the 3D acceleration, can you reproduce this issue ?
If I disable 3D acceleration in my Manjaro VM, then the Rack VST crashes when Bitwig tries to open the VST editor window. (It seems to always crash the first time, but maybe it’s random.)
The crash is in swrast, the software rasterizer, which I assume is used when acceleration is disabled, and not used when acceleration is enabled.
As I understand it, on real hardware you have the option of using free graphics drivers or proprietary ones - does that make a difference? I’ve read that you can switch using “Manjaro Settings Manager” (note that that’s different from “Settings Manager”) / “Hardware configuration” / “Auto install proprietary driver”, but that option isn’t available to me in my VM.
For AMD, which I have, it is always recommended to use the open source driver (I’ve heard that they actively contribute to the development of it and is far ahead of the closed source driver). In previous tests I did try the closed source option from the manjaro live usb but it didn’t make any difference.
Everything I’ve tried indicates that I have acceleration enabled so I’m not sure why Rack would be unable it use it. Also, this seems to be specific to bitwig as I can use Rack in Reaper, Renoise, Carla, BespokeSynth so I would guess that if acceleration is disabled/not working then this should happen in all hosts?
Ok guys I think I found the problem. As I wrote in my last message, I have two GPU with the hybrid driver installed (video-hybrid-intel-nvidia-prime). After what @Richie suggested, I had the idea to install optimus-manager, a small utility to switch between the two GPU (need to log out between each switches).
When I use the integrated mode, the issue is happening every time. However, since I switched to Nvidia only, it is working fine ! Apparently, when “3D acceleration” is enabled in VM, the virtual system is switching to the dedicated GPU.
@TroubledMind If you also have two GPU, could you please test with the dedicated mode only ?
Also, is that an usual behaviour, or should VCV make the vst works also with the integrated mode when there are two GPU available ? @pgatt do you need me to send a new email to support regarding this “discovery”, or will you forward it to the person looking at it internally ?
I only have one GPU as far as I know. This is what I was confused about with it working in a VM with that setting enabled, surely it’s not doing anything my card can’t?
Honestly I don’t know, but it’s pretty sure that it’s graphics related under Arch based distro in Bitwig. In addition, it has been reproduced by three of us. I think we need more clarification about how the VST is handled by the GPU, especially when there are two.
Rack doesn’t do anything special with the GPU, either standalone or VST. It uses OpenGL to paint its user interface, and that will use whatever driver you have to talk to your video card.
When you have acceleration disabled, a software rasteriser (known as swrast) will be used, rather than your video card driver. It’s that swrast driver that’s crashing in the case of Bitwig (for me at least). I suspect there’s some combination of things that Bitwig and Rack are doing, which works fine on real hardware but confuses swrast.
@TroubledMind: Could you trap the crash in gdb? That would be a big help - it would tell us whether you’re using swrast in your environment, even though it doesn’t seem like you should be. To debug the crash:
- Start Bitwig and drag the Rack VST to a track. Bitwig reports the crash.
- Click “Reload plugin”.
- In a Terminal, run
ps -f -u <username> | grep BitwigPluginHost - You’ll see something like
<username> 1234 ... /opt/bitwig-studio/bin/BitwigPluginHost-X64-SSE41 ... - Run
gdbwith that number and pathname:sudo gdb -p 1234 /opt/bitwig-studio/bin/BitwigPluginHost-X64-SSE41 - Continue the process by typing
cont. - Back in Bitwig, click the icon to show the Rack VST’s editor window.
gdb should trap the crash, and if you type where it will give you a stack trace. That’s what will tell us where the crash is happening. For me, I get this:
(gdb) where
#0 0x00007feee208bb8e in free () from /usr/lib/libc.so.6
#1 0x00007feed8419f09 in ZSTD_compress () from /usr/lib/libzstd.so.1
#2 0x00007feec07c403c in ?? () from /usr/lib/dri/swrast_dri.so
#3 0x00007feec07c475d in ?? () from /usr/lib/dri/swrast_dri.so
#4 0x00007feec07b85dc in ?? () from /usr/lib/dri/swrast_dri.so
#5 0x00007feec07b156c in ?? () from /usr/lib/dri/swrast_dri.so
#6 0x00007feee207b5c2 in start_thread () from /usr/lib/libc.so.6
#7 0x00007feee2100584 in clone () from /usr/lib/libc.so.6
(gdb)
As you can see, the crash is in the swrast driver.
Thanks Richie. This is the output that I got:
#0 0x00007fbdefad934c in __pthread_kill_implementation () from /usr/lib/libc.so.6
#1 0x00007fbdefa8c4b8 in raise () from /usr/lib/libc.so.6
#2 0x00007fbdefa76534 in abort () from /usr/lib/libc.so.6
#3 0x00007fbdefacd397 in __libc_message () from /usr/lib/libc.so.6
#4 0x00007fbdefae333c in malloc_printerr () from /usr/lib/libc.so.6
#5 0x00007fbdefae5420 in _int_free () from /usr/lib/libc.so.6
#6 0x00007fbdefae7be3 in free () from /usr/lib/libc.so.6
#7 0x00007fbd9ef76a5a in ZSTD_freeDDict () from /home/alex/.local/share/VCV/Rack2Pro/libRack.so
#8 0x00007fbd9ef78907 in ZSTD_decompressDCtx () from /home/alex/.local/share/VCV/Rack2Pro/libRack.so
#9 0x00007fbdb407ecd4 in ZSTD_decompress () from /usr/lib/libzstd.so.1
#10 0x00007fbd3e4aaa5f in ?? () from /usr/lib/dri/radeonsi_dri.so
#11 0x00007fbd3e4aaded in ?? () from /usr/lib/dri/radeonsi_dri.so
#12 0x00007fbd3ec48d71 in ?? () from /usr/lib/dri/radeonsi_dri.so
#13 0x00007fbd3ec7e79f in ?? () from /usr/lib/dri/radeonsi_dri.so
#14 0x00007fbd3e49f5dc in ?? () from /usr/lib/dri/radeonsi_dri.so
#15 0x00007fbd3e49856c in ?? () from /usr/lib/dri/radeonsi_dri.so
#16 0x00007fbdefad75c2 in start_thread () from /usr/lib/libc.so.6
#17 0x00007fbdefb5c584 in clone () from /usr/lib/libc.so.6
Same problem for me.
I have Endeavouros installed (Arch) and Bitwitg 4.
I have a machine with nvidia graphic card and everything works fine.
But in my laptop, with AMDGPU, the standalone version works fine, but the vst pro version crash when I tried to reopen de ui very offten.
With Vult modules installed is imposible to open the ui. But without them, some times I can open the vst version and works fine. But crash if I try to close and reopen the ui.
Thanks in advance.
1 Like
Ah! Big thanks for taking the time to generate that. It’s very interesting, for two reasons:
- It tells us that you’re not using
swrast, which is good because that would have been weird. - It tells us that the problem lies with the way the Rack VST interacts with the
zstdlibrary.
zstd is a compression library that’s both a part of Linux and linked into Rack. It looks like it’s also used by both swrast and your radeon drivers, and there’s a conflict between the two - the code should use one or the other, but in your stack trace we can see the system one calling into the Rack one.
I suspect it doesn’t affect standalone Rack because of differences in the way the code is loaded, as its own process (standalone) or as a shared library in an existing process (VST).
I also suspect that those who don’t see the crash are using video drivers that don’t use zstd, or don’t use it in quite the same way.
Plenty of food for thought there - thanks again, and hopefully it will lead to a fix.
4 Likes
I don’t get it. Since zstd is linked statically into Rack how could something else call into it?
The problem is that libRack.so needs to export all the symbols of all the libraries it includes, so that Rack plugins can call into those libraries.
In the case of standalone Rack, the Rack executable is tiny and does very little other than loading libRack.so. libRack.so is big and includes almost all of the Rack code and all the built-in libraries, and the plugins are small and call into libRack.so when they need to call either Rack code or library code. All good.
But in the VST case, it’s a bit different. The executable is the hosting process, which is big and pulls in lots of system libraries. It loads libRack.so, which exposes all the functions of the all the libraries that it includes. So for some libraries, including zstd, the hosting process now contains two exported versions of every function.
(You can’t just use RTLD_LOCAL to solve this, because Rack plugins need to see the symbols of libRack.so. Obviously you can’t control the way other shared objects are loaded by the host process.)
Quite how the loader decides which function to bind to for any given call, I don’t know. My worry is that you don’t get the level of control you’d need to solve this.
So the hosting process is the DAW, right? So are you talking about a DAW that also uses zstd? I guess I’m not grokking how graphics drivers could possibly come into the picture.
Mostly talking out my arse here but… I know symbol versioning is a thing, e.g. Glibc makes use of it heavily. Could it possibly be a solution to force zstd symbol versions to be N for Rack, which never changes, that can’t collide with other loaded zstd symbol versions from another library/binary?
I think you mean “I can’t prove it, but my programmer intuition is…”. imao that intuition is right more often than it’s wrong. But it’s for sure not always one or the other.
2 Likes
Is there any update on this? Is it being worked on?
There is no update here, or you would have seen it. We don’t know what Andrew is working on - I don’t think he’s allowed to post here.
1 Like
It’s a shame. Vcv Rack is the only vst I have that doesn’t stop crashing all the time. And I have bought it.
This is very, very, very frustrating. I spend all the day making a song, for nothing. Crash, crash, crash and crash again.