HTMLTexture (DX9) Exception

The HTMLTexture Node crashes after a short time of being loaded with the following exception:

vvvv.exe-exception-2017-01-09.log (74.0 KB)

It is used with a local file as URL.

EDIT: Sorry false alarm. Had to do with warnings that the webapp was throwing. Those Warnings actually had nothing to do with the functionality of app. There could always be warnings in the console, so that the Node crashes because of a warning message might not be the best behaviour.

EDIT2: Nope that might have been wrong. Still crashing, with the same exception.

Best
d0t

can you share the local file so we can reproduce?

Hi Joreg,

i made a sample patch where the web app still produces warnings, i could suppress them but then the patch is not throwing the exceptions. Those warnings were ARIA (Web Accessibility) related and thrown by the web framework by default if those ARIA specifications weren’t correctly implemented. I don’t need ARIA for my interface and thats the reason why i left it out. But the web app then reminds my with those Warnings that i haven’t used it.
Anyhow i have to admit that i cannot reproduce the exception every time. Sometimes the exception gets thrown sometimes not. But furthermore at least on my setup the patch crashes after a while without any exception. Maybe after 10 mins or a bit longer.

HTMLException.zip (216.4 KB)

is this with beta35?

Yes, beta35

First of all sorry for replying so late. Just had a look at your patch and it seems you’re running out of memory. At least at my computer after running the patch for a while the Error output of the HTML renderer says that it is out of memory. VVVV doesn’t crash though. However the problem seems to be the repeated DOM updates you make with that Blinker node. If you remove that connection the patch runs fine. You can watch the memory by opening up your task manager and navigating to VVVV.Nodes.Texture.HTML.exe . The funny thing is that if you open the patch with the DOM update disabled and later on connect the blinker it runs just fine, without the memory going up. If you start it with the DOM update enabled the memory of one of those VVVV.Nodes.Texture.HTML.exe processes goes through the roof immediately. Seems to be an issue either in the used .NET wrapper or in CEF itself. Using a memory profiler I couldn’t see any leaks in our code. So I guess you’ll have to find (and live with) a workaround. :/

This topic was automatically closed 365 days after the last reply. New replies are no longer allowed.