i’m not sure whats different but my project suddenly crashes whenever i try to open it. sometimes i get lucky and it opens, not sure why. attaching the crash report if anyone would like to take a look and see what it could be…
vcv crash.txt (909.2 KB) log.txt (46.3 KB)
All I could glean at a quick look over was that it’s crashing in the Audio thread. Maybe your project refers to an audio device that isn’t plugged in or working…or something.
It might be interesting to see your autosave/patch.json file to see what plugins/modules you have loaded, and what their settings are.
Super common problem. I usually it’s some plugin that is messing up the memory. In subtle cases the problem comes and goes randomly. Strange that no plugin names are in the crash log, maybe there never are in a release build.
Only “solution” is to figure out which module is the culprit, or only use modules from developers who don’t make crash prone software.
Plugin names won’t show up in the crash log when the crash is in some of Rack’s utility threads such as the ones for rtmidi and rtaudio. Plugins often won’t be in the stack trace for these threads, which are servicing internal queues that interface with the hardware.
I know of one existing unfixed bug in Rack’s rtmidi wrapper that will crash Rack, but that will be in the rtmidi thread, so it’s not this issue.
Are you saying there aren’t any memory corruption issues in any of the third party modules?
There are lots of crashy modules. I’ve mostly seen them crash in their code with their plugin in the callstack. Rarer that they mess up the data in Rack’s audio and midi services IME. Those are a lot harder to track down.
Not much a user can do but swap out modules in their patch to localize which modules are bad. I’m trying to remember if anyone has written a guide on how to do that troubleshooting.
thanks everyone for the help so far, i really appreciate it!
my patch seems to open and then crash immediately to desktop. if i unplug my midi hub which has the audio interface (usb streamer) and my midi controller (launch control XL) and then launch vcv rack it doesnt crash. then i can plug in my interface and run the patch, i think i usually have to plug in the interface and then reopen the patch and select “no” when it asks me if i want to clear the patch and then it will launch successfully.
i’m using one non-release set of modules, its the NYSTHI ARM build. however i was getting this crash before switching over to arm. i tried switching to arm version to see if it would improve my crash problem and it didnt, but the patch runs a lot better when it does manage to launch without crashing.
would seeing a screenshot of my patch help at all? or is the patch.json and the log files enough?
another note on my patch, i use two audio modules, one for my audio interface and another for my laptop speakers. i used to use a single audio module and select “aggregate device” but lately ive just been using two modules, one for each audio interface and it seemed to work just fine and i liked how it kept things visually separate, but perhaps this is part of the issue? i always wondered if its better practice to do a single audio module and aggregate, or two modules, or if it doesnt matter
From the VCV Manual:
Note: Using multiple Audio modules is experimental and may crash Rack or render unstable audio. Most DAWs avoid this feature entirely by restricting audio to a single input and a single output device for stability reasons, but if using multiple audio devices in Rack works with your configuration, more power to you!
interesting, thank you for this!! i hope this solves my problem… for some reason i have a feeling it wont, but what do i know… will report back
Yeah, I cannot say whether or not it is the problem, but it is definitely something that you want to rule out.
Here’s hoping that this solves it, though, because you already seem to know a workaround.
As said in the manual - yes, it definately could be, and in your case probably is. Just stick to an aggregate device, they’re rocksolid.
14: Rack(fatalSignalHandler(int)+40)
13: libsystem_platform.dylib(_sigtramp+56)
12: plugin.dylib(StoermelderPackOne::EightFaceMk2::EightFaceMk2Module<8>::process(rack::engine::Module::ProcessArgs const&)+2776)
11: plugin.dylib(StoermelderPackOne::EightFaceMk2::EightFaceMk2Module<8>::process(rack::engine::Module::ProcessArgs const&)+2776)
10: libRack.dylib(rack::engine::Module::doProcess(rack::engine::Module::ProcessArgs const&)+168)
9: libRack.dylib(rack::engine::Engine::stepBlock(int)+1236)
8: libRack.dylib(rack::audio::Device::processBuffer(float const*, int, float*, int, int)+352)
7: libRack.dylib(rack::RtAudioDevice::rtAudioCallback(void*, void*, unsigned int, double, unsigned int, void*)+168)
6: libRack.dylib(RtApiCore::callbackEvent(unsigned int, AudioBufferList const*, AudioBufferList const*)+340)
5: libRack.dylib(callbackHandler(unsigned int, AudioTimeStamp const*, AudioBufferList const*, AudioTimeStamp const*, AudioBufferList*, AudioTimeStamp const*, void*)+24)
4: CoreAudio(HALC_ProxyIOContext::IOWorkLoop()+6628)
3: CoreAudio(invocation function for block in HALC_ProxyIOContext::HALC_ProxyIOContext(unsigned int, unsigned int)+116)
2: CoreAudio(HALB_IOThread::Entry(void*)+88)
1: libsystem_pthread.dylib(_pthread_start+148)
0: libsystem_pthread.dylib(thread_start+8)
Looking at this, I’d say it’s the EightFace or one of the modules it’s controlling that is crashing.
The log file says you’re running the ARM version of rack, are you sure all of the plugins you’re using are ARM compatible?
The patch file opens for me on Windows albeit with a bunch of missing modules as I don’t have all of the available plug-ins installed.
EightFaceMk2 is implicated, but it could be some other plug corrupting memory and making it crash.
There are 6 8face modules, each one has four presets that are sent to count modula manual cv (there are 6 of the manual cv modules)
Then there are two more 8faces, each one controls master preset for each half of the patch. So the top 8fave controls every single module on the top half of the patch, and same for the lower 8face. The patch is split in half, three oscillators per side.
The master preset 8face modules, is it bad form to have them controlling the other 8face modules that control the manual cv modules? Is it better form to have the master 8face modules control the manual cv and unbind them from any other 8face modules?
I switched to arm in hopes it would crash less.
Everything is compatible, the only module series I’m using that isn’t compatible is NYSTHI, however for those modules I downloaded a nightly build that is arm compatible…
For Rack ecosystem, ARM is less mature, so if anything I would think it would be more likely to crash. Why would ARM be less crashy?
I don’t know