Windows10 home, vvvv_50beta35_x64, ZeroMQ v.0.5.4 downloaded from github releases.
I was planning on using zeromq for communication between multiple vvvv instances and computers.
It is just a fraction of a larger patch which I cannot share.
The repective ZeroMq part looks more or less like this and is receiving only one single value:
vvvv hangs then crashes. No exceptions dialog and nothing in TTY.
Taskmanger says (sorry german):
Mindestens ein Thread von ‘vvvv.exe’ wartet auf die Fertigstellung von Netzwerk-E/A
From the log it seems, that there is in fact a NetMQException coming from inside the lib this pack is using. This is worrisome, because you are the first one to have an issue like that (at least to my knowledge).
It is hard to say, why this happens to you, and the exception handling from vvvv is even weirder. But I guess that is because there are many async things going on in the lib, which make it hard for vvvv to show the exception to the user.
So I guess we need more info, to get to the bottom of this. Sorry that I cannot provide any better intuition than that:
What does your network look like? Is this fault similar, if all instances are on one machine only?
Firewall?
Is the port itself playing a role, or do all ports eventually cause issues for you?
Are there more senders to the port you are using? Are they sending non-zeromq-data?
Does the patch you screenshotted above reproduce the error, or is it only the bigger patch you mentioned?
The error occured when communicating only locally (also tried with localhost/127.0.0.1) between three vvvv instances.
Firewall was active but vvvv was exempt. And since it was working – sometimes for hours – until it crashed I don’t think the firewall is the reason.
To be honest I didn’t try different ports.
Only one sender per port (two subscribers in two vvvv instances). What is non-zeromq-data?
The crash always occured in the same vvvv instance. I removed every other zero-mq related stuff in this instance except for the part in that screenshot and vvvv still crashed. Due to project time constraints I wasn’t able to investigate further.
I ended up using sharedmemory for local data transfer and plain UDP for communication between the different machines.
The instance that crashed was calculating a voronoi diagram using darellp’s contribution (and shared the vertex coordinates with an other instance). Those nodes were throwing exceptions now and then too.
With the voronoi the vertex-/spread-count is constantly changing , I think that maybe Asraw couldn’t handle this. When using sharedmemory writer I needed to “pad” the spread because it doesn’t like changing sizes, probably this also fixed the problem because afterwards I had no more crashes.
Unfortunately I no longer have access to the setup and can’t follow up on this.
Thanks for the detailed report. In case someone else ever encounters an error like that, maybe we find the cause of it.
I made a small test setup with 2 subscribers, similar to your specs. Only difference is, that I handle the topic properly.
It runs great at my end, would be nice if you could see if it’s doing so for you as well.
ZeroMQ is negotiating a communication between Binder and Non-Binder, so a packet-like communication is possible over tcp. So if faulty (or malicious) data arrives from a third party, this can render the handshake kaputt. I remember there were issues about this in the netmq github, and how the lib should simply reject the faulty data.
