I suspect this is a timing issue. If things happen in this order it crashes due to stepi()ing a module that isn’t fully allocated yet, if it happens to do it in a different order it starts fine. It seems on reopen the context is fully initialized so opening patch after open works, as Rack startup does not interfere with the timing of loading the patch. My best hypothesis on what causes this given it is sometimes crash and sometimes open fine on start which, as you say’ seems unrelated to any module, but how Rack starts up and at same time opens patch to get it ready to step()
1 Like
have you tried running the same stuff under a different O/S? ie linux
No, I do not have another OS system set up. Actually, I have a Debian linux gaming laptop, but I have not booted it in a couple of years. Rack V1 is installed on it. I probably should just move on and accept these occasional crashed since a 2nd try always launches the patch.
I don’t think you should move on and accept it. I’ve seen more than a few crashes on exit, an apparent interaction with two different plugins/modules (I won’t include my issues with the VST) and I think it seems reasonable to assume there is at least one bug causing crashes and that shouldn’t really happen. You seem to have enough knowledge to look into it properly and potentially give reproducible steps and further information, and with that a fix might happen.
I’m starting to wonder if there’s some major refactoring going on at the moment. It’s been a while since an update and the last one posted here didn’t get pushed to the release channel, and support seems quiet from my own experience and reading others here. I’ve reported a few serious reproducible bugs in the pro version, one for it not working at all in a particular daw and another which crashes the whole OS, so maybe others have as well and there’s some work being done at the core of things.
1 Like
Thanks for the encouragement. I suppose as long as I can think of one more controlled experiment to run, I will keep trying. This is a bit like “design of experiments”.
I’m fairly confident that the bug is sensitive to complexity and heterogeneity. I.E., the more modules there are as well as the more CV senders and CV receivers there are in the patch, the more likely it is to crash. It very probably is a startup issue where some modules start sending before all receivers are initialized or vice versa. NaN and ±INF could be involved, i.e., invalid CV values.
1 Like
I’ve found and reported a bug to VCV and Andrew has confirmed to me it’s fixed for the next release.
2 Likes
That is really interesting. At the risk of crying eureka too soon, I may have located the stimulus for my crashes, but probably not the root cause. A couple of weeks ago I began adding a Count Modula “Startup Delay” module to my patches with which I have a 1 second delay from startup and then send a reset to my master CLOCKED module which then outputs the reset to everything in the patch that accepts a reset. The crashes started at about that same time. After disconnecting the delayed reset from the patch modules, I have not been able to induce a crash after a couple of hours of testing.
There is probably something that happens in the Rack patch startup that is sensitive to state changes during the patch initialization phase or some such thing.
Recently I certainly thought that copy-pasting or insertion or deletion of modules caused the crash, so maybe there are some upcoming fixes for Rack that will fix a number of secondary effect crashes.
@k-chaffin has been using 2.1.0 and getting crashes. Do you think the crash your are talking about was fixed in 2.1.0?
1 Like
Thanks for asking. I was wondering the same thing.
1 Like
@Squinky , @k-chaffin the bug I’m referring to is still present in 2.1.0, and by “next release” I was meaning to say that it’s most likely the next release after 2.1.0
@k-chaffin I know you have spent a lot of time on this, and if ever you want to test a bit more to see if the bug you’re experiencing is the same as the one I reported, just message me and I’ll send you the source code fix (you’ll have to rebuild Rack obviously for it to take effect though).
2 Likes
Thanks Marc for the clarification, which is what I thought you were implying. I have avoided building Rack myself as that just isn’t where I want to put my energy and efforts, but thanks for the offer.
1 Like
Hmm, there’s nothing special in the startup delay module. I just tried it connected to the reset input of Clocked which I had driving 64 sequencers and could not get it to crash despite the UI still drawing when the reset pulse occurred. Can you share your patch?
1 Like
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:
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