Closed volks73 closed 3 years ago
When I was running the Connect-Disconnect.vi
test for the Session multiple times in a row to induce the Error 1097
, a couple of times a dialog appeared with the following message:
crypto\env\evp_enc.c:157: OpenSSL internal error: assertion failed: ctx->cipher->block_size==1 || ctx->cipher->block_size == 8 || ctx->cipher->block_size == 16
Once I clicked OK, the box would disappear and LabVIEW 2018 would crash. I think the new v0.2.2 shared libraries were compiled incorrectly and/or used a bugged version of OpenSSL.
see my log output in https://github.com/fieldrndservices/libssh2-labview/issues/36#issuecomment-946223387
I rolled back to v0.2.1 of the shared libraries and the same behavior has occurred. It does not appear to be a problem with shared library. I am not sure about the OpenSSL error. It is difficult to reproduce, so it might be another issue.
Based on the output from @ngblume log, the Connect.vi and specifically the Call Library Function node within the VI has become corrupted/malformed. I am not very familiar with the debug output, but past experience when a VI has become corrupted has been to just delete and re-create from a blank VI. I will try this next.
@ngblume I think there might be a conflict with having multiple versions of this toolkit installed. I have the source code running and along with the package installed. When I run the tests with the source code, it will constantly crash and/or get the Error 1097. However, as soon as I uninstalled the package, using the VIPM, then the source code tests worked without crashing or the Error 1097.
I wonder if through the various tests, trying different packages, etc. resulted in multiple versions of the shared libraries being loaded at the same time?
@volks73 I changed to different versions of the lib by using the package manager to upgrade / downgrade.. Seems to me that there shouldn't be two versions on the system at the same time.. I will try uninstalling all versions and working directly from source code next.... It seemed to me that calling that function via the call library node leaves something behind that gets in the way of calling it again without garbage collection happening when closing LabVIEW....
@ngblume I think the uninstalling of the package and successfully re-running tests from the source code was a coincidence. I was also trying a variety of different shared library versions. I have since bumped the shared library to v0.2.3, which uses OpenSSL v1.1.1l and libssh2 v1.10.0, i.e. the latest versions of both dependencies for compiling the libssh2lv shared libraries. After replacing the DLL with this new DLL, I can re-run tests and VIs without crashing LabVIEW and I can re-run the Connect VI without getting an Error 1097. This is only from the source code, but it appears the issue was within the shared library and possibly a bug in the OpenSSL library.
I have created a release, v1.2.2, and it should be available on VIPM.io in the near future. The VIP is available on the release page if you would like to try it sooner. Please let me know if this new version works and if Error 1097 has been resolved. If yes, then I will close this issue.
Error is fixed for me.. I think the issue can be closed.... I'm running into another issue, but I will open a separte issue for that.
As mentioned in #36, when an example or test is run the first time, it completes successfully and/or passes without error. If the example or test is ran again, an Error 1097 occurs when establishing a SSH connection with the
Session:Connect.vi
or LabVIEW 2018 crashes with an internal error. The Error 1097 occurs with the examples while the LabVIEW 2018 crash occurs with the Caraya-based tests. I believe the LabVIEW 2018 crash is caused by the Error 1097 but Caraya has a conflict.Error 1097 mentions an internal errors with the external shared library (DLL for Windows) through the Call Library Function node. It is possible there is something wrong with the v0.2.2 of the libssh2lv shared libraries.