Which plugin (if any) is crashing Rack 2.1.0 standalone patch?

I can certainly upload the patch, but it does use the Harmony and Arpeggiator modules by Squinkytronix that are not in the library yet. Do you still want the patch given this?

By the way, I was going to wire up the startup delay module so that you could do exactly what I was doing. Strangely, that crashed Rack and once reloaded, the RCM CV Momentary master reset button will also crash Rack when it is pushed. So I went to another of my variations of the patch that is known to eventually crash Rack and the momentary switch reset works fine. One of the reset crashes did have MixMaster in the log but I failed to copy the log to another name and it got written over. I really don’t understand what is happening, but this is more evidence that there is probably a Rack bug as Marc and other have described. BTW, both the delay start and the momentary switch go into a Count Modula Boolean Or Gate A and B inputs and the OR output goes to the CLKD RESET. Here is a picture:

Rack startup delay

I will try to figure out why things are crashing after I reconnected the delay module to the patch.

Thanks for taking a look at this.

I’m not sure what was happening. As long as the Startup delay and the Boolean OR modules are not hooked up to anything, the patch is not crashing when the Momentary switch is clicked. But, the Momentary switch is now going directly to the CLKD RESET input. I may have had a variation where the Momentary was going to the OR B input and nothing was connected to the OR A input. Seems like that should not cause a problem either. Oh well, probably inexplicable and probably related to the crash bug this topic is about.

Here is a screen grab of the problem patch, but with the Startup Delay and Boolean OR modules not hooked up. The Momentary switch is connected directly to the CLKD RESET in. This is the variation that took me 4 hours to get a crash, indicating that the root problem is still there but not as likely to be encountered without the resets during load and initialization.

Loudnumbers is crashing too…

I edited 70 patches this morning to remove the startup delay reset on load module. In doing so, a simple edit of removing two modules, reconnecting the Momentary switch output directly the the CLKD RESET input was enough to crash Rack about a dozen times. This seems consistent with @marc_boule 's bug report he mentions above. Mostly the log did not implicate any modules, but a few time random modules that are in the patch were implicated. I do not think this really has anything to do with those modules. I also do not think there is a problem with the Count Modula Startup Delay and the Boolean OR or the Momentary button modules.

This is the last I will post about these crashes until the next release of Rack comes out and I will retest at that time. Thanks to everyone who has advised on this topic.

I’m not sure which plugin and module this refers to, but since it is not in my patch, this may need to be reported or discussed elsewhere. Thanks for reporting it here though.

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:

Hora VC Delay and Resonator not working in VST / Windows - Plugins & Modules - VCV Community (vcvrack.com)

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