ZeroMQ examples

[martinv]

Hi,

I got interested in ZeroMQ, so I downloaded the kit and installed it on VMS x86_64 running on VMware Workstation Player.
I also downloaded the examples from the ZeroMQ guide from GitHub. Trying the C++ binding of the simple "Hello world" request-reply example.

Code: Select all

CXX /INCLUDE=zmq$root:[include] /NAMES=(AS_IS,SHORTENED) /POINTER_SIZE=32  /OBJECT=hwserver.obj hwserver.cpp
SYS$SYSDEVICE:[temp.0mq-test]hwserver.cpp;1:6:10: fatal error: 'zmq.hpp' file not found
#include <zmq.hpp>
         ^~~~~~~~~
1 error generated.

and in fact ZMQ$ROOT:[INCLUDE] does not have a zmq.hpp, but only zmq.h. Okay, so no C++ binding. Interesting it looks like ZMQ$ROOT:[LIB]LIBZMQ*.OLB include names that look mangled...

Trying the C binding next:

Code: Select all

CXX /INCLUDE=zmq$root:[include] /NAMES=(AS_IS,SHORTENED) /POINTER_SIZE=32  /OBJECT=hwserver.obj hwserver.c
LINK  /EXEC=hwserver.exe hwserver.obj, zmq32.opt/OPTION
CXX /INCLUDE=zmq$root:[include] /NAMES=(AS_IS,SHORTENED) /POINTER_SIZE=32  /OBJECT=hwclient.obj hwclient.c
LINK  /EXEC=hwclient.exe hwclient.obj, zmq32.opt/OPTION

Fine. But:

Code: Select all

$ run hwserver
%SYSTEM-F-ACCVIO, access violation, reason mask=04, virtual address=000000000000001B, PC=0000000080026464, PS=0000001B
%TRACE-F-TRACEBACK, symbolic stack dump follows
image     module    routine               line      rel PC           abs PC
LIBCXXABI                                    0 0000000080000464 0000000080026464
LIBCXXABI                                    0 000000008002794C 000000008004D94C
                                             0 FFFF830007BAE417 FFFF830007BAE417
----- Above condition handler called with exception 0000000C
%SYSTEM-F-ACCVIO, access violation, reason mask=04, virtual address=000000000000001B, PC=0000000080026464, PS=0000001B
----- End of Exception message
                                             0 FFFF830007BB8CF4 FFFF830007BB8CF4
LIBCXXABI                                    0 0000000080000464 0000000080026464
LIBCXXABI                                    0 000000008002794C 000000008004D94C
                                             0 FFFF830007BAE417 FFFF830007BAE417
----- Above condition handler called with exception 0000000C
%SYSTEM-F-ACCVIO, access violation, reason mask=04, virtual address=000000000000001B, PC=0000000080026464, PS=0000001B
----- End of Exception message
                                             0 FFFF830007BB8CF4 FFFF830007BB8CF4
LIBCXXABI                                    0 0000000080000464 0000000080026464
LIBCXXABI                                    0 000000008002794C 000000008004D94C
                                             0 FFFF830007BAE417 FFFF830007BAE417
----- Above condition handler called with exception 0000000C
%SYSTEM-F-ACCVIO, access violation, reason mask=04, virtual address=000000000000001B, PC=0000000080026464, PS=0000001B
----- End of Exception message
                                             0 FFFF830007BB8CF4 FFFF830007BB8CF4
LIBCXXABI                                    0 0000000080000464 0000000080026464
LIBCXXABI                                    0 000000008002794C 000000008004D94C
                                             0 FFFF830007BAE417 FFFF830007BAE417
----- Above condition handler called with exception 0000000C
%SYSTEM-F-ACCVIO, access violation, reason mask=04, virtual address=000000000000001B, PC=0000000080026464, PS=0000001B
----- End of Exception message
                                             0 FFFF830007BB8CF4 FFFF830007BB8CF4
LIBCXXABI                                    0 0000000080000464 0000000080026464
LIBCXXABI                                    0 000000008002794C 000000008004D94C
                                             0 FFFF830007BAE417 FFFF830007BAE417
----- Above condition handler called with exception 0000000C
%SYSTEM-F-ACCVIO, access violation, reason mask=04, virtual address=0000003535353532, PC=FFFF830009E0A27D, PS=0000001B
----- End of Exception message
                                             0 FFFF830007BB8CF4 FFFF830007BB8CF4
DECC$SHR  MALLOC.C;1                    #28494 00000000800A327D FFFF830009E0A27D
zmq$shr32                                    0 000000008005A247 00000000800F4247
zmq$shr32                                    0 0000000080060B2A 00000000800FAB2A
zmq$shr32                                    0 0000000080060A6C 00000000800FAA6C
zmq$shr32                                    0 0000000080026E52 00000000800C0E52
zmq$shr32                                    0 0000000080029F15 00000000800C3F15
zmq$shr32                                    0 0000000080004DF4 000000008009EDF4
zmq$shr32                                    0 000000008000069E 000000008009A69E
hwserver  SYS$SYSDEVICE:[temp.0mq-test]hwserver.c;3
                                           #13 0000000000000040 0000000080000040
hwserver                                     0 0000000080000133 0000000080000133
PTHREAD$RTL                                  0 000000008004122C FFFF830009D0322C
PTHREAD$RTL                                  0 0000000080002316 FFFF830009CC4316
                                             0 FFFF8300081BDEA6 FFFF8300081BDEA6
DCL                                          0 000000008006778B 000000007ADEB78B
%TRACE-I-LINENUMBER, Leading '#' specifies a source file record number.
%TRACE-I-END, end of TRACE stack dump

Building the hwserver with /DEBUG and running through the debugger doesn't crash, but gives:

Code: Select all

run hwserver
%DEBUG-E-NOACCESSR, no read access to address 0000000000000000

         OpenVMS x86-64 Debug64 Version V9.2-005

%DEBUG-I-INITIAL, Language: C++, Module: HWSERVER

DBG> g
zmq_bind returned -1, errno=48!
%DEBUG-I-EXITSTATUS, is '%SYSTEM-S-NORMAL, normal successful completion'

where errno 48 translates to " EADDRINUSE - Address already in use"

Anyone with any ideas to proceed?

Thanks in advance,
Martin

[arne_v]

First thing to check should if it works with the C compiler.

If it does not then it is most likely a bug in the library itself on VMS x86+64.

If it does then it is most likely a problem with the new C++ compiler and the .H file.

[martinv]

Thanks Arne. I should have thought of that.
The results when using CC instead of CXX are exactly the same, though.

cu,
Martin

[arne_v]

I can confirm.

I took some code that works on Windows and tried building and running on VMS x86-64.

No compile error. No link error. But the application crashes.

I also experimented with /POINTER=64. Did not help.

[brett.cameron]

Martin, that ACCVIO has been fixed - it is/was a CRTL issue, and nothing in particular to do with ZeroMQ. Despite the use of the C binding, ZeroMQ is of course built with C++. For the x86-64 C++ compiler, size_t is 8 bytes as opposed to 4, and this necessitated a few adjustments to some CRTL struct definitions. If I recall, the problematical function in this case was getaddrinfo(). You will need to be using either a 9.2 system with latest RTL patches or 9.2-1 (recommended).

[martinv]

Brett,

thanks for the quick response. Looking forward to download the CRTL ECO once it is published to continue my journey into ZeroMQ.

[martinv]

The CRTL ECO8 release notes installed with VMS921X_UPDATE-V0100 explicitly mention fixes in getaddrinfo() and 64-bit mode. Unfortunately, after installing the update kit and recompiling the ZeroMQ hwserver/hwclient examples, the error persists. I tried 32- and 64-bit mode as well as using the ZeroMQ shareable images and static libraries.

[martinv]

The new timebomb-free compiler kit didn't change the code's behaviour.

As this seems to be getting nowhere, I decided to download the latest 4.1.x sources from GitHub (4.1.8, last changed in 2020, as opposed to 4.1.2, published in 2015), and try my luck with a self-compiled LIBZMQ. Hacked together a platform.hpp from [.src]platform.hpp.in, wrote a description file, and gave it a go.

What a surprise - it works! Currently only 32-bit and without libsodium, but it works.

I'll have a deeper look into the test failures (my library also passes more tests than the VSI one), and remove VSI ZEROMQ V4.1-2A.