Might be barking up the wrong tree here, but to me this has all the smells of something else on the system interfering, which most of the time means “security software”, but sometimes can also be bad drivers, bad Windows updates, bad hardware, etc. So ignore if you will but anytime someone gets strange crashes/behaviour on Windows, the first thing I’d recommend is:
Completely turn off any 3’rd party “security software” you might be using on the machine (anti-virus, anti-whatever…) and see if that helps. Even better - completely uninstall that crap, life is too short and it always causes more trouble than it’s worth - just use the Windows builtin anti-* software, it’s perfectly fine and adequate.
Check if your Documents directory is now on OneDrive/DropBox/GoogleDrive/whatever. If it is - don’t! It causes lots of problems.
Turn off that new’ish Windows Ransomware Protection feature/thing completely, and see if it helps.
Temporarily turn off Windows Defender (the builtin anti-virus) and see if it helps.
All these things have provably caused lots of problems to people using Rack (and everything else), just search through this forum and read.
Does anyone know if Rack reads the log file at startup? If not, how does it know if there was a crash in the previous session? I’m still trying to understand why it appears that the longer I run a patch session, the more likely it is to crash on exit or the next start. That is why I was exploring autosave file size which turns out to be independent of run time. But, the log file definitely gets larger the longer the patch is run due to the autosave lines. Also, the more complex the patch is, the larger the log file becomes. So, I’m wondering if as the log file gets large, if there might be some startup timing issues that might arise from having to read a large log file to find out if there was a crash.
Looking at the code, it appears that it does read the log file to determine if rack terminated normally last time it was run by seeking to the end of the log file and checking that it ends with “END”. If I;m reading it correctly, I think this is done before the patch is loaded.
Ah, I see that. My crash logs do not have an “END”. I had missed that since my old text file editor I use for examining text files sometimes misses the last line in the file before the EOF. No wonder I could not figure out how Rack detected a crash. Thank you!
Okay, for real here! I know I said I was suspending my tests to figure out which plugin, if any, is causing my sporadic Rack standalone crashes, but, I have continued trying to systematically determine if any plugin is responsible.
I am going to assume that if no module is implicated in the crash log, that it is not a module causing the problem. Since I can always just try a second time to launch patch after Rack tells me the previous session crashed, that is what I will do. I will just live with it.
Again, a personal choice, but I am not turning off AV software. The crashes are so incredibly intermittent that it would be very difficult to determine if the AV is the source, even if I turn it off.
This is probably the last I will post in this topic unless some new information comes to me
When I do get a crash on exit stack trace, it always implicates RackScrollWidget . Is this a known issue in Rack V2 with a distinct cause and resolution? I searched here and found several references to this problem in V2 but I did not see a definitive answer.
At the risk of being ridiculed (as this is sort of weird), my current working hypothesis is that no plugin or module is causing my crash. The more modules I have in my patch, the more likely it is to crash. This is not a thread setting issue. What it seems to be is that I am moving the mouse cursor into the patch before the patch is fully loaded after clicking on the Rack icon in my taskbar or fully terminated after clicking the X in the upper right Rack window (for Windows) to exit. This complex patch can take several seconds to fully load and initialize. I have not been able to induce a crash on launch if I do not move the mouse cursor from the taskbar icon until the patch is fully loaded nor move from the application X exit button until Rack has totally terminated.
As you may remember, when there is a crash on load or exit and I am lucky enough to have a crash log, the stack trace always implicates RackScrollWidget. When I move the mouse cursor into the patch during load or exit, I do have to cross over at least one Rack scroll bar.
Has anyone ever seen such behavior, or am I imagining this pattern?
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()
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.
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.
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.
@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).
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.
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?
