-
Notifications
You must be signed in to change notification settings - Fork 94
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Bug when stopping provider on OSX #168
Comments
I don't see any reference to python module issues in the above...Why do you think this is the issue? If it's "only" exactly the 4 errors above with algorithms of the SPHINCS+ family (is it?) this reminds me a bit of open-quantum-safe/liboqs#1420... If it's indeed only these Sphincs+ tests failing, would you be willing to re-build&test with "-DOQS_USE_SHA2_OPENSSL=OFF" to see whether this improves things (so it may be the same issue as in open-quantum-safe/liboqs#1420)? |
Just found a definite bug; until the fix for that lands, |
Sorry, proposed workaround is no-joy: One excerpt:
|
Without the workaround, at least the test-run completes, though the majority of the tests fail:
With that presumed workaround - tests don't even run, as shown above, and here:
|
Correct workaround is
Looking forward to seeing the bug fix merged. TNX |
Thanks for the test/reconfirmation. We'll look into this. |
It works on Apple Silicon. I'll need to check on x86_64. But on Apple Silicon, OpenSSL-3.2.0-dev crashes several times, with this:
|
So we re-open. Is this dependent on other providers being active? Any way you see how we can reproduce (also for CI)? Edit/Add: Is this issue really correct here? Should it rather be an |
On Apple Silicon. With minimal set of providers enabled:
and no crash. UpdateWith With both
and crash report:
|
@mouse07410 Can you still reproduce this issue after the latest oqsprovider & libops updates? |
Unfortunately, yes I can. Tests proceed fine, but when they finish I see about 5 or so OS crash reports telling me that it crashed. |
Too bad. On Ubuntu, everything works like a charm (see below for OpenSSL3.0.2; same results for 3.2.0-dev): Tests pass and no crash at the end, so I cannot debug into this... Tagging @mattcaswell for thoughts as to whether this may be another openssl (config) issue (?)
|
This is crashing during a call to The stack trace shows us this:
I assume the "0 is not in any region" message in the stack trace means that the write lock that int ERR_unload_strings(int lib, ERR_STRING_DATA *str)
{
#ifndef OPENSSL_NO_ERR
if (!RUN_ONCE(&err_string_init, do_err_strings_init))
return 0;
if (!CRYPTO_THREAD_write_lock(err_string_lock))
return 0; With the DEFINE_RUN_ONCE_STATIC(do_err_strings_init)
{
if (!OPENSSL_init_crypto(OPENSSL_INIT_BASE_ONLY, NULL))
return 0;
err_string_lock = CRYPTO_THREAD_lock_new();
if (err_string_lock == NULL)
return 0; Since void err_cleanup(void)
{
if (set_err_thread_local != 0)
CRYPTO_THREAD_cleanup_local(&err_thread_local);
CRYPTO_THREAD_lock_free(err_string_lock);
err_string_lock = NULL;
#ifndef OPENSSL_NO_ERR
lh_ERR_STRING_DATA_free(int_error_hash);
int_error_hash = NULL;
#endif
} But that is only ever called from 17 libcrypto.3.dylib 0x10453ae2c ossl_lib_ctx_default_deinit + 20
18 libcrypto.3.dylib 0x10453dd80 OPENSSL_cleanup + 204 So, we are currently in the OSSL_TRACE(INIT, "OPENSSL_cleanup: ossl_lib_ctx_default_deinit()\n");
ossl_lib_ctx_default_deinit();
ossl_cleanup_thread();
OSSL_TRACE(INIT, "OPENSSL_cleanup: bio_cleanup()\n");
bio_cleanup();
OSSL_TRACE(INIT, "OPENSSL_cleanup: evp_cleanup_int()\n");
evp_cleanup_int();
OSSL_TRACE(INIT, "OPENSSL_cleanup: ossl_obj_cleanup_int()\n");
ossl_obj_cleanup_int();
OSSL_TRACE(INIT, "OPENSSL_cleanup: err_int()\n");
err_cleanup(); So, right now I don't see a situation how this could occur!? In any case this doesn't currently look like an oqs-provider issue. More likely it is an OpenSSL problem. Perhaps open an issue there? |
Opened an OpenSSL issue for this. Also, it affects both Apple Silicon and x86_64 platforms. |
As I just chased another OpenSSL (only in 3.0.1 -- triggered by old CI packaging) bug for a few hours now, I tend to also consider this issue moot for |
No objections - let's release. |
As far as I can see, current master runs and passes tests on my MacOS Ventura, both Intel and M2 platforms. Using OpenSSL-3.1.1 and 3.2.0-dev. Thus, let me close this for now - might re-open if hit with the same problem again. ;-) |
Thanks for these tests on what is now a release: Glad to hear that! |
Describe the bug
On a newly-prepared platform , I'm getting a ton of errors trying to run test-suite:
To Reproduce
Steps to reproduce the behavior:
build
subdirectory.ninja run_tests
Expected behavior
Tests passing or being skipped, test-scripts not crashing.
Screenshots
If applicable, add screenshots to help explain your problem.
Environment (please complete the following information):
Additional context
I hope you can point me at where/what in Python environment seems missing - maybe an older version of some module, or such...?
The text was updated successfully, but these errors were encountered: