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.
Hi,
Have you tested with version 4.3 Beta2 ? You’ll need to install with Flatpak.
I’m using it with PipeWire (without the dedicated GPU) and it seems to work now 
Let me know!
It does the same for me unfortunately. Are you running Arch?
Yes still on EndeavourOS. Are you using PipeWire too?
As we were able to show, the problem was related to graphics. Maybe it’s also due to the Nvidia updates (on my side at least) difficult to say…
I was using Jack when it started and have since moved to pipewire but it didn’t make any difference.
I’ve given up hoping this will be fixed to be honest.
Yes still hoping that it will be fixed in the next update…
Have you tried with Cardinal?
Yeah, it works fine with the VST2.