LabVIEW Crashes while using ZMQ
LabVIEW bindings for the ZeroMQ project
Brought to you by:
mjasperse
Menu
▾
▴
A number of times LabVIEW has crashed on me during the development of a new ZMQ component that I’m adding into an existing application. When it happens, I get a variant or two of the popup attached that tells me to send in the log files into this forum but when I browse to them, they are completely empty. I read somewhere that there’s a development dll that will produce logs but i couldn’t find it. Any help there would be appreciated.
The application we've written has been pretty bullet proof in terms of crashing in the past and I'm worried with these crashes that adding in the ZMQ functionality is putting that at risk. TBH, I have been getting these crashes while i am deliberately trying to cause issues with ZMQ component to ensure its stability along with the stability of my code when the unexpected occurs. e.g. attempting to connect to the same sockets on the same ports at the same time (e.g. if they are already in use) producing an "Assertion failure (nbytes == sizeof (dummy))" error, or disconnecting/disabling the ethernet port etc sometimes producing an "Assertion failure (Socket operation on non-socket).
In my implmentation, I've wrapped up some of the ZMQ library into an FGV compoenent just to help tidy up the code and also to help store and handle the socket references. Our ZMQ architecture uses two sockets. One a Subscriber to two topics that we can read messages on and another being a Push socket to send messages out on. The other code just handles the queueing of messages to and from those Send and Receive loops. For your refernce, I've attached some screen shots of the top level, the compoent and the sequence used to open the sockets.
If theres anything obvious that i'm doing wrong please feel free to let me know. Thank you
I've been reading the FAQ page for LabVIEW ZeroMQ (https://labview-zmq.sourceforge.io/?faq) and have seen some specific references to not splitting the context and socket references like I am doing with my wrapped-up component. In my implementation I don't easily see where I am performing simultaneous or illegal actions on my socket references because there is a clear “Open>Read/Send>Close” design (albeit in different threads), but I am going to work at reforming the architecture to work without any splitting of the reference wires.
The FAQ also mentions handling closures correctly. Currently I am relying on the close context vi with "reap?" = True to force blocking events to exit. Perhaps this could be another source of my troubles.
I have managed to create a testbench that can casue the "Socket operation on non-socket" error every so often. It tiggers the error by forcibly closing the context with reap? = True while performing a read in a seperate loop. Then it just restablishes the contexts and sockets and repeats until eventually the error happens. If the ZMQ labview library deeloper ever finds any time to review this perhaps it will help them to resolve the casue. See the attached TB vi.
There appear to be two modes where the vi will crash. One is the with this "Socket operation on non-socket" popup and the other is where the context cannot be closed and it just holds forever waiting to close it. This occurs even when reap = true so potentially this could highlight a bug.
Interstingly, the TB when built into an exe will not produce an error under my testing so i am assuming that the library developer has locked that popup away under a development environment case in the code.
In the end, I have resolved my issues by better handling the context and socket refernces ensuring not to split wires and to never to use the reap = true setting while closing the context. When reading, I also use things like the polling methods to ensure when i read it will can never block. It will only read whenever the poll indicates there is data to read. This allows me to exit read and send loops as i want before cleanly closing sockets and then finally the context.
Note: there is potentially a bug in the libraries zmq_recv_event.vi becasue it still attempts to read if the Poll Sockets.vi times out. A fix to this issue is present in my ZMQ - Event Driven Pull sever - Custom poll.vi