Hey!

Just a follow up here.

I think this issue may have been conflated with another similar one that we had previously fixed in VDMX.

Before I dive in any further, I will note that this appears to not be an issue so far in the Vuo 2.0 beta, so you may want to close this issue out... but if you plan to update the 1.2.x branch, feel free to follow up with us about this.

To the best of our knowledge, this doesn't appear to be a bug with VDMX. Here's the high-level summary:

Sometimes (rarely), when loading vuo comps (as dylibs- this does not appear to be an issue when running vuo comps as separate processes) using the c++ API, the image produced by vuo is all-white. When this happens, the following appears in the console log (VDMX's console log, as the vuo comp is being run within the vdmx process):

[38;5;112m# pid=941 t= 34.6284s VuoHeap.cc:52 sendErrorWrapper() VuoRetain was called for unregistered pointer 0x61400008e380 "(not allocated)"[0m [38;5;112m# pid=941 t= 34.6287s VuoHeap.cc:52 sendErrorWrapper() VuoRetain was called for unregistered pointer 0x61400008e380 "(not allocated)"[0m [38;5;112m# pid=941 t= 34.6289s VuoHeap.cc:52 sendErrorWrapper() VuoRelease was called for unregistered pointer 0x61400008e380 "(not allocated)"[0m [38;5;112m# pid=941 t= 34.6451s VuoHeap.cc:52 sendErrorWrapper() VuoRelease was called for unregistered pointer 0x61400008e380 "(not allocated)"[0m

i don't know why these errors are being thrown, as every single call to VuoRetain()/VuoRelease() in all of our codebases explicitly checks to make sure that the ptr being retained/released is non-null, and the ptrs they're getting are coming directly from calls to the Vuo SDK. if this is being thrown from where i think it's being thrown, the stack looks something like this:

VuoImage tmpImg = VuoImage_makeFromJson(someJSONVal); if (tmpImg!=NULL) { VuoRetain(tmpImg); returnMe = (id)[_globalVVBufferPool allocBufferFromVuoImage:tmpImg]; VuoRelease(tmpImg); }

(allocBufferFromVuoImage: further retains the passed VuoImage, and doesn't release it until the VVBuffer using it is released. this is why you're seeing two "VuoRetain()" calls followed by one "VuoRelease()" call in very quick succession, with the final "VuoRelease()" call some time later when the VVBuffer that was retaining the VuoImage is finally released)