If you could share your patch that would be great. I’d like to do some investigation of my own and I’ve not been able to recreate the problem even with the startup delay, momentary button and boolean OR connected as you showed in your screen capture.
Organic Harmony E-minor with start delay.vcv (13.6 KB)
log.txt (91.7 KB)
Sure. Attached is the patch file. Note, this was a functioning version that did not have the delay reset button modules attached to each other or to CLKD. I have not been able to get a crash with that patch. For this upload, I saved the patch into a new name, connected up the delay/momentary/OR modules and connected the OR out to CLKD reset as shown in my screen snip above. I then saved the file. Then I clicked on the Momentary and Rack immediately crashed. Attached is the log file from that crash. As you can see, there is a stack trace but no module is implicated.
As a reminder, I am on Win11 and running Rack 2.1.0 . Note also, @Squinky has done extensive debugging on my patch under Windows but has never been able to create a crash. All of the modules in the patches came from the VCV library with the exception of Squinkytronix Harmony and Arpeggiator which are development builds done by him and Meander which I build locally with the 2.1.0 SDK. But, I have reverted to the library build of Meander for testing over the past month and still had the crashes.
Also, it seems to be a lost cause looking for modules causing problems. I have done an extensive set of experiments where I systematically removed all brands of plugin modules, one plugin at a time and could not totally eliminate the crashes. But, the more modules I have in the patch, the more likely I am to have a crash. I usually have to launch, exit, launch… from 1-30 times to get the crash on a crash prone patch like the one attached.
@Squinky has done a super job of debugging as well as address sanitizer checks, focusing on Meander, Harmony and Arpeggiator but also looking at my complex patch. Nothing serious has been found, based on my limited understanding of those tools.
I updated to Rack 2.1.0 immediately after it was pre-released on 2/26 . Squinky and I began our conversation on this around 3/26 because I was testing Harmony and Arpeggiator in variations of the attached patch file. As @marc_boule mentioned, the Rack bug he identified and provided a fix for tends to show up when editing patches. At the time I started having crashes, I was doing a lot of editing. Along the way I had many false leads as crashes seemed to be associated with whichever modules I was editing at the time, but I truly believe that there is no plugin/module causing these crashes. I advise that you not take that path of trying to find a problem in a plugin.
Well, this is probably long enough. Thanks for looking at this. I just don’t think you are going to be able to find anything related to a plugin.
3 Likes
Thank you.
There are quite a few modules in that patch that I don’t have. I did not download any of the missing ones and unsurprisingly, the patch does not crash for me.
1 Like
Yep, this type of crash is hard to sort out. The simplest patches never crash on me. There seems to be a sensitivity to large heterogeneous patches, but I can’t sort it out. I have not had a crash since I removed the startup delayed reset, but I do not think this has anything to do with the modules I used to implement this startup reset.
Thanks for testing though.
1 Like
Hi,
I’ve noticed Rack 2 v2.1.0 Pro is crashing (CTD) as soon as I try to bring Millenial module (from Hora-Processors plugin v2.0.1, lastest in date), this crash occurs everytime.
No issue against Rack 2 v2.0.6 standalone, however (but DAW crash from Rack 2 FX as VST2 effect plugin both REAPER 6 or Ableton Live 11 Lite).
- Windows 10 Pro 21H2 (x64) French localized.
- VCV Rack 2 Pro Edition.
- REAPER 6 v6.57 (64-bit), Ableton Live 11 Lite v11.1.1 (64-bit).
I reported similar here, no response on it yet:
1 Like
Is there open-source for this/these module(s)? As I’m reasonable at code scanning.
Nope, they’re free and commercial versions of Hora, but closed/private source.
I originally created this topic due to crashes I was having in Rack 2.1.0 . There were multiple theories as to what was causing the crashes, including one bug report that was supposed to be fixed in the next version. This morning I tested Rack 2.1.1 under Windows with a known problem patch from a couple of months ago. I was able to cause the crash several times.
My workaround from that time was to remove the startup delayed global reset from 70 of my patches. I have not had a single crash in these past two months, so it still appears that my crash was caused by doing a STARTUP DELAY trigger with a delay of 1 second and sending the trigger to CLOCKED RESET in and sending the CLOCKED RESET out to all modules in the patch that have reset inputs.
It still appears to me that there is no problem with the STARTUP DELAY module, but rather that sending a reset to a lot of modules 1 second after Rack is started causes the crash due to some initialization not being complete 1 second after startup.
This type of crash is not a problem for me since I do not use the startup delay reset in any patches any longer.
This is just my observation and opinion, but Rack V2.1.1 is more sensitive to the delayed start reset crash than was V2.1.0 . And it is much harder to recover from such crashes. Both yesterday and today I had loaded my problem patch from a couple of months ago and ended up crashing Rack in a way that I could not reliably start back up. This to me seems to imply problems in the autosave files. I was able to somehow get back up without deleting the autosave folder contents, but it is unclear what I did to do that. Thus, I do not feel inclined to mess around with this any longer. BTW, the log file does not implicate any module crash but rather indicates a Rack crash, just as two months ago. But, two months ago I could always just try to launch Rack again and Rack and the patch would load fine. That is no longer the case.
I wonder if this new sensitivity is related to the V2.1.1 init and load manifest order changes since my old crash sure seems to be related to order of initialization or some such.
1 Like
send patch to support?
1 Like
I created a folder inside patches_factory to use my own Surge patches inside Surge player and VCV crashes when I use em.
Not all ; I have a simple sine patch that loads properly, and might be one or two others but the majority makes VCV Pro 2.1.2 crash.
[92.563 info src/app/Browser.cpp:90 chooseModel] Creating module Surge for Rack SurgePatchPlayer
[92.563 info src/SurgeModuleCommon.hpp:96 showBuildInfo] [SurgeRack] Instance: Module=PatchPlayer BuildInfo=os:win pluggit:fb9c9a2 surgegit:5270cfb9 buildtime=Dec 4 2021 19:24:35
[92.570 info src/SurgeModuleCommon.cpp:105 setupSurgeCommon] [SurgeRack] storage::dataPath = 'C:/Users/The Void/Documents/Rack2/plugins/SurgeRack/build/surge-data/'
[92.570 info src/SurgeModuleCommon.cpp:106 setupSurgeCommon] [SurgeRack] storage::userDataPath = ''
[92.599 info src/app/Browser.cpp:94 chooseModel] Creating module widget Surge for Rack SurgePatchPlayer
[98.010 fatal adapters/standalone.cpp:48 fatalSignalHandler] Fatal signal 22. Stack trace:
16: 0x0
15: raise 0x7ffe7485abe0
14: abort 0x7ffe7485f1e0
13: wassert 0x7ffe7485d210
12: ZN16SurgeSynthesizer25prepareModsourceDoProcessEi 0x7ffde57085e0
11: ZN16SurgeSynthesizer14processControlEv 0x7ffde5709c20
10: ZN16SurgeSynthesizer7processEv 0x7ffde570a690
9: ZN16SurgePatchPlayer7processERKN4rack6engine6Module11ProcessArgsE 0x7ffde57942a0
8: ZN4rack6engine6Module9doProcessERKNS1_11ProcessArgsE 0x7ffdee635c10
7: ZN4rack6engine6Engine9stepBlockEi 0x7ffdee631070
6: ZN4rack6engine6Engine9stepBlockEi 0x7ffdee631070
5: atomic_flag_test_and_set_explicit 0x7ffdf2e711d0
4: pthread_create_wrapper 0x7ffe69a14c20
3: beginthreadex 0x7ffe7486ae30
2: endthreadex 0x7ffe7486af80
1: BaseThreadInitThunk 0x7ffe762e7020
0: RtlUserThreadStart 0x7ffe76602630
Am I the only one to get this ?
where do you get these patches that crash? could you put one here so others could try it?
The patches are my own, all are made in SurgeXT 1.0.1
sorry - I can’t figure out how to load this file in the module. The instructions say this:
We follow the same load/browse semantic as SurgeWTOSC.
FIXME this section needs improving.
@baconpaul is that an attempt to be funny? 
1 Like
Don’t be sorry, I also had to search for a while to find the right folder, you have it when right-clicking on the module → info → open plugin folder
The full directory is C:\Users****\Documents\Rack2\plugins\SurgeRack\build\surge-data\patches_factory
I added a “User” folder inside the directory. It’s possible that it doesn’t like it since user presets are in another directory in the VST files. It’s also possible that it doesn’t like SurgeXT patches and would prefer Surge patches ?
I didn’t find anything on this issue so I’m sure there is something so obvious and dumb I didn’t think about yet, and everything will work. Maybe
well, I know there are people here who use that plugin. I don’t, which is why I have no idea how to load a patch.
we’ll see, I posted an issue on Github. I tried with patches made with Surge 1.9, VCV crashes as well.
Me neither usually, but it would be very useful to the rack I’m working on
I found a Discord post from 2021 from @baconpaul
They use the 1.7.1 dsp engine
So it has to be 1.7.1 patches, or at least patches that do not use XT or 1.9 stuff
That’s a shame.