Not shaming, but in case anyone else has a problem. I was working on an older patch. It was crashing vcv hard every 20 minutes or so. I started replacing older modules for a few hours to finally find AS Tri-LFO was the culprit. Once removed the crashes stopped. On W11 Intel i9 and up to date rack.
4 Likes
Thank you for the info, good to know!
Can you tell whether you also get these crashes when using AS TriLFO in a new patch? Or is there some connection to prior versions of VCV Rack?
I just tried the AS TriLFO in a new patch and had
no crash in about half an hour yet.
so it could be something about the old patch.
1 Like
Yeah, I use TriLFO very often and have never ran into an issue with it. Win 10 and latest VCV Rack Pro.
1 Like
I donât know why, but removing the TriLFO stopped the crashing, but adding it back in did not make the crashing return. Thanks for the comments, and sorry for the false alarm.
2 Likes
No need to apologize, IMO, the issue your were facing was probably real nonetheless.
I think there always is a risk of unusual behavior when using older modules. A short while ago, I created a patch (Ambient Drift) that started crashing periodically after loading Amalgamated Harmonicsâ Fifths and Fourths.
Unfortunately, I was not able to figure out any root cause, so I decided to just finish up the patch (with frequent âSave Asâ steps in between), record the video/audio and move on.
Even though nothing has been proven, the experience left a tiny psychological mark with me that there is âan issueâ with the module, and I have not loaded it since.
Another example is the problems (crashes) I encountered with a couple of dBiz modules a couple of years ago. Even though they may be perfectly fine most of the time, now I just shy away from them for some reason â almost like a prejudice. I know that this is a rather illogical reaction, because some of these modules are actually quite powerful.
It can be very difficult (impossible) for a VCV user to know which module is causing crashes. There was a very smart user who was testing my âArpeggiatorâ module, and thought it was causing crashes in his system. Turned out it was some other module.
There are things developers can do to make sure this doesnât happen. There are programs like address sanitizer and valgrind that can find the kinds of memory corruption issues that often cause these mystery crashes. Very thorough unit testing can find this. Also, experienced developer may have learned how to avoid these issues in the first place.
The problem is not limited to older modules, I donât think.
1 Like
I assume you mean the developer can control whether their own plugin can cause corruption.
But there is nothing a developer can do to stop some other plugin from causing corruption that may be misinterpreted as a bug in the developerâs plugin. Which is basically what you said in your first paragraph.
Yes, right, your are correct. Well, I guess you could try to be immune to otherâs memory corruption if you created a new process and ran most of your plugin in there. But that would awfully extreme, difficult, inefficient, etcâŚ
So, yeah, practically speaking you can make plugins that donât corrupt memory or otherwise crash themselves, but you canât do much to keep other plugins from corrupting memory and causing your own plugin to crash VCV.
At least that is my belief.
2 Likes