LabVIEW
"Connect to TLS Server.vi" example closes LabVIEW for MAC
I don’t have a Mac that is new enough to run LabVIEW 2021 so can’t try it out. Your picture is of limited use since it states that thread 4 had crashed but you only show the stack trace for thread 0 (which is the LabVIEW root loop or UI thread and would be strange if it had crashed because of the execution of a specific network functionality.
I would expect NI to have some earlier reports already about this as it would be strange if nobody has run into this before but just in case it might be helpful to attach the actual error report itself instead of just the pic.
Well, I unfortunately can't help you with a solution. However I can see that the crash happens in SSL_ctx_new(). This is an OpenSSL function, so NI apparently interfaces directly to the underlying SSL provider rather than using the MacOS SecureTransport API. It makes sense since on all other LabVIEW platforms this is the API to interface to for TLS transport security, so why complicate the development of this functionality by having to interface to a different API?
Well OpenSSL is NOT binary compatible between versions, so interfacing to it is a very tricky business. And as can be seen in the logs, the OpenSSL implementation used on your Mac is actually Googles boringssl library which is a fork from OpenSSL, since Google felt that the OpenSSL community was not responsive enough about addressing security vulnerabilities (for instance after the HeartBleed vulnerability). In the meantime OpenSSL development has considerably picked up and while there are many things that you can disagree with in pretty much every Open Source project, not addressing security fixes promptly isn't really one you can accuse the OpenSSL community at this time.
Google itself discourges everyone to use their boringssl engine as they state openly that it can be binary incompatible between versions and also with the official OpenSSL implementation. Apple decided to go with it anyhow for MacOS 11 (and apparently even your 10.13.6 High Sierra). Generally this would be not necessarily a problem as MacOS applications are supposed to use the according SecureTransport API, so the only one having to worry about such binary incompatibilities would be Apple itself in their SecureTransport API when interfacing to the underlying SSL engine. In practice though it is to tempting for a multiplatform application like LabVIEW to skip the development of a special intermediate layer to adapt to the special platform API when there is a "compatible" software library already present in the system that seems to match the API on all the other platforms like Linux and Windows. Except when it doesn't match! It also makes sense from a software architectural point of view. Compare these software layers:
LabVIEW
LabVIEW TLS layer handler
LabVIEW adapter for Apple Secure Transport
Apple Secure Transport
Apple Secure Transport for BoringSSL Adapter
Boring SSL library
platform specific network adapter layer based on sockets
Apple Network Transport layer
network driver stack
LabVIEW
LabVIEW TLS layer handler
LabVIEW adapter for OpenSSL
Open SSL library
platform specific network adapter layer based on sockets
network driver stack
It's quite a bit leaner and meaner and saves the effort to implement a specific Apple TLS layer adapter and it pretty much works too, except when it doesn't because of version incompatibilities. Would be interesting what boringSSL version your High Sierra system uses. It's probably not the same as in newer Apple OSes and the reason for this. If this boringssl implementation is based on OpenSSL 1.0.2 or earlier it requires explicit initialization of the underlying engines before any API can be called. It would seem strange that Apple uses such a version in their latest update from 2020 for your system (10.13.6 17G14042 was released on November 12, 2020) but they probably used whatever was the initial release of boringssl when the 10.13 system came out in 2017 and in the various bug fix releases of this OS only applied bugfix releases to the boringssl engine rather than upgrading to a completely new base version of it.
There is one possibility to check this but it is a bit hairy if you never have worked with calling C functions. You could try to use a Call Library Node to execute the function
int SSL_library_init(void):
in the boringssl.dylib shared library before attempting to do any TLS operation in LabVIEW.
Simply drop a Call Library Node in a VI diagram, set the library name to "boringssl.dylib" (without quotes) and the function name to SSL_lbrary_init, then configure the return value to be a 32-bit integer. The function has no parameters so don't configure any. Set the Calling Convention to cdecl (I believe there isn't even a calling convention configuration on the Mac). The return value unfortunately does not say anything as it is always 1 no matter if the function was successful or ran into a snag.
Make sure to call this VI before you try to call any LabVIEW TLS functions. It may magically fix this problem if the boringssl implementation on your Mac System uses the OpenSSL 1.0.2 or earlier initialization system. Later versions do auto initialization whenever any of the SSL functions is called. If this fixes it, then the solution for NI would be to call this function always too. It will not hurt for newer OpenSSL/BoringSSL implementation but will fix issues with older versions. Of course for OpenSSL itself using a system that still runs 1.0.2 or earlier is a serious security liability nowadays. It is fully unsupported since December 20, 2019 so any vulnerability discovered since then is still present. BoringSSL may be fixing additional things but since your MacOS 10.13.6 release was last updated on November 12, 2020 it would not contain any fixes that Google may have added since then to their library release and there is no guarantee that Apple actually used the latest version of that library when building that release.
it is called "libboringssl.dylib" and it may be not visible in the normal finder since it is probably contained in one of the framework bundles in the /Library/.... tree.
Actually it seems to be in /usr/lib/libboringssl.dylib. But this is a system path and you should not need to enter the whole path, actually that will mess up the application builder when you later build an executable. Instead just enter "libboringssl.dylib" as library name and then it should find it.
Sorry for the wrong name.
Well, my Mac is from 2012 and runs MacOS 10.11 so I can't check it myself.
But first, if you look in the full error report that you posted it says on line 101:
6 libboringssl.dylib 0x00007fff51934ed8 SSL_CTX_new + 252and later on on line :360:
0x7fff518af000 - 0x7fff51968ffb libboringssl.dylib (109.50.15) <FC25FE02-6AA8-3F0B-9EF3-56A455C08C0F> /usr/lib/libboringssl.dylibSo unless the MacOS error reporter invents non-existing shared libraries in its stack trace and loaded modules list, that library is there somewhere.
As to your VI, don't try to enter the path in the Call Library Node! That is bad for referencing system libraries and would go and bite you when you later try to build an executable from your LabVIEW program. Instead simply try to enter the string "libboringssl.dylib" without double quotes and see if the VI is still broken.
If you only enter the library name then LabVIEW will pass this name to the OS dlopen() function like that, and the MacOS dynamic loader will do its work and find it (actually it shouldn't even have to search for it as it was already loaded by LabVIEW for its own use so if this still breaks then Apple obviously did a lot of very weird mumbo jumbo here again).
Once the VI is not broken anymore with this name in the library path I would improve it to be more platform tolerant by enabling the "Specify path on diagram" checkbox and pass that library name as a path constant from the diagram. That way the VI will not break if someone tries to run your program on a Mac system that uses a different SSL library. It will cause a runtime error in that case which that person would have to ignore.
There is no VI or vilib that you can replace here. The TCP and TLS nodes are directly implemented in the LabVIEW executable in C++ code and interface to the relevant platform APIs directly. While not all is in the LabVIEW executable itself but also divided up in various shared libraries itself, trying to go and change anything in there is a sure way to mess up for good. Without access to the actual source code to see what is done where and how, you can not even hope to make any change to the better. There are zillion possibilities to mess up and one or two to make it better, and that whole architecture changes frequently in subtle and not so subtle ways between LabVIEW versions, so even if you find something that might work with your current version of LabVIEW, the next update or bugfix install might throw your solution into panic.
