- macOS 10.13
Steps causing the bug to occur:
Was about to test Vuo & MMV intergration, and it keeps crashing shortly after start up. This began after installing MMV, and keeps happening even if it is closed. The only other reason I could think of is I updated my 3rd Party ISF Directory while Vuo was offline... but this doesn't sound like the reason to me. Reinstalled program with no luck either, any ideas? No error messages, was working beforehand. Specs below:
MacBook Pro (Retina, 15-inch, Mid 2014) 2.8 GHz Intel Core i7 16 GB 1600 MHz DDR3 NVIDIA GeForce GT 750M 2048 MB & Intel Iris Pro 1536 MB High Sierra 10.13.6
Vuo Community Edition
Magic Music Visuals Performer Edition
Is it Vuo or MMV that is
Is it Vuo or MMV that is crashing? What exactly do you mean when you say MMV and Vuo integration?
Do you get any crash reports? When a crash happens, macOS may pop up a dialog asking if you want to report the crash, and if you say yes then it will show you the report. Or you can find recent crash reports by opening Console.app, clicking on Crash Reports in the sidebar, and looking for anything related to Vuo or MMV. Either way, if you could attach the crash report(s) to this discussion, we could see what clues they give as to why there are crashes.
It is Vuo that is crashing. I
It is Vuo that is crashing. I was looking to connect the two via Syphon to test out different workflows, but this issue leaves me having to choose between one or the other.
Thank you for looking and pointing that out, here is a crash report!
The only other reason I could
That does seem to be the change that led to the problem. According to your crash report, Vuo is crashing while compiling ISFs. There doesn't seem to be any particular ISF that provokes the crash, but just that Vuo has trouble compiling so many at once.
We were able to confirm the crash and will investigate further. Thanks for letting us know about the problem. As a workaround, you could install a smaller number of ISFs.
Please accept my humble +1 on this bug report. I've got huge piles of ISF files but I have to be pretty selective about which ones get loaded by Vuo or I get a crash shortly after launch. Several times I have methodically attempted a split-half search to identify the problematic ISF file(s), and I can confidently say that the behavior is non-deterministic. As you say, it's not a problem with specific ISF files, but rather with how many I try to load - seems like a race of some kind.
I've attached a crash report, in which thread 84 is the crashed thread. I bet this problem could be mitigated (but not solved) just by capping the number of threads used to compile ISF files to the number of available cpu cores. Generally speaking, using lots of threads for this work makes sense as it's (probably) mostly I/O bound, but with more threads comes more opportunities to trip over any improper memory handling, etc. But you know all that :)
Thanks a bunch! I'm a big fan of Vuo, and your small team does a great job interacting with the community.
I really thought
I really thought DispatchQueue would know how to do this by now (i.e. accept a concurrency param), but nope. Even still, I think I validated my theory with this one character change:
Of course this is not a good change because it blocks the main thread and makes startup take longer (much longer with lots of ISF modules); however with this change Vuo is stable with 1,236 ISF modules available...
There's a little more info that might help you pinpoint the underlying problem: with this change, if there are unsupported ISF modules, I still crash sometimes after taking action in the dialog that is thrown about the unsupported module. Once the only modules being loaded are supported, it launches with no crash every time.
Here's a screencap of the crashing with unsupported modules: https://youtu.be/kkrAhVJbeVg
Wow, thanks ClapsOn2and4 for
Wow, thanks ClapsOn2and4 for compiling Vuo from source and testing that change. I tested on my system and got the same results: no more crashes (at the expense of much slower launch).
Here's another way to cap the number of threads:
As you hypothesized, it reduces but does not eliminate the crashes.
I tested our work-in-progress code to see if we might have already fixed the bug (since we've revised a lot of the code related to loading ISFs and other modules). From my testing so far, it looks like we probably have. We'll plan to do more testing and include those changes in Vuo 2.5.0 some months from now.