Assertion failure (ok), log file empty
LabVIEW bindings for the ZeroMQ project
Brought to you by:
mjasperse
Menu
▾
▴
Hi everyone,
I managed to develop an application using lvzmq. It seems to work as expected until I stop the application and start it again. Most times, lvzmq will crash throwing an "Assertion failure (ok)" but without writing anything to the log file. Do I have to configure something to enable logging?
Basically, I want to build this architecture in LabVIEW: http://zguide.zeromq.org/page:all#toc123
So I'm binding a PUB, ROUTER and PULL socket to 3 different ports on the server side. On the client side, I connect to these ports with a SUB, DEALER and PUSH socket.
The main application is running the server and a local client. As far as I can tell, it exits without error.
However, on startup of the following run (without closing the project), lvzmq crashes (often, not always). If I close the project in between runs, it seems to work...
It smells like a race condition. Are there any timeouts/delays that I have to consider for stopping lvzmq properly?
Edit: Sometimes I get an Assertion failure (Socket operation on non-socket) instead. The result is the same: 0MQ crashes and takes LabVIEW down with it.
Edit 2: As far as I can tell, it was a timing problem. I was trying to send messages while server and/or client were still initializing. At least the problem is gone when I give both some time before sending anything. However, it still seems a bit odd that this would result in a crash... I would have expected a basic error message.
Last edit: pktl 2018-08-27
Hi,
Apparently I missed your post. Race conditions can cause crashes because it violates a precondition of the underlying zeromq library. ZMQ is not thread-safe and LabVIEW is inherently multithreaded. That's why it's important not to split context or socket wires wherever possible. My library includes a system for tracking which objects are in use and attempts to clean them up - when the project is closed that's when this system fires and cleans everything up. Basically once an assertion failure occurs it is impossible to handle the error and the whole system is shut down by the OS. I haven't encountered this myself so it would depend on your implementation; "socket operation on non-socket" certainly implies this is the case.
Cheers