Hotswap issues

vvvv gamma bug
1

hellllo,

i’m currently trying to isolate some unexpected behaviour i’m experiencing in a larger project…

i’m patching a lot of custom (de)serializers since i’m communicating with some API.
While the process (learned from HowTo Register Custom Serializer helppatch) is supernice, i’m often interrupted by a failing hotswap that only can be fixed via restart of vvvv.
I think, the issue arises when doing changes to the serialized datatypes, like adding a new pad or so. It does not only happen when the signature changes.

In those cases, i see a outdated message in the log like this one:

message 
REASON: Outdated, RestoreState

System.Reflection.TargetInvocationException: Exception has been thrown by the target of an invocation.
 ---> VL.Core.RuntimeCommandException: OUTDATED: o: 0(-1) p: 0(-1) H1
REASON: Outdated, RestoreState
   at VL.Core.RuntimeCommandException.Complain(String exceptionMessage, RuntimeCommand runtimeCommand)
   at VL.Lang.Platforms.SwapHelpers.React(NodeContext nodeContext, SwapTroubleReaction troubleReaction, String innerMessage, String outerMessage, String exceptionMessage)
   at VL.Lang.Platforms.SwapHelpers.OnReport(NodeContext nodeContext, String what, HotswapTrouble hotswapTrouble)
   at VL.AppServices.CompilationHelper.Report(NodeContext context, String what, HotswapTrouble hotswapTrouble)
   at VL.AppServices.Hotswap.SwappableVLObject`1.__Restore[TStateClass]()
   at _Unibonn_Model_.unibonn.H1_CProgram_.Draw_(H1_C __self, Matrix Transformation_1_In, Matrix Transformation_2_In, Single Offset_In, IGraphicsRendererBase& entity_Out, IGraphicsRendererBase& led_Out) in F:\projects\unibonn\VL\Unibonn.Model.vl.1.cs:line 573
   at _Unibonn_Model_.unibonn.H1_C._Unibonn_Model_.unibonn.ILayout_I.Draw(Matrix Transformation_1_In, Matrix Transformation_2_In, Single Offset_In, IGraphicsRendererBase& entity_Out, IGraphicsRendererBase& led_Out) in F:\projects\unibonn\VL\Unibonn.Model.vl.1.cs:line 550
   at _unibonn_.unibonn.DrawScreen_KW8O2B5HgQrPcyNNOcAwfUProgram_.Update(DrawScreen_KW8O2B5HgQrPcyNNOcAwfU __self, Screen_R Screen_In, Matrix Transform_1_In, Matrix Transform_2_In, Entity& Output_Out) in F:\projects\unibonn\unibonn.vl.1.cs:line 384
   at _unibonn_.unibonn.Schaufensterbespielung_C4kMdVafyNKP0fTtwAYycZProgram_.Update(Schaufensterbespielung_C4kMdVafyNKP0fTtwAYycZ __self, Screen_R Screen_In, Matrix& Screen1_Transform_Out, Matrix& Screen2_Transform_Out, Entity& Output_Out) in F:\projects\unibonn\unibonn.vl.1.cs:line 974
   at _unibonn_.unibonn.Schaufensterbespielung_C4kMdVafyNKP0fTtwAYycZ.Update(Screen_R Screen_In, Matrix& Screen1_Transform_Out, Matrix& Screen2_Transform_Out, Entity& Output_Out) in F:\projects\unibonn\unibonn.vl.1.cs:line 943
   at _unibonn_.unibonn.App_Q6TvMZdzRekNqNcFam0MZOProgram_.Update(App_Q6TvMZdzRekNqNcFam0MZO __self) in F:\projects\unibonn\unibonn.vl.1.cs:line 33
   at _unibonn_.__auto.unibonnApplication_KjcIrOxd9AkLDjJANwQAC6Program_.Update(unibonnApplication_KjcIrOxd9AkLDjJANwQAC6 __self) in F:\projects\unibonn\unibonn.vl.1.cs:line 21
   at InvokeStub_unibonnApplication_KjcIrOxd9AkLDjJANwQAC6.Update(Object, Object, IntPtr*)
   at System.Reflection.MethodBaseInvoker.InvokeWithNoArgs(Object obj, BindingFlags invokeAttr)
   --- End of inner exception stack trace ---
   at System.Reflection.MethodBaseInvoker.InvokeWithNoArgs(Object obj, BindingFlags invokeAttr)
   at VL.Lang.Platforms.RuntimeInstance.Step(ITargetCompilation compilation)
   at VL.Lang.Platforms.RuntimeHost.StepInstances(ITargetCompilation compilation, Boolean& hadToKill)

At the same time, the registered serializer patches stop running.

After some F8F5 or recompile from the contextMenu, i can see such messages in the log:
image

sadly, i wasn’t able to reproduce this behaviour in a simple patch i could share… the only thing i could offer is sharing the bigger patch privately.

is there something i could or should check in my patch? does this ring a bell somewhere? something i could test on my site?

thanks in advance!

2

digging a bit here makes me ask if RegisterServices isn’t called often enough?

i just placed a logger like so
image
and only see the logmessage on startup of vvvv and not when doing F8-F5.

most of the times, a recompile restores everything and i also see the logmessage.

side quest:
why does the debug window close on recompile?

3

here’s a small demo i recorded just after startup. the only thing i do here is opening the H1 node which immediately leads to the issue:

4

We did fix something in this area on the 8th of July, could you do a quick test with a current preview build? Just that we know whether we need to follow up on this or not.

5

i’m on 6.7-0113

the error happened also with older versions

6

Ok thanks. I’d also expect RegisterServices to get called on F8/F5. We’ll try to reproduce that one on our end.

7

another find, maybe related:


what isn’t visible in the video: at sec. 23, when the debug window closes, i pressed recompile in the context menu.
Hotswap.vl (24.5 KB)

8

Thanks for the patch. Should work correctly in upcoming preview builds.

Background: Our compiler didn’t track the dependency from the application patch to all the referenced startup / RegisterServices patches. This in turn lead to all sorts of inconsistencies forcing the user to to re-compile the entire app.

2 Likes
10

super nice, thanks! it runs super smooth now.
i have the feeling recompilation is even quicker now.

11

upsi, it happens again…

but only for one of my datatypes.
The only special thing that differentiates this one from the others is, that it has a videoplayer inside. Can that be related somehow?

image
image1235×374 38.8 KB