Got a difficult bugger I can’t reproduce outside of a complicated commercial project that I can’t post here. I probably haven’t provided enough information to isolate the bug but maybe this information will be helpful later if other users run into a similar bug and can provide more details.
Latest beta 38.1 x64
The bug is a total freeze of VL and vvvv UI with no exception dialog. Can only close with task manager. It occurs when I open a particular class for editing in the VL editor. It didn’t happen when I was building the class a few days ago, only when I go to reopen the class for further editing the next day.
What’s weird is that the class is actually running fine and producing output including skia drawing. Its only when I try and open it in the VL editor that the freeze occurs.
If I instance the main process in vvvv, VL is ‘running’, open the class to edit than the freeze occurs
If I instance the main process in vvvv, VL is ‘stopped’,open the class to edit than the freeze occurs
If I open vvvv.exe and don’t load my patch, open the vl editor and open the vl file than the freeze does not occur.
Lets call it class A.
Class A has create, drawUI, update and split methods.
A single instance of class A is created at start and put into a pad.
The update method is run every frame in my main process.
DrawUI method is called only when the UI should be visible.
The same single instance of class A is passed into a spread of other objects (also classes, lets call them class B) where the split method of class A is called. The split method only reads some pads like you would expect. The freeze occurs even when no Class B objects exist (spreadcount 0).
IF I go into class B and delete the class A split method (and the associated link on the main patch that passes the single instance of class A into class B) then there is no freeze.
Instead I pass in the required primitive data and don’t use the split method.
Looking closer it also seems the spread of Class B objects gets passed into the update method of Class A, where the Class B split method is called. Maybe this is creating a recursive situation?
However I thought if you are only using split (read) operations then you shouldn’t run into this kind of problem as you aren’t changing state in multiple places.
Note there is no pad storing the objects inside each other.
I made a little test patch to see if I could get the same freeze with a similar recursive setup but no freeze.
I had talked to Anton about this earlier and thought at the time it was something to do with a stopwatch node but further testing indicated that wasn’t the case.