Downgrading a key is not thread safe

I modified the multi threads test in #13987 so that one thread worker did a key downgrade, at the same time as other workers were using the EVP_PKEY.
I get regular seg faults and lots of errors reported from tsan:
==================
WARNING: ThreadSanitizer: data race (pid=408166)
  Read of size 8 at 0x7b4400000a28 by thread T10 (mutexes: write M2751):
    #0 memcpy <null> (threadstest+0x430f37)
    #1 evp_pkey_downgrade /home/matt/dev/openssl-write/crypto/evp/p_lib.c:1973:16 (libcrypto.so.3+0x3757f6)
    #2 EVP_PKEY_get0 /home/matt/dev/openssl-write/crypto/evp/p_lib.c:736:10 (libcrypto.so.3+0x379970)
    #3 thread_downgrade_shared_evp_pkey /home/matt/dev/openssl-write/test/threadstest.c:411:9 (threadstest+0x4b5e8b)
    #4 thread_run /home/matt/dev/openssl-write/test/threadstest.c:74:5 (threadstest+0x4b562a)
  Previous atomic write of size 4 at 0x7b4400000a28 by thread T9:
    #0 __tsan_atomic32_fetch_add <null> (threadstest+0x472059)
    #1 CRYPTO_UP_REF /home/matt/dev/openssl-write/include/internal/refcount.h:38:12 (libcrypto.so.3+0x37c5c0)
    #2 EVP_PKEY_up_ref /home/matt/dev/openssl-write/crypto/evp/p_lib.c:1624:9 (libcrypto.so.3+0x37c4ed)
    #3 int_ctx_new /home/matt/dev/openssl-write/crypto/evp/pmeth_lib.c:327:9 (libcrypto.so.3+0x383221)
    #4 EVP_PKEY_CTX_new_from_pkey /home/matt/dev/openssl-write/crypto/evp/pmeth_lib.c:352:12 (libcrypto.so.3+0x383368)
    #5 thread_shared_evp_pkey /home/matt/dev/openssl-write/test/threadstest.c:371:15 (threadstest+0x4b5feb)
    #6 thread_run /home/matt/dev/openssl-write/test/threadstest.c:74:5 (threadstest+0x4b562a)
  Location is heap block of size 296 at 0x7b4400000a00 allocated by main thread:
    #0 malloc <null> (threadstest+0x425874)
    #1 CRYPTO_malloc /home/matt/dev/openssl-write/crypto/mem.c:184:12 (libcrypto.so.3+0x3bfc59)
    #2 CRYPTO_zalloc /home/matt/dev/openssl-write/crypto/mem.c:191:11 (libcrypto.so.3+0x3bfcc4)
    #3 EVP_PKEY_new /home/matt/dev/openssl-write/crypto/evp/p_lib.c:1418:21 (libcrypto.so.3+0x37c016)
    #4 evp_keymgmt_util_make_pkey /home/matt/dev/openssl-write/crypto/evp/keymgmt_lib.c:72:20 (libcrypto.so.3+0x3659be)
    #5 decoder_construct_EVP_PKEY /home/matt/dev/openssl-write/crypto/encode_decode/decoder_pkey.c:144:24 (libcrypto.so.3+0x2dfc28)
    #6 decoder_process /home/matt/dev/openssl-write/crypto/encode_decode/decoder_lib.c:536:16 (libcrypto.so.3+0x2da162)
    #7 der2key_decode /home/matt/dev/openssl-write/providers/implementations/encode_decode/decode_der2key.c:385:14 (libcrypto.so.3+0x5c8f76)
    #8 decoder_process /home/matt/dev/openssl-write/crypto/encode_decode/decoder_lib.c:627:14 (libcrypto.so.3+0x2da5c6)
    #9 OSSL_DECODER_from_bio /home/matt/dev/openssl-write/crypto/encode_decode/decoder_lib.c:47:10 (libcrypto.so.3+0x2d9e8f)
    #10 OSSL_DECODER_from_data /home/matt/dev/openssl-write/crypto/encode_decode/decoder_lib.c:93:9 (libcrypto.so.3+0x2da8da)
    #11 try_key_value /home/matt/dev/openssl-write/crypto/store/store_result.c:282:11 (libcrypto.so.3+0x4ed32a)
    #12 try_key /home/matt/dev/openssl-write/crypto/store/store_result.c:401:18 (libcrypto.so.3+0x4ec06f)
    #13 ossl_store_handle_load_result /home/matt/dev/openssl-write/crypto/store/store_result.c:147:10 (libcrypto.so.3+0x4eb8eb)
    #14 file_load_construct /home/matt/dev/openssl-write/providers/implementations/storemgmt/file_store.c:528:12 (libcrypto.so.3+0x60e69e)
    #15 decoder_process /home/matt/dev/openssl-write/crypto/encode_decode/decoder_lib.c:536:16 (libcrypto.so.3+0x2da162)
    #16 pem2der_decode /home/matt/dev/openssl-write/providers/implementations/encode_decode/decode_pem2der.c:205:14 (libcrypto.so.3+0x5cd4fb)
    #17 decoder_process /home/matt/dev/openssl-write/crypto/encode_decode/decoder_lib.c:627:14 (libcrypto.so.3+0x2da5c6)
    #18 OSSL_DECODER_from_bio /home/matt/dev/openssl-write/crypto/encode_decode/decoder_lib.c:47:10 (libcrypto.so.3+0x2d9e8f)
    #19 file_load_file /home/matt/dev/openssl-write/providers/implementations/storemgmt/file_store.c:648:12 (libcrypto.so.3+0x60db8e)
    #20 file_load /home/matt/dev/openssl-write/providers/implementations/storemgmt/file_store.c:808:16 (libcrypto.so.3+0x60d142)
    #21 OSSL_STORE_load /home/matt/dev/openssl-write/crypto/store/store_lib.c:385:18 (libcrypto.so.3+0x4e51eb)
    #22 pem_read_bio_key /home/matt/dev/openssl-write/crypto/pem/pem_pkey.c:74:23 (libcrypto.so.3+0x41c5d3)
    #23 PEM_read_bio_PrivateKey_ex /home/matt/dev/openssl-write/crypto/pem/pem_pkey.c:144:12 (libcrypto.so.3+0x41c9ea)
    #24 load_pkey_pem /home/matt/dev/openssl-write/test/testutil/load.c:80:15 (threadstest+0x4bc481)
    #25 test_multi /home/matt/dev/openssl-write/test/threadstest.c:471:14 (threadstest+0x4b51c1)
    #26 run_tests /home/matt/dev/openssl-write/test/testutil/driver.c:357:21 (threadstest+0x4bb041)
    #27 main /home/matt/dev/openssl-write/test/testutil/main.c:30:15 (threadstest+0x4bc689)
  Mutex M2751 (0x7b1000008980) created at:
    #0 pthread_rwlock_init <null> (threadstest+0x429279)
    #1 CRYPTO_THREAD_lock_new /home/matt/dev/openssl-write/crypto/threads_pthread.c:41:9 (libcrypto.so.3+0x3dd191)
    #2 EVP_PKEY_new /home/matt/dev/openssl-write/crypto/evp/p_lib.c:1428:17 (libcrypto.so.3+0x37c080)
    #3 evp_keymgmt_util_make_pkey /home/matt/dev/openssl-write/crypto/evp/keymgmt_lib.c:72:20 (libcrypto.so.3+0x3659be)
    #4 decoder_construct_EVP_PKEY /home/matt/dev/openssl-write/crypto/encode_decode/decoder_pkey.c:144:24 (libcrypto.so.3+0x2dfc28)
    #5 decoder_process /home/matt/dev/openssl-write/crypto/encode_decode/decoder_lib.c:536:16 (libcrypto.so.3+0x2da162)
    #6 der2key_decode /home/matt/dev/openssl-write/providers/implementations/encode_decode/decode_der2key.c:385:14 (libcrypto.so.3+0x5c8f76)
    #7 decoder_process /home/matt/dev/openssl-write/crypto/encode_decode/decoder_lib.c:627:14 (libcrypto.so.3+0x2da5c6)
    #8 OSSL_DECODER_from_bio /home/matt/dev/openssl-write/crypto/encode_decode/decoder_lib.c:47:10 (libcrypto.so.3+0x2d9e8f)
    #9 OSSL_DECODER_from_data /home/matt/dev/openssl-write/crypto/encode_decode/decoder_lib.c:93:9 (libcrypto.so.3+0x2da8da)
    #10 try_key_value /home/matt/dev/openssl-write/crypto/store/store_result.c:282:11 (libcrypto.so.3+0x4ed32a)
    #11 try_key /home/matt/dev/openssl-write/crypto/store/store_result.c:401:18 (libcrypto.so.3+0x4ec06f)
    #12 ossl_store_handle_load_result /home/matt/dev/openssl-write/crypto/store/store_result.c:147:10 (libcrypto.so.3+0x4eb8eb)
    #13 file_load_construct /home/matt/dev/openssl-write/providers/implementations/storemgmt/file_store.c:528:12 (libcrypto.so.3+0x60e69e)
    #14 decoder_process /home/matt/dev/openssl-write/crypto/encode_decode/decoder_lib.c:536:16 (libcrypto.so.3+0x2da162)
    #15 pem2der_decode /home/matt/dev/openssl-write/providers/implementations/encode_decode/decode_pem2der.c:205:14 (libcrypto.so.3+0x5cd4fb)
    #16 decoder_process /home/matt/dev/openssl-write/crypto/encode_decode/decoder_lib.c:627:14 (libcrypto.so.3+0x2da5c6)
    #17 OSSL_DECODER_from_bio /home/matt/dev/openssl-write/crypto/encode_decode/decoder_lib.c:47:10 (libcrypto.so.3+0x2d9e8f)
    #18 file_load_file /home/matt/dev/openssl-write/providers/implementations/storemgmt/file_store.c:648:12 (libcrypto.so.3+0x60db8e)
    #19 file_load /home/matt/dev/openssl-write/providers/implementations/storemgmt/file_store.c:808:16 (libcrypto.so.3+0x60d142)
    #20 OSSL_STORE_load /home/matt/dev/openssl-write/crypto/store/store_lib.c:385:18 (libcrypto.so.3+0x4e51eb)
    #21 pem_read_bio_key /home/matt/dev/openssl-write/crypto/pem/pem_pkey.c:74:23 (libcrypto.so.3+0x41c5d3)
    #22 PEM_read_bio_PrivateKey_ex /home/matt/dev/openssl-write/crypto/pem/pem_pkey.c:144:12 (libcrypto.so.3+0x41c9ea)
    #23 load_pkey_pem /home/matt/dev/openssl-write/test/testutil/load.c:80:15 (threadstest+0x4bc481)
    #24 test_multi /home/matt/dev/openssl-write/test/threadstest.c:471:14 (threadstest+0x4b51c1)
    #25 run_tests /home/matt/dev/openssl-write/test/testutil/driver.c:357:21 (threadstest+0x4bb041)
    #26 main /home/matt/dev/openssl-write/test/testutil/main.c:30:15 (threadstest+0x4bc689)
  Thread T10 (tid=408199, running) created by main thread at:
    #0 pthread_create <null> (threadstest+0x42713b)
    #1 run_thread /home/matt/dev/openssl-write/test/threadstest.c:80:12 (threadstest+0x4b54f6)
    #2 test_multi /home/matt/dev/openssl-write/test/threadstest.c:483:17 (threadstest+0x4b52aa)
    #3 run_tests /home/matt/dev/openssl-write/test/testutil/driver.c:357:21 (threadstest+0x4bb041)
    #4 main /home/matt/dev/openssl-write/test/testutil/main.c:30:15 (threadstest+0x4bc689)
  Thread T9 (tid=408198, running) created by main thread at:
    #0 pthread_create <null> (threadstest+0x42713b)
    #1 run_thread /home/matt/dev/openssl-write/test/threadstest.c:80:12 (threadstest+0x4b54f6)
    #2 test_multi /home/matt/dev/openssl-write/test/threadstest.c:482:10 (threadstest+0x4b526a)
    #3 run_tests /home/matt/dev/openssl-write/test/testutil/driver.c:357:21 (threadstest+0x4bb041)
    #4 main /home/matt/dev/openssl-write/test/testutil/main.c:30:15 (threadstest+0x4bc689)
SUMMARY: ThreadSanitizer: data race (/home/matt/dev/openssl-write/test/threadstest+0x430f37) in memcpy
==================
==================
WARNING: ThreadSanitizer: data race (pid=408166)
  Write of size 8 at 0x7b4400000a20 by thread T10 (mutexes: write M2751):
    #0 memset <null> (threadstest+0x430bd2)
    #1 evp_pkey_reset_unlocked /home/matt/dev/openssl-write/crypto/evp/p_lib.c:1401:7 (libcrypto.so.3+0x37c266)
    #2 evp_pkey_downgrade /home/matt/dev/openssl-write/crypto/evp/p_lib.c:1975:9 (libcrypto.so.3+0x375812)
    #3 EVP_PKEY_get0 /home/matt/dev/openssl-write/crypto/evp/p_lib.c:736:10 (libcrypto.so.3+0x379970)
    #4 thread_downgrade_shared_evp_pkey /home/matt/dev/openssl-write/test/threadstest.c:411:9 (threadstest+0x4b5e8b)
    #5 thread_run /home/matt/dev/openssl-write/test/threadstest.c:74:5 (threadstest+0x4b562a)
  Previous read of size 8 at 0x7b4400000a20 by main thread:
    #0 evp_pkey_export_to_provider /home/matt/dev/openssl-write/crypto/evp/p_lib.c:1719:31 (libcrypto.so.3+0x37601a)
    #1 evp_pkey_asym_cipher_init /home/matt/dev/openssl-write/crypto/evp/asymcipher.c:49:15 (libcrypto.so.3+0x2fd990)
    #2 EVP_PKEY_encrypt_init /home/matt/dev/openssl-write/crypto/evp/asymcipher.c:171:12 (libcrypto.so.3+0x2fd6fd)
    #3 thread_shared_evp_pkey /home/matt/dev/openssl-write/test/threadstest.c:377:14 (threadstest+0x4b6034)
    #4 test_multi /home/matt/dev/openssl-write/test/threadstest.c:486:5 (threadstest+0x4b52e5)
    #5 run_tests /home/matt/dev/openssl-write/test/testutil/driver.c:357:21 (threadstest+0x4bb041)
    #6 main /home/matt/dev/openssl-write/test/testutil/main.c:30:15 (threadstest+0x4bc689)
  Location is heap block of size 296 at 0x7b4400000a00 allocated by main thread:
    #0 malloc <null> (threadstest+0x425874)
    #1 CRYPTO_malloc /home/matt/dev/openssl-write/crypto/mem.c:184:12 (libcrypto.so.3+0x3bfc59)
    #2 CRYPTO_zalloc /home/matt/dev/openssl-write/crypto/mem.c:191:11 (libcrypto.so.3+0x3bfcc4)
    #3 EVP_PKEY_new /home/matt/dev/openssl-write/crypto/evp/p_lib.c:1418:21 (libcrypto.so.3+0x37c016)
    #4 evp_keymgmt_util_make_pkey /home/matt/dev/openssl-write/crypto/evp/keymgmt_lib.c:72:20 (libcrypto.so.3+0x3659be)
    #5 decoder_construct_EVP_PKEY /home/matt/dev/openssl-write/crypto/encode_decode/decoder_pkey.c:144:24 (libcrypto.so.3+0x2dfc28)
    #6 decoder_process /home/matt/dev/openssl-write/crypto/encode_decode/decoder_lib.c:536:16 (libcrypto.so.3+0x2da162)
    #7 der2key_decode /home/matt/dev/openssl-write/providers/implementations/encode_decode/decode_der2key.c:385:14 (libcrypto.so.3+0x5c8f76)
    #8 decoder_process /home/matt/dev/openssl-write/crypto/encode_decode/decoder_lib.c:627:14 (libcrypto.so.3+0x2da5c6)
    #9 OSSL_DECODER_from_bio /home/matt/dev/openssl-write/crypto/encode_decode/decoder_lib.c:47:10 (libcrypto.so.3+0x2d9e8f)
    #10 OSSL_DECODER_from_data /home/matt/dev/openssl-write/crypto/encode_decode/decoder_lib.c:93:9 (libcrypto.so.3+0x2da8da)
    #11 try_key_value /home/matt/dev/openssl-write/crypto/store/store_result.c:282:11 (libcrypto.so.3+0x4ed32a)
    #12 try_key /home/matt/dev/openssl-write/crypto/store/store_result.c:401:18 (libcrypto.so.3+0x4ec06f)
    #13 ossl_store_handle_load_result /home/matt/dev/openssl-write/crypto/store/store_result.c:147:10 (libcrypto.so.3+0x4eb8eb)
    #14 file_load_construct /home/matt/dev/openssl-write/providers/implementations/storemgmt/file_store.c:528:12 (libcrypto.so.3+0x60e69e)
    #15 decoder_process /home/matt/dev/openssl-write/crypto/encode_decode/decoder_lib.c:536:16 (libcrypto.so.3+0x2da162)
    #16 pem2der_decode /home/matt/dev/openssl-write/providers/implementations/encode_decode/decode_pem2der.c:205:14 (libcrypto.so.3+0x5cd4fb)
    #17 decoder_process /home/matt/dev/openssl-write/crypto/encode_decode/decoder_lib.c:627:14 (libcrypto.so.3+0x2da5c6)
    #18 OSSL_DECODER_from_bio /home/matt/dev/openssl-write/crypto/encode_decode/decoder_lib.c:47:10 (libcrypto.so.3+0x2d9e8f)
    #19 file_load_file /home/matt/dev/openssl-write/providers/implementations/storemgmt/file_store.c:648:12 (libcrypto.so.3+0x60db8e)
    #20 file_load /home/matt/dev/openssl-write/providers/implementations/storemgmt/file_store.c:808:16 (libcrypto.so.3+0x60d142)
    #21 OSSL_STORE_load /home/matt/dev/openssl-write/crypto/store/store_lib.c:385:18 (libcrypto.so.3+0x4e51eb)
    #22 pem_read_bio_key /home/matt/dev/openssl-write/crypto/pem/pem_pkey.c:74:23 (libcrypto.so.3+0x41c5d3)
    #23 PEM_read_bio_PrivateKey_ex /home/matt/dev/openssl-write/crypto/pem/pem_pkey.c:144:12 (libcrypto.so.3+0x41c9ea)
    #24 load_pkey_pem /home/matt/dev/openssl-write/test/testutil/load.c:80:15 (threadstest+0x4bc481)
    #25 test_multi /home/matt/dev/openssl-write/test/threadstest.c:471:14 (threadstest+0x4b51c1)
    #26 run_tests /home/matt/dev/openssl-write/test/testutil/driver.c:357:21 (threadstest+0x4bb041)
    #27 main /home/matt/dev/openssl-write/test/testutil/main.c:30:15 (threadstest+0x4bc689)
  Mutex M2751 (0x7b1000008980) created at:
    #0 pthread_rwlock_init <null> (threadstest+0x429279)
    #1 CRYPTO_THREAD_lock_new /home/matt/dev/openssl-write/crypto/threads_pthread.c:41:9 (libcrypto.so.3+0x3dd191)
    #2 EVP_PKEY_new /home/matt/dev/openssl-write/crypto/evp/p_lib.c:1428:17 (libcrypto.so.3+0x37c080)
    #3 evp_keymgmt_util_make_pkey /home/matt/dev/openssl-write/crypto/evp/keymgmt_lib.c:72:20 (libcrypto.so.3+0x3659be)
    #4 decoder_construct_EVP_PKEY /home/matt/dev/openssl-write/crypto/encode_decode/decoder_pkey.c:144:24 (libcrypto.so.3+0x2dfc28)
    #5 decoder_process /home/matt/dev/openssl-write/crypto/encode_decode/decoder_lib.c:536:16 (libcrypto.so.3+0x2da162)
    #6 der2key_decode /home/matt/dev/openssl-write/providers/implementations/encode_decode/decode_der2key.c:385:14 (libcrypto.so.3+0x5c8f76)
    #7 decoder_process /home/matt/dev/openssl-write/crypto/encode_decode/decoder_lib.c:627:14 (libcrypto.so.3+0x2da5c6)
    #8 OSSL_DECODER_from_bio /home/matt/dev/openssl-write/crypto/encode_decode/decoder_lib.c:47:10 (libcrypto.so.3+0x2d9e8f)
    #9 OSSL_DECODER_from_data /home/matt/dev/openssl-write/crypto/encode_decode/decoder_lib.c:93:9 (libcrypto.so.3+0x2da8da)
    #10 try_key_value /home/matt/dev/openssl-write/crypto/store/store_result.c:282:11 (libcrypto.so.3+0x4ed32a)
    #11 try_key /home/matt/dev/openssl-write/crypto/store/store_result.c:401:18 (libcrypto.so.3+0x4ec06f)
    #12 ossl_store_handle_load_result /home/matt/dev/openssl-write/crypto/store/store_result.c:147:10 (libcrypto.so.3+0x4eb8eb)
    #13 file_load_construct /home/matt/dev/openssl-write/providers/implementations/storemgmt/file_store.c:528:12 (libcrypto.so.3+0x60e69e)
    #14 decoder_process /home/matt/dev/openssl-write/crypto/encode_decode/decoder_lib.c:536:16 (libcrypto.so.3+0x2da162)
    #15 pem2der_decode /home/matt/dev/openssl-write/providers/implementations/encode_decode/decode_pem2der.c:205:14 (libcrypto.so.3+0x5cd4fb)
    #16 decoder_process /home/matt/dev/openssl-write/crypto/encode_decode/decoder_lib.c:627:14 (libcrypto.so.3+0x2da5c6)
    #17 OSSL_DECODER_from_bio /home/matt/dev/openssl-write/crypto/encode_decode/decoder_lib.c:47:10 (libcrypto.so.3+0x2d9e8f)
    #18 file_load_file /home/matt/dev/openssl-write/providers/implementations/storemgmt/file_store.c:648:12 (libcrypto.so.3+0x60db8e)
    #19 file_load /home/matt/dev/openssl-write/providers/implementations/storemgmt/file_store.c:808:16 (libcrypto.so.3+0x60d142)
    #20 OSSL_STORE_load /home/matt/dev/openssl-write/crypto/store/store_lib.c:385:18 (libcrypto.so.3+0x4e51eb)
    #21 pem_read_bio_key /home/matt/dev/openssl-write/crypto/pem/pem_pkey.c:74:23 (libcrypto.so.3+0x41c5d3)
    #22 PEM_read_bio_PrivateKey_ex /home/matt/dev/openssl-write/crypto/pem/pem_pkey.c:144:12 (libcrypto.so.3+0x41c9ea)
    #23 load_pkey_pem /home/matt/dev/openssl-write/test/testutil/load.c:80:15 (threadstest+0x4bc481)
    #24 test_multi /home/matt/dev/openssl-write/test/threadstest.c:471:14 (threadstest+0x4b51c1)
    #25 run_tests /home/matt/dev/openssl-write/test/testutil/driver.c:357:21 (threadstest+0x4bb041)
    #26 main /home/matt/dev/openssl-write/test/testutil/main.c:30:15 (threadstest+0x4bc689)
  Thread T10 (tid=408199, running) created by main thread at:
    #0 pthread_create <null> (threadstest+0x42713b)
    #1 run_thread /home/matt/dev/openssl-write/test/threadstest.c:80:12 (threadstest+0x4b54f6)
    #2 test_multi /home/matt/dev/openssl-write/test/threadstest.c:483:17 (threadstest+0x4b52aa)
    #3 run_tests /home/matt/dev/openssl-write/test/testutil/driver.c:357:21 (threadstest+0x4bb041)
    #4 main /home/matt/dev/openssl-write/test/testutil/main.c:30:15 (threadstest+0x4bc689)
SUMMARY: ThreadSanitizer: data race (/home/matt/dev/openssl-write/test/threadstest+0x430bd2) in memset
==================
==================
WARNING: ThreadSanitizer: data race (pid=408166)
  Write of size 8 at 0x7b4400000a58 by thread T10 (mutexes: write M2751):
    #0 memset <null> (threadstest+0x430bd2)
    #1 evp_pkey_reset_unlocked /home/matt/dev/openssl-write/crypto/evp/p_lib.c:1402:7 (libcrypto.so.3+0x37c293)
    #2 evp_pkey_downgrade /home/matt/dev/openssl-write/crypto/evp/p_lib.c:1975:9 (libcrypto.so.3+0x375812)
    #3 EVP_PKEY_get0 /home/matt/dev/openssl-write/crypto/evp/p_lib.c:736:10 (libcrypto.so.3+0x379970)
    #4 thread_downgrade_shared_evp_pkey /home/matt/dev/openssl-write/test/threadstest.c:411:9 (threadstest+0x4b5e8b)
    #5 thread_run /home/matt/dev/openssl-write/test/threadstest.c:74:5 (threadstest+0x4b562a)
  Previous read of size 8 at 0x7b4400000a58 by main thread:
    #0 evp_keymgmt_util_export_to_provider /home/matt/dev/openssl-write/crypto/evp/keymgmt_lib.c:101:13 (libcrypto.so.3+0x365b6e)
    #1 evp_pkey_export_to_provider /home/matt/dev/openssl-write/crypto/evp/p_lib.c:1847:15 (libcrypto.so.3+0x376a19)
    #2 evp_pkey_asym_cipher_init /home/matt/dev/openssl-write/crypto/evp/asymcipher.c:49:15 (libcrypto.so.3+0x2fd990)
    #3 EVP_PKEY_encrypt_init /home/matt/dev/openssl-write/crypto/evp/asymcipher.c:171:12 (libcrypto.so.3+0x2fd6fd)
    #4 thread_shared_evp_pkey /home/matt/dev/openssl-write/test/threadstest.c:377:14 (threadstest+0x4b6034)
    #5 test_multi /home/matt/dev/openssl-write/test/threadstest.c:486:5 (threadstest+0x4b52e5)
    #6 run_tests /home/matt/dev/openssl-write/test/testutil/driver.c:357:21 (threadstest+0x4bb041)
    #7 main /home/matt/dev/openssl-write/test/testutil/main.c:30:15 (threadstest+0x4bc689)
  Location is heap block of size 296 at 0x7b4400000a00 allocated by main thread:
    #0 malloc <null> (threadstest+0x425874)
    #1 CRYPTO_malloc /home/matt/dev/openssl-write/crypto/mem.c:184:12 (libcrypto.so.3+0x3bfc59)
    #2 CRYPTO_zalloc /home/matt/dev/openssl-write/crypto/mem.c:191:11 (libcrypto.so.3+0x3bfcc4)
    #3 EVP_PKEY_new /home/matt/dev/openssl-write/crypto/evp/p_lib.c:1418:21 (libcrypto.so.3+0x37c016)
    #4 evp_keymgmt_util_make_pkey /home/matt/dev/openssl-write/crypto/evp/keymgmt_lib.c:72:20 (libcrypto.so.3+0x3659be)
    #5 decoder_construct_EVP_PKEY /home/matt/dev/openssl-write/crypto/encode_decode/decoder_pkey.c:144:24 (libcrypto.so.3+0x2dfc28)
    #6 decoder_process /home/matt/dev/openssl-write/crypto/encode_decode/decoder_lib.c:536:16 (libcrypto.so.3+0x2da162)
    #7 der2key_decode /home/matt/dev/openssl-write/providers/implementations/encode_decode/decode_der2key.c:385:14 (libcrypto.so.3+0x5c8f76)
    #8 decoder_process /home/matt/dev/openssl-write/crypto/encode_decode/decoder_lib.c:627:14 (libcrypto.so.3+0x2da5c6)
    #9 OSSL_DECODER_from_bio /home/matt/dev/openssl-write/crypto/encode_decode/decoder_lib.c:47:10 (libcrypto.so.3+0x2d9e8f)
    #10 OSSL_DECODER_from_data /home/matt/dev/openssl-write/crypto/encode_decode/decoder_lib.c:93:9 (libcrypto.so.3+0x2da8da)
    #11 try_key_value /home/matt/dev/openssl-write/crypto/store/store_result.c:282:11 (libcrypto.so.3+0x4ed32a)
    #12 try_key /home/matt/dev/openssl-write/crypto/store/store_result.c:401:18 (libcrypto.so.3+0x4ec06f)
    #13 ossl_store_handle_load_result /home/matt/dev/openssl-write/crypto/store/store_result.c:147:10 (libcrypto.so.3+0x4eb8eb)
    #14 file_load_construct /home/matt/dev/openssl-write/providers/implementations/storemgmt/file_store.c:528:12 (libcrypto.so.3+0x60e69e)
    #15 decoder_process /home/matt/dev/openssl-write/crypto/encode_decode/decoder_lib.c:536:16 (libcrypto.so.3+0x2da162)
    #16 pem2der_decode /home/matt/dev/openssl-write/providers/implementations/encode_decode/decode_pem2der.c:205:14 (libcrypto.so.3+0x5cd4fb)
    #17 decoder_process /home/matt/dev/openssl-write/crypto/encode_decode/decoder_lib.c:627:14 (libcrypto.so.3+0x2da5c6)
    #18 OSSL_DECODER_from_bio /home/matt/dev/openssl-write/crypto/encode_decode/decoder_lib.c:47:10 (libcrypto.so.3+0x2d9e8f)
    #19 file_load_file /home/matt/dev/openssl-write/providers/implementations/storemgmt/file_store.c:648:12 (libcrypto.so.3+0x60db8e)
    #20 file_load /home/matt/dev/openssl-write/providers/implementations/storemgmt/file_store.c:808:16 (libcrypto.so.3+0x60d142)
    #21 OSSL_STORE_load /home/matt/dev/openssl-write/crypto/store/store_lib.c:385:18 (libcrypto.so.3+0x4e51eb)
    #22 pem_read_bio_key /home/matt/dev/openssl-write/crypto/pem/pem_pkey.c:74:23 (libcrypto.so.3+0x41c5d3)
    #23 PEM_read_bio_PrivateKey_ex /home/matt/dev/openssl-write/crypto/pem/pem_pkey.c:144:12 (libcrypto.so.3+0x41c9ea)
    #24 load_pkey_pem /home/matt/dev/openssl-write/test/testutil/load.c:80:15 (threadstest+0x4bc481)
    #25 test_multi /home/matt/dev/openssl-write/test/threadstest.c:471:14 (threadstest+0x4b51c1)
    #26 run_tests /home/matt/dev/openssl-write/test/testutil/driver.c:357:21 (threadstest+0x4bb041)
    #27 main /home/matt/dev/openssl-write/test/testutil/main.c:30:15 (threadstest+0x4bc689)
  Mutex M2751 (0x7b1000008980) created at:
    #0 pthread_rwlock_init <null> (threadstest+0x429279)
    #1 CRYPTO_THREAD_lock_new /home/matt/dev/openssl-write/crypto/threads_pthread.c:41:9 (libcrypto.so.3+0x3dd191)
    #2 EVP_PKEY_new /home/matt/dev/openssl-write/crypto/evp/p_lib.c:1428:17 (libcrypto.so.3+0x37c080)
    #3 evp_keymgmt_util_make_pkey /home/matt/dev/openssl-write/crypto/evp/keymgmt_lib.c:72:20 (libcrypto.so.3+0x3659be)
    #4 decoder_construct_EVP_PKEY /home/matt/dev/openssl-write/crypto/encode_decode/decoder_pkey.c:144:24 (libcrypto.so.3+0x2dfc28)
    #5 decoder_process /home/matt/dev/openssl-write/crypto/encode_decode/decoder_lib.c:536:16 (libcrypto.so.3+0x2da162)
    #6 der2key_decode /home/matt/dev/openssl-write/providers/implementations/encode_decode/decode_der2key.c:385:14 (libcrypto.so.3+0x5c8f76)
    #7 decoder_process /home/matt/dev/openssl-write/crypto/encode_decode/decoder_lib.c:627:14 (libcrypto.so.3+0x2da5c6)
    #8 OSSL_DECODER_from_bio /home/matt/dev/openssl-write/crypto/encode_decode/decoder_lib.c:47:10 (libcrypto.so.3+0x2d9e8f)
    #9 OSSL_DECODER_from_data /home/matt/dev/openssl-write/crypto/encode_decode/decoder_lib.c:93:9 (libcrypto.so.3+0x2da8da)
    #10 try_key_value /home/matt/dev/openssl-write/crypto/store/store_result.c:282:11 (libcrypto.so.3+0x4ed32a)
    #11 try_key /home/matt/dev/openssl-write/crypto/store/store_result.c:401:18 (libcrypto.so.3+0x4ec06f)
    #12 ossl_store_handle_load_result /home/matt/dev/openssl-write/crypto/store/store_result.c:147:10 (libcrypto.so.3+0x4eb8eb)
    #13 file_load_construct /home/matt/dev/openssl-write/providers/implementations/storemgmt/file_store.c:528:12 (libcrypto.so.3+0x60e69e)
    #14 decoder_process /home/matt/dev/openssl-write/crypto/encode_decode/decoder_lib.c:536:16 (libcrypto.so.3+0x2da162)
    #15 pem2der_decode /home/matt/dev/openssl-write/providers/implementations/encode_decode/decode_pem2der.c:205:14 (libcrypto.so.3+0x5cd4fb)
    #16 decoder_process /home/matt/dev/openssl-write/crypto/encode_decode/decoder_lib.c:627:14 (libcrypto.so.3+0x2da5c6)
    #17 OSSL_DECODER_from_bio /home/matt/dev/openssl-write/crypto/encode_decode/decoder_lib.c:47:10 (libcrypto.so.3+0x2d9e8f)
    #18 file_load_file /home/matt/dev/openssl-write/providers/implementations/storemgmt/file_store.c:648:12 (libcrypto.so.3+0x60db8e)
    #19 file_load /home/matt/dev/openssl-write/providers/implementations/storemgmt/file_store.c:808:16 (libcrypto.so.3+0x60d142)
    #20 OSSL_STORE_load /home/matt/dev/openssl-write/crypto/store/store_lib.c:385:18 (libcrypto.so.3+0x4e51eb)
    #21 pem_read_bio_key /home/matt/dev/openssl-write/crypto/pem/pem_pkey.c:74:23 (libcrypto.so.3+0x41c5d3)
    #22 PEM_read_bio_PrivateKey_ex /home/matt/dev/openssl-write/crypto/pem/pem_pkey.c:144:12 (libcrypto.so.3+0x41c9ea)
    #23 load_pkey_pem /home/matt/dev/openssl-write/test/testutil/load.c:80:15 (threadstest+0x4bc481)
    #24 test_multi /home/matt/dev/openssl-write/test/threadstest.c:471:14 (threadstest+0x4b51c1)
    #25 run_tests /home/matt/dev/openssl-write/test/testutil/driver.c:357:21 (threadstest+0x4bb041)
    #26 main /home/matt/dev/openssl-write/test/testutil/main.c:30:15 (threadstest+0x4bc689)
  Thread T10 (tid=408199, running) created by main thread at:
    #0 pthread_create <null> (threadstest+0x42713b)
    #1 run_thread /home/matt/dev/openssl-write/test/threadstest.c:80:12 (threadstest+0x4b54f6)
    #2 test_multi /home/matt/dev/openssl-write/test/threadstest.c:483:17 (threadstest+0x4b52aa)
    #3 run_tests /home/matt/dev/openssl-write/test/testutil/driver.c:357:21 (threadstest+0x4bb041)
    #4 main /home/matt/dev/openssl-write/test/testutil/main.c:30:15 (threadstest+0x4bc689)
SUMMARY: ThreadSanitizer: data race (/home/matt/dev/openssl-write/test/threadstest+0x430bd2) in memset
==================
==================
WARNING: ThreadSanitizer: data race (pid=408166)
  Write of size 8 at 0x7b4400000a60 by thread T10 (mutexes: write M2751):
    #0 memset <null> (threadstest+0x430bd2)
    #1 evp_pkey_reset_unlocked /home/matt/dev/openssl-write/crypto/evp/p_lib.c:1402:7 (libcrypto.so.3+0x37c293)
    #2 evp_pkey_downgrade /home/matt/dev/openssl-write/crypto/evp/p_lib.c:1975:9 (libcrypto.so.3+0x375812)
    #3 EVP_PKEY_get0 /home/matt/dev/openssl-write/crypto/evp/p_lib.c:736:10 (libcrypto.so.3+0x379970)
    #4 thread_downgrade_shared_evp_pkey /home/matt/dev/openssl-write/test/threadstest.c:411:9 (threadstest+0x4b5e8b)
    #5 thread_run /home/matt/dev/openssl-write/test/threadstest.c:74:5 (threadstest+0x4b562a)
  Previous read of size 8 at 0x7b4400000a60 by main thread:
    #0 evp_pkey_export_to_provider /home/matt/dev/openssl-write/crypto/evp/p_lib.c:1721:26 (libcrypto.so.3+0x376072)
    #1 evp_pkey_asym_cipher_init /home/matt/dev/openssl-write/crypto/evp/asymcipher.c:49:15 (libcrypto.so.3+0x2fd990)
    #2 EVP_PKEY_encrypt_init /home/matt/dev/openssl-write/crypto/evp/asymcipher.c:171:12 (libcrypto.so.3+0x2fd6fd)
    #3 thread_shared_evp_pkey /home/matt/dev/openssl-write/test/threadstest.c:377:14 (threadstest+0x4b6034)
    #4 test_multi /home/matt/dev/openssl-write/test/threadstest.c:486:5 (threadstest+0x4b52e5)
    #5 run_tests /home/matt/dev/openssl-write/test/testutil/driver.c:357:21 (threadstest+0x4bb041)
    #6 main /home/matt/dev/openssl-write/test/testutil/main.c:30:15 (threadstest+0x4bc689)
  Location is heap block of size 296 at 0x7b4400000a00 allocated by main thread:
    #0 malloc <null> (threadstest+0x425874)
    #1 CRYPTO_malloc /home/matt/dev/openssl-write/crypto/mem.c:184:12 (libcrypto.so.3+0x3bfc59)
    #2 CRYPTO_zalloc /home/matt/dev/openssl-write/crypto/mem.c:191:11 (libcrypto.so.3+0x3bfcc4)
    #3 EVP_PKEY_new /home/matt/dev/openssl-write/crypto/evp/p_lib.c:1418:21 (libcrypto.so.3+0x37c016)
    #4 evp_keymgmt_util_make_pkey /home/matt/dev/openssl-write/crypto/evp/keymgmt_lib.c:72:20 (libcrypto.so.3+0x3659be)
    #5 decoder_construct_EVP_PKEY /home/matt/dev/openssl-write/crypto/encode_decode/decoder_pkey.c:144:24 (libcrypto.so.3+0x2dfc28)
    #6 decoder_process /home/matt/dev/openssl-write/crypto/encode_decode/decoder_lib.c:536:16 (libcrypto.so.3+0x2da162)
    #7 der2key_decode /home/matt/dev/openssl-write/providers/implementations/encode_decode/decode_der2key.c:385:14 (libcrypto.so.3+0x5c8f76)
    #8 decoder_process /home/matt/dev/openssl-write/crypto/encode_decode/decoder_lib.c:627:14 (libcrypto.so.3+0x2da5c6)
    #9 OSSL_DECODER_from_bio /home/matt/dev/openssl-write/crypto/encode_decode/decoder_lib.c:47:10 (libcrypto.so.3+0x2d9e8f)
    #10 OSSL_DECODER_from_data /home/matt/dev/openssl-write/crypto/encode_decode/decoder_lib.c:93:9 (libcrypto.so.3+0x2da8da)
    #11 try_key_value /home/matt/dev/openssl-write/crypto/store/store_result.c:282:11 (libcrypto.so.3+0x4ed32a)
    #12 try_key /home/matt/dev/openssl-write/crypto/store/store_result.c:401:18 (libcrypto.so.3+0x4ec06f)
    #13 ossl_store_handle_load_result /home/matt/dev/openssl-write/crypto/store/store_result.c:147:10 (libcrypto.so.3+0x4eb8eb)
    #14 file_load_construct /home/matt/dev/openssl-write/providers/implementations/storemgmt/file_store.c:528:12 (libcrypto.so.3+0x60e69e)
    #15 decoder_process /home/matt/dev/openssl-write/crypto/encode_decode/decoder_lib.c:536:16 (libcrypto.so.3+0x2da162)
    #16 pem2der_decode /home/matt/dev/openssl-write/providers/implementations/encode_decode/decode_pem2der.c:205:14 (libcrypto.so.3+0x5cd4fb)
    #17 decoder_process /home/matt/dev/openssl-write/crypto/encode_decode/decoder_lib.c:627:14 (libcrypto.so.3+0x2da5c6)
    #18 OSSL_DECODER_from_bio /home/matt/dev/openssl-write/crypto/encode_decode/decoder_lib.c:47:10 (libcrypto.so.3+0x2d9e8f)
    #19 file_load_file /home/matt/dev/openssl-write/providers/implementations/storemgmt/file_store.c:648:12 (libcrypto.so.3+0x60db8e)
    #20 file_load /home/matt/dev/openssl-write/providers/implementations/storemgmt/file_store.c:808:16 (libcrypto.so.3+0x60d142)
    #21 OSSL_STORE_load /home/matt/dev/openssl-write/crypto/store/store_lib.c:385:18 (libcrypto.so.3+0x4e51eb)
    #22 pem_read_bio_key /home/matt/dev/openssl-write/crypto/pem/pem_pkey.c:74:23 (libcrypto.so.3+0x41c5d3)
    #23 PEM_read_bio_PrivateKey_ex /home/matt/dev/openssl-write/crypto/pem/pem_pkey.c:144:12 (libcrypto.so.3+0x41c9ea)
    #24 load_pkey_pem /home/matt/dev/openssl-write/test/testutil/load.c:80:15 (threadstest+0x4bc481)
    #25 test_multi /home/matt/dev/openssl-write/test/threadstest.c:471:14 (threadstest+0x4b51c1)
    #26 run_tests /home/matt/dev/openssl-write/test/testutil/driver.c:357:21 (threadstest+0x4bb041)
    #27 main /home/matt/dev/openssl-write/test/testutil/main.c:30:15 (threadstest+0x4bc689)
  Mutex M2751 (0x7b1000008980) created at:
    #0 pthread_rwlock_init <null> (threadstest+0x429279)
    #1 CRYPTO_THREAD_lock_new /home/matt/dev/openssl-write/crypto/threads_pthread.c:41:9 (libcrypto.so.3+0x3dd191)
    #2 EVP_PKEY_new /home/matt/dev/openssl-write/crypto/evp/p_lib.c:1428:17 (libcrypto.so.3+0x37c080)
    #3 evp_keymgmt_util_make_pkey /home/matt/dev/openssl-write/crypto/evp/keymgmt_lib.c:72:20 (libcrypto.so.3+0x3659be)
    #4 decoder_construct_EVP_PKEY /home/matt/dev/openssl-write/crypto/encode_decode/decoder_pkey.c:144:24 (libcrypto.so.3+0x2dfc28)
    #5 decoder_process /home/matt/dev/openssl-write/crypto/encode_decode/decoder_lib.c:536:16 (libcrypto.so.3+0x2da162)
    #6 der2key_decode /home/matt/dev/openssl-write/providers/implementations/encode_decode/decode_der2key.c:385:14 (libcrypto.so.3+0x5c8f76)
    #7 decoder_process /home/matt/dev/openssl-write/crypto/encode_decode/decoder_lib.c:627:14 (libcrypto.so.3+0x2da5c6)
    #8 OSSL_DECODER_from_bio /home/matt/dev/openssl-write/crypto/encode_decode/decoder_lib.c:47:10 (libcrypto.so.3+0x2d9e8f)
    #9 OSSL_DECODER_from_data /home/matt/dev/openssl-write/crypto/encode_decode/decoder_lib.c:93:9 (libcrypto.so.3+0x2da8da)
    #10 try_key_value /home/matt/dev/openssl-write/crypto/store/store_result.c:282:11 (libcrypto.so.3+0x4ed32a)
    #11 try_key /home/matt/dev/openssl-write/crypto/store/store_result.c:401:18 (libcrypto.so.3+0x4ec06f)
    #12 ossl_store_handle_load_result /home/matt/dev/openssl-write/crypto/store/store_result.c:147:10 (libcrypto.so.3+0x4eb8eb)
    #13 file_load_construct /home/matt/dev/openssl-write/providers/implementations/storemgmt/file_store.c:528:12 (libcrypto.so.3+0x60e69e)
    #14 decoder_process /home/matt/dev/openssl-write/crypto/encode_decode/decoder_lib.c:536:16 (libcrypto.so.3+0x2da162)
    #15 pem2der_decode /home/matt/dev/openssl-write/providers/implementations/encode_decode/decode_pem2der.c:205:14 (libcrypto.so.3+0x5cd4fb)
    #16 decoder_process /home/matt/dev/openssl-write/crypto/encode_decode/decoder_lib.c:627:14 (libcrypto.so.3+0x2da5c6)
    #17 OSSL_DECODER_from_bio /home/matt/dev/openssl-write/crypto/encode_decode/decoder_lib.c:47:10 (libcrypto.so.3+0x2d9e8f)
    #18 file_load_file /home/matt/dev/openssl-write/providers/implementations/storemgmt/file_store.c:648:12 (libcrypto.so.3+0x60db8e)
    #19 file_load /home/matt/dev/openssl-write/providers/implementations/storemgmt/file_store.c:808:16 (libcrypto.so.3+0x60d142)
    #20 OSSL_STORE_load /home/matt/dev/openssl-write/crypto/store/store_lib.c:385:18 (libcrypto.so.3+0x4e51eb)
    #21 pem_read_bio_key /home/matt/dev/openssl-write/crypto/pem/pem_pkey.c:74:23 (libcrypto.so.3+0x41c5d3)
    #22 PEM_read_bio_PrivateKey_ex /home/matt/dev/openssl-write/crypto/pem/pem_pkey.c:144:12 (libcrypto.so.3+0x41c9ea)
    #23 load_pkey_pem /home/matt/dev/openssl-write/test/testutil/load.c:80:15 (threadstest+0x4bc481)
    #24 test_multi /home/matt/dev/openssl-write/test/threadstest.c:471:14 (threadstest+0x4b51c1)
    #25 run_tests /home/matt/dev/openssl-write/test/testutil/driver.c:357:21 (threadstest+0x4bb041)
    #26 main /home/matt/dev/openssl-write/test/testutil/main.c:30:15 (threadstest+0x4bc689)
  Thread T10 (tid=408199, running) created by main thread at:
    #0 pthread_create <null> (threadstest+0x42713b)
    #1 run_thread /home/matt/dev/openssl-write/test/threadstest.c:80:12 (threadstest+0x4b54f6)
    #2 test_multi /home/matt/dev/openssl-write/test/threadstest.c:483:17 (threadstest+0x4b52aa)
    #3 run_tests /home/matt/dev/openssl-write/test/testutil/driver.c:357:21 (threadstest+0x4bb041)
    #4 main /home/matt/dev/openssl-write/test/testutil/main.c:30:15 (threadstest+0x4bc689)
SUMMARY: ThreadSanitizer: data race (/home/matt/dev/openssl-write/test/threadstest+0x430bd2) in memset
==================
ThreadSanitizer:DEADLYSIGNAL
==408166==ERROR: ThreadSanitizer: SEGV on unknown address 0x0000000000b8 (pc 0x7f6cbb791d1c bp 0x7ffc90653f20 sp 0x7ffc90653e20 T408166)
==408166==The signal is caused by a READ memory access.
==408166==Hint: address points to the zero page.
ThreadSanitizer:DEADLYSIGNAL
    #0 evp_keymgmt_util_export_to_provider /home/matt/dev/openssl-write/crypto/evp/keymgmt_lib.c:121:29 (libcrypto.so.3+0x365d1c)
    #1 evp_pkey_export_to_provider /home/matt/dev/openssl-write/crypto/evp/p_lib.c:1847:15 (libcrypto.so.3+0x376a19)
    #2 evp_pkey_asym_cipher_init /home/matt/dev/openssl-write/crypto/evp/asymcipher.c:49:15 (libcrypto.so.3+0x2fd990)
    #3 EVP_PKEY_encrypt_init /home/matt/dev/openssl-write/crypto/evp/asymcipher.c:171:12 (libcrypto.so.3+0x2fd6fd)
    #4 thread_shared_evp_pkey /home/matt/dev/openssl-write/test/threadstest.c:377:14 (threadstest+0x4b6034)
    #5 test_multi /home/matt/dev/openssl-write/test/threadstest.c:486:5 (threadstest+0x4b52e5)
    #6 run_tests /home/matt/dev/openssl-write/test/testutil/driver.c:357:21 (threadstest+0x4bb041)
    #7 main /home/matt/dev/openssl-write/test/testutil/main.c:30:15 (threadstest+0x4bc689)
    #8 __libc_start_main /build/glibc-ZN95T4/glibc-2.31/csu/../csu/libc-start.c:308:16 (libc.so.6+0x270b2)
    #9 _start <null> (threadstest+0x41f9bd)
ThreadSanitizer can not provide additional info.
SUMMARY: ThreadSanitizer: SEGV /home/matt/dev/openssl-write/crypto/evp/keymgmt_lib.c:121:29 in evp_keymgmt_util_export_to_provider
==408166==ABORTING
../../util/wrap.pl ../../test/threadstest -fips ../../test/recipes/90-test_threads_data => 66

Is this a case where we could get away with a global lock or a per library context one?

Is this a case where we could get away with a global lock or a per library context one?

No - I don't think so. Currently the downgrade code goes to great pains to ensure that the EVP_PKEY lock is held during a downgrade. Unfortunately it is no sufficient. The downgrade code wipes the entire EVP_PKEY - with the exception of the lock - and recreates it all. However, even though the lock is held, many of the fields in an EVP_PKEY are considered to be immutable once the key is created and are accessed locklessly by lots of functions. So, holding the EVP_PKEY lock doesn't solve the problem. Having a global or per library context lock doesn't really resolve this problem. Also, converting everywhere that accesses one of these fields to first acquire a lock isn't particularly desirable due to lock contention.

Is it an option to not destruct things, keep the old data, and add
some other data?

That seems like the most sensible solution to me - although I'm not too clear on why things were done the way they are in the first place. Perhaps @levitte might comment.

I'd be interested in finding out why.

I talked this over with @levitte. The reason the key is wiped is to avoid having a key with two origins. The problem is that if the legacy key is not an origin after it is downgraded then it becomes unreliable...e.g. what happens if the provider side key changes in the meantime, or if the application changes the legacy key.
Possibly we could accept these restrictions. So if you call (for example) EVP_PKEY_get0_RSA() then it is a "point in time" copy of the actual key. If you change the provider side key, or update the RSA object then the changes won't be synced.

Currently when you create a legacy EVP_PKEY from scratch and then upgrade it for an operation, it will be a snapshot of the RSA data at the time, or not? Will that upgrade be cached?

Currently when you create a legacy EVP_PKEY from scratch and then upgrade it for an operation, it will be a snapshot of the RSA data at the time, or not? Will that upgrade be cached?

In that scenario there is a "dirty" counter to detect when changes are made to the legacy key vs the upgraded provider key. If the legacy key changes then the provider key is abandoned and re-upgraded when needed.

Note that there are a number of places where evp_pkey_downgrade() is currently called, that we can replace with a call of evp_pkey_copy_downgraded().  evp_pkey_downgrade() should really be used As Little As Possible.

If you called EVP_PKEY_get0_RSA(), then changed the key, and then
used the pointer EVP_PKEY_get0_RSA() returned previously, I think
you're asking for problems. I guess that might have worked, we
could reuse the object, but it could also turn into a dangling
pointer.
But I don't understand the 2 origins part. I assume the key is one
of:

legacy, not upgraded
legacy, upgraded
non-legacy, not downgraded
non-legacy, downgraded

And that we have metadata to know which one it is.
(You talk about a legacy key being downgraded, which is not in
that list.)
Key changes are not something that is thread safe, but if the
upgrade or downgrade doesn't happen at the same time, the upgrade
or downgrade should be thread safe.
I assume that we do not allow changing a non-legacy key once it's
set.
Is upgrading also not thread-safe?

But I don't understand the 2 origins part

Every key has an "origin", i.e. the first location it existed in. That can either be a legacy key or a provider. During the course of its use the key might get copied to other providers and cached - but those are subordinate to the "origin". If a key exists only on the provider side then the process of "downgrading" the key effectively changes the origin to be the legacy key. Effectively if a legacy key is present then it is always the origin.

I assume that we do not allow changing a non-legacy key once it's set.

This is something I'm not clear on.

Is upgrading also not thread-safe?

AFAIK this is ok

But I don't understand the 2 origins part

An EVP_PKEY has a pointer to a keytype-specific structure for the key data (the numbers, parameters, yada yada).
That used to be a pointer to a DSA, DH, RSA, or EC_KEY structure, and were all governed with the help of EVP_PKEY_METHOD and EVP_PKEY_ASN1_METHOD.  I've called the "legacy origin".
With providers, we have a different pointer that points at whatever key data the provider holds, and it's governed with the help of an EVP_KEYMGMT.  I've called this the "provider native origin"
There's also a cache of key data exports.  This is used to hold additional pointers to key data, held by other providers than the one hold the "provider native origin", whenever an operation such as signing needs it (the technical reason being that provider A and provider B can't be expected to have the same internal structures for their keys).  What happens is that the origin key gets exported to the provider that's being used for the operation, regardless of form (i.e it handles exporting from a legacy origin as well from a provider native origin).
There are a number of tricky bits in there that make it very difficult to have an EVP_PKEY hold both types of origins at the same time.  Data synchronisation between the two is a problem we simply avoid, and thereby also, when exporting the internal key to do an operation of some sort (like signing), we avoid having to "guess" which of the two origins is the most accurate.
From this, one can quickly conclude that this list is overstating it:

legacy, not upgraded
legacy, upgraded
non-legacy, not downgraded
non-legacy, downgraded

There are only two possible origins, "legacy" or "provider native", period.  There is no "upgraded" or "downgraded" state.  A downgrade means that the EVP_PKEY gets transformed (or a copy is created, if evp_pkey_copy_downgraded() is used) from having a provider native internal key to having a legacy internal key.
Also, unless I'm hugely misremembering things, there is no way to upgrade a key...  the cached export that is performed when initializing an operation should be enough.

The reason we have a downgrade functionality at all is that we have certain functions that simply cannot be used with provider keys.  Things like EVP_PKEY_get0_RSA() being a perfect example.
evp_pkey_downgrade() is a bit over-used, however, and we should work to minimize its use to the bare minimum.

I assume that we do not allow changing a non-legacy key once it's set.

No.  One would wish that they're immutable, but that isn't the case.  EVP_KEYMGMT has an OSSL_FUNC_keymgmt_set_params() call, and we do support the use of it for these things:

DH, EC, EDxxx, Xxxx: setting the public key
EC: flipping the ECDH cofactor mode

To futher expand on the export cache, there's trigger that purges that export; the dirty count that we do in legacy.  The idea is that any time an export is to be done, there's a check to see if the origin internal key has already been exported, and doesn't do it again.  However, a dirty count change will clear the cache first, meaning a new export will be made.  In essence, this is what the export call does:

check if the dirty count in the EVP_PKEY has changed since the previous time (in the EVP_PKEY, there's dirty_cnt, which is incremented by legacy key code whenever the key data is changed, and the export function maintains a copy in dirty_cnt_copy to compare against).
If the dirty count has changed, clear the export cache
check if there's an entry in the export cache that's the same provider that an export is to be made to.
If one is found, do nothing more.
export the internal key to the provider, using appropriate methods (legacy keys have an export function, provider side KEYMGMT export their key data in OSSL_PARAM form), and save away the key data pointer and corresponding keymgmt in the cache.

Can this terminology about upgrade/downgrade be written down in docs somewhere?

Yes, I was thinking that the comments I wrote could be a fairly good write-up that could become more permanent. I take your comment as confirmation that what I wrote was indeed good enough, @richsalz. Thank you.

In all of this, we haven't really thought of the dirty count for anything but legacy origins.  It should probably be incremented by EVP_PKEY_set_params() as well.  It's currently not, and that's a bug.

Fix in #14056

Open question: we do have an internal EVP_PKEY(7) which does explain a bit, and that I'm currently fleshing out with what I wrote in the comments above.  Should this document be made public, i.e. should we do this move?
doc/internal/man7/EVP_PKEY.pod -> doc/man7/EVP_PKEY.pod
Something to be noted is that some time in the future (as soon as possible is my hope, but we're still talking 5 years from when 3.0 is released), the legacy "origin" will be removed and we will only have the provider-native "origin" to deal with.

Something to be noted is that some time in the future (as soon as possible is my hope, but we're still talking 5 years from when 3.0 is released), the legacy "origin" will be removed and we will only have the provider-native "origin" to deal with.

Off topic side note: I actually hope that we will start removing the legacy codepaths much earlier - i.e. for example after releasing 3.2 and declaring it LTS we'll start developing 4.0 where all the legacy codepaths and deprecated stuff from 3.0 is dropped. The 5 years promise will be fulfilled by the 3.2 LTS release and we could in theory have nice and clean 4.0 in 3 years from when 3.0 is released. Otherwise the "5 years from when 3.0 is released" sounds quite depressing. :wink:

@t8m, the thing that absolutely needs legacy support is ENGINEs.  Without that, they stop functioning, full stop, so it's basically a matter of when we remove ENGINE support.

Note that 5 years is our policy:

No existing public interface can be removed until its replacement has been in place in an LTS stable release. The original interface must also have been documented as deprecated for at least 5 years. A public interface is any function, structure or macro declared in a public header file.

We can decide to make an exception from this rule, but there you go...

Well, I'd propose to amend the rule (but it is of course OMC call) to say something like: The original interface must stay supported within a supported release for at least 5 years since the first release where the deprecation happened. Which of course means if we declared 3.0 LTS we could start working on 4.0 dropping all legacy (including engines of course) right away after the release but I am not saying that would be the right thing. If the above wording is used in the policy we might even make the supported lifetime of the deprecated API even longer - for example 7 years.

The original interface must stay supported within a supported release for at least 5 years since the first release where the deprecation happened.

Er, isn't that exactly what the policy currently say, just in slightly different words?  Basically, there are two conditions:

condition 1: replacement functionality must exist in an LTS release
"No existing public interface can be removed until its replacement has been in place in an LTS stable release."
condition 2: must have been documented documented as deprecated for 5 years
"The original interface must also have been documented as deprecated for at least 5 years."

Those are two separate conditions.  Mixing in LTS in condition 2 is not applicable.

I've updated doc/internal/man7/EVP_PKEY.pod, see #14059

So after reading that new manpage, what I think that happens in
case of a downgrade is:

A low level type like RSA is generated
The EVP_KEYMGNT is moved to the operation cache

I currently fail to see why this would involve any destruction.

I currently fail to see why this would involve any destruction.

Me too...  I think someone may have misread the code.  Here is the lines that moves the previous provider side data to the cache:
https://github.com/openssl/openssl/blob/9db6af922c48c5cab5398ef9f37e425e382f9440/crypto/evp/p_lib.c#L1965-L1975
I may have inadvertently "confirmed" that the old provider side key data was indeed destroyed during my conversation with @mattcaswell, but that's more because I didn't have all the details in mind at the moment...

The destruction happens in the call to evp_pkey_reset_unlocked() a few lines above this point.


Mocking: Add "out-of-the-box" working example of FreeRTOS and other components (IDFGH-14274)

Is your feature request related to a problem?
The "problem" I see is that while mocking seems to be integrated (At least for some components) on esp-idf, I haven't been able to find a working example on how to use these mocking capabilities. I have read the documentation, on both esp-idf and CMock, the problem is how to go from that, to include tests that rely on mocking to an existent project. Esp-idf uses CMake, but not in the "traditional" way I have seen in other projects, so how to do this doesn't seem trivial.
Describe the solution you'd like.
I'd like to see a working project example, like many on the examples folder of esp-idf and were of GREAT HELP. But defining tests that use mocking. FreeRTOS mocking alone would be a huge added value, since you can test through software alone task interaction logic for complex applications.
Describe alternatives you've considered.
Since I have been unable to integrate mocking natively, I have been considering on using Ceedling as a nested isolated project, and doing the mocking myself. But I am not so familiar with Ceedling so I'd need more time to achieve this.
Additional context.
No response

Hi, did you take a look at this part of the docs?
At the end it also links to some examples, including esp-event tests which uses mocks for the freertos calls.

Hi @ESP-Marius ! Sorry for the late reply. Yes, I've read the section of the docs regarding mocks, I didn't try this particular example tho, by using the esp-event tests project I was able to compile the tests and run them by hand, thank you!
However, I still have some doubts, regarding how to integrate this onto a full project. If I can get this working I could make a pull request to add it as an example if it helps.
My doubts are:

When I work with idf, I'll be ofc targeting an esp32 microcontroller based board. What I think people would expect is to be able to test their code on the host through some command, and if they want to compile their project for the target, then use some other command instead. How can I do this with IDF? The examples overwrite the "sdkconfig.defaults" to target Linux if I am not mistaken
All the examples use like an isolated project to define the test runner executable. In a real project I believe one would have many components, and would like to test each component individually in the host. The best way to do this is to define one nested project per component? Or is there a native way of doing this through the SDK?


(Bug) Adding Sharpness to weapons doesn't really change the displayed old blue tooltip

Ah yeah, I forgot the weird quirks of the vanilla tooltip... If an item has specific default modifiers (with specific UUIDs/IDs as of 1.21) for damage and attack speed, then those will show up in green and include the base damage as well as enchantment damage (in theory). If the modifiers don't match that condition, the game will instead use the blue tooltip, which only shows the additional damage over base damage and does not include enchantment modifiers (for whatever reason). My mod currently basically just tells the client to switch to the second "kind" of tooltip, which I forgot doesn't include the enchantment modifiers. I will fix that soon.
Curiously, as of 1.21, this is broken with the default green tooltips as well (see MC-271840), so for the 1.21 version, I'll add an option to fix that as well.

Ok, so after looking into it, I've decided not to fix this bug in 1.21, as that version introduced datapack-customizable enchantments which makes this much more difficult than expected (and is probably the reason why it doesn't with the vanilla tooltip in 1.21 in the first place). I will release a fix for 1.20.6 though.

@rizecookey yeah, i've recently just realized this is a vanilla bug

This is now fixed in <IP_ADDRESS> for 1.20.6, I'll wait for a fix in vanilla before I fix it in CombatEdit for 1.21.1.


Infix operators spacing inconsistency

Creating such aliases for float operators results in strange formatting of multiply operator. It should be consistent with others as follows.
Expected:
let (+) = (+.);
let (*) = (*.);
let (-) = (-.);
let (/) = (/.);

Received:
let (+) = (+.);
let ( * ) = ( *. );
let (-) = (-.);
let (/) = (/.);

I think that might be a thing from OCaml, where (* is a comment start.


hive_flutter ^2.0.5 which doesn't match any versions

Question
flutter pub get .
Code sample
Pub get  happen error ' hive_flutter ^2.0.5 which doesn't match any versions'

Version

Platform: iOS, Android,
Flutter version: [2.5.1]
Hive version: [2.0.5]

@GavinDon hive_flutter latest version is 1.1.0
You can check that here
https://pub.dev/packages/hive_flutter/changelog

@GavinDon hive_flutter latest version is 1.1.0 You can check that here https://pub.dev/packages/hive_flutter/changelog

Thank you. I was careless. I thought all versions were consistent


Remove detectors code that is not currently working

When we fail to detect the build command with Netlify Dev, many detectors are adding a default command.
The way this is currently done does not work. This is because the possibleArgsArr are the arguments passed to command which is npm run or yarn. For example, if possibleArgsArr is ['gatsby', 'develop'], then npm run gatsby develop will be run instead of simply gatsby develop.
A follow-up PR will fix how we assign a default build command. This PR just removes the code that is currently failing.

The way this is currently done does not work.
🤦


[ISSUE] Unable to retrieve the return value of the list method in TablesAPI class

Description
I am unable to retrieve the return value of the list method in the TablesAPI class.
Reproduction
import time

from databricks.sdk import WorkspaceClient

w = WorkspaceClient()

created_catalog = w.catalogs.create(name=f'sdk-{time.time_ns()}')

created_schema = w.schemas.create(name=f'sdk-{time.time_ns()}', catalog_name=created_catalog.name)

all_tables = w.tables.list(catalog_name=created_catalog.name, schema_name=created_schema.name)
print(all_tables)

# cleanup
w.schemas.delete(full_name=created_schema.full_name)
w.catalogs.delete(name=created_catalog.name, force=True)

Expected behavior
Gets an array of all tables for the current metastore under the parent catalog and schema.
Other Information

Enviroment: Azure Databricks
Runtime Version: 13.3 LTS ML (includes Apache Spark 3.4.1, Scala 2.12)

Additional context
Could it be that the reason is that the return value of the method has not been set? It seems that the list_summaries method also does not have a return value set.
https://github.com/databricks/databricks-sdk-py/blob/bbe81c13c4a0275020d241b78f61cdddf349adc2/databricks/sdk/service/catalog.py#L5525-L5533

This method returns a generator. If you want to turn it into a list, you can do list(all_tables). Please reopen if you have issues with this.

Thank you for your response. By making the following changes, it worked as expected.I appreciate your help.
import time

from databricks.sdk import WorkspaceClient

w = WorkspaceClient()

created_catalog = w.catalogs.create(name=f"sdk-{time.time_ns()}")
created_schema = w.schemas.create(
    name=f"sdk-{time.time_ns()}",
    catalog_name=created_catalog.name,
)
spark.sql(
    f"""
    CREATE TABLE `{created_catalog.name}`.`{created_schema.name}`.table_01
    """
)

all_tables = w.tables.list(
    catalog_name=created_catalog.name, schema_name=created_schema.name,
)
print(list(all_tables))

# cleanup
w.schemas.delete(full_name=created_schema.full_name)
w.catalogs.delete(name=created_catalog.name, force=True)


Add timeCreated to properties for VM, VMSS, CR, DH resources

Add timeCreated to properties for VM, VMSS, CR, and DH resources
Set location in Resource as not required

MSFT employees can try out our new experience at OpenAPI Hub  - one location for using our validation tools and finding your workflow.

Changelog
Add a changelog entry for this PR by answering the following questions:

What's the purpose of the update?

[ ] new service onboarding
[x] new API version
[ ] update existing version for new feature
[ ] update existing version to fix swagger quality issue in s360
[ ] Other, please clarify

When are you targeting to deploy the new service/feature to public regions? Please provide the date or, if the date is not yet available, the month.
2021-11-01
When do you expect to publish the swagger? Please provide date or, the the date is not yet available, the month.
2021-11-01
If updating an existing version, please select the specific langauge SDKs and CLIs that must be refreshed after the swagger is published.

[ ] SDK of .NET (need service team to ensure code readiness)
[ ] SDK of Python
[ ] SDK of Java
[ ] SDK of Js
[ ] SDK of Go
[ ] PowerShell
[ ] CLI
[ ] Terraform
[x] No refresh required for updates in this PR

Contribution checklist:

[ ] I commit to follow the Breaking Change Policy of "no breaking changes"
[ ] I have reviewed the documentation for the workflow.
[ ] Validation tools were run on swagger spec(s) and errors have all been fixed in this PR. How to fix?

If any further question about AME onboarding or validation tools, please view the FAQ.
ARM API Review Checklist

Applicability: :warning:
If your changes encompass only the following scenarios, you should SKIP this section, as these scenarios do not require ARM review.

Change to data plane APIs
Adding new properties
All removals

Otherwise your PR may be subject to ARM review requirements. Complete the following:

[ ] Check this box if any of the following apply to the PR so that label “WaitForARMFeedback” will be added automatically to begin ARM API Review. Failure to comply may result in delays to the manifest.

Adding a new service
Adding new API(s)
Adding a new API version
-[ ] To review changes efficiently, ensure you copy the existing version into the new directory structure for first commit and then push new changes, including version updates, in separate commits.

[ ] Ensure you've reviewed following guidelines including ARM resource provider contract and REST guidelines. Estimated time (4 hours). This is required before you can request review from ARM API Review board.

[ ] If you are blocked on ARM review and want to get the PR merged with urgency, please get the ARM oncall for reviews (RP Manifest Approvers team under Azure Resource Manager service) from IcM and reach out to them.

Breaking Change Review Checklist
If any of the following scenarios apply to the PR, request approval from the Breaking Change Review Board as defined in the Breaking Change Policy.

[ ] Removing API(s) in a stable version
[ ] Removing properties in a stable version
[ ] Removing API version(s) in a stable version
[ ] Updating API in a stable or public preview version with Breaking Change Validation errors
[ ] Updating API(s) in public preview over 1 year (refer to Retirement of Previews)

Action: to initiate an evaluation of the breaking change, create a new intake using the template for breaking changes. Addition details on the process and office hours are on the Breaking change Wiki.
Please follow the link to find more details on PR review process.

@ArcturusZhang @grizzlytheodore @Sandido
Checking to make sure you saw this PR into 2021-11-01? Validations look unrelated to changes. Prettier is flagging the null values and model validation is flagging a format int32 type; both are not changes in the PR

/azp run

Checks failing due to recent changes on base branch:
https://github.com/Azure/azure-rest-api-specs/commit/5c18a1728fe2dd67c1ff90acb4027b36abe89dc6
@Sandido @grizzlytheodore

/azp run


Moved simplecov_setup into lib folder

As simplecov_setup is a runtime dependency of the cucumber bin script it
should not be placed into spec/ folder as there should be only test
parts be placed. The old code bites us at SUSE as all tests are split
into a testsuite package which results in a currently broken cucumber.

related to the discussion in https://github.com/cucumber/cucumber-ruby/commit/4b8343ab3d47c6f6a17faaf82a0b4fd30bb3f4ac

Build failed just because of coveralls API error.

Thanks!


Re-run definitions:generateMavlink task

Apologies for the massive diff, but I just tried running gradle definitions:generateMavlink on the latest versions of the Mavlink XML definition files from the official repo. Seems there have been a few changes since this was last run!
From a glance, the changes include (in roughly-descending order of impact):

new/renamed fields
new enums/types
new/renamed enum entries
sub-dialect changes for some of the dialects
SpeedType moved from ardupilotmega to common dialect
some classes have @WorkInProgress annotations removed
extra comments and typo fixes

Also bear in mind that I've not actually tested any of this on any actual drones - just thought it might be useful.
Might be useful to have this kind of thing automated to help with keeping on top of changes. I think Github Actions allows cronjobs, I could set that up if you think it's useful :+1:

@rowden-jon good PRs like these are wholeheartedly welcome. I'll do a quick review and test. I'll create a release soon.

Might be useful to have this kind of thing automated to help with keeping on top of changes. I think Github Actions allows cronjobs, I could set that up if you think it's useful 👍

That would be a massive help!
I too want to set up automated workflows and start work on the multiplatform part (maybe even some core MAVLink microservices), but I have been unable to find time for those things for a while.

I hope you generated these using the latest stable MAVLink definitions?
Also, I am thinking of setting up the workflow in a way that takes the input as the GitHub URL of the files. That would remove the need to maintain the MAVlink submodule.

I hope you generated these using the latest stable MAVLink definitions?

Latest commit of the repo on main. They don't have releases on there, and the latest tag was in 2019 so that's all we have to define as "stable". That being said, their CI has been failing for the past few commits - apparently only on some Node.JS tests.

Also, I am thinking of setting up the workflow in a way that takes the input as the GitHub URL of the files. That would remove the need to maintain the MAVlink submodule.

Agreed - can use this to get the latest commit in the definitions folder. Would be a nifty pre-check to see whether the definitions have changed before we clone.

Okay. Can you please also check out the mavlink submodule to the latest master commit and push that change as well?

Didn't even realise that was a submodule! Sorted :white_check_mark:

Thanks! Just give me a couple of days.


Added microservice entry-point

Discussion results:
Common factory constructors:

migrate from constructors to separate static methods
user can be able to create common factory via craterFromArgs(vararg args: String) and createFromProvider(provider: IConfigurationProvider). Other ways should be deprecated

Common factory methods:

public <T> T getConfiguration(Path configPath, Class<T> configClass, ObjectMapper customObjectMapper) should be removed because this method can be implemented out side from common factory
protected abstract Path getPathToCustomConfiguration() should be removed after createFromProvider implementation

JsonConfigurationProvider:

public constructor should be replaced to a static method
class should be public because it is useful for tests


there is no suite setup execute info in the log

only display the test setup log. but there is no suite setup info . I am sure the suite or session setup is exetuted.

hmm, i thought pytest didn't really have a concept of suite-level setup and teardown, only fixtures that get called by individual tests as they're needed. but reading into it more i see it supports setup_module and teardown_module functions. i could probably hook those to make them show in the log as suite-level setup/teardowns.
could you please confirm that's how you're defining your suite setup? or are there other ways to do it?

def pytest_runtest_setup():
logging.info("this is a test")
this  function has been logged into the report. Others listener or pytest_sessionstart was not.

ok so there's a few reasons for this:

the logs from your listener don't work because robot itself doesn't support logging outside of a test from a listener
the pytest_sessionstart one doesn't get logged because that hook is called at the very beginning of the pytest session before any tests are collected and before robot starts, which means it's impossible for robot to know about it
the session-scoped fixtures are lazily executed (ie. only executed when a test needs them). for example, the following test suite will execute the functions in the following order: test_foo, setup, then test_bar:@fixture(scope="session")
def setup():
    info("1") # runs second

def test_foo():
    info("2") # runs first

def test_bar(setup: None):
    info("3") # runs last

i'm going to make some changes that should make setup_module and teardown_module show up as suite setups in the log, so i would recommend doing it that way

actually, even setup_module and teardown_module only get executed in the setup/teardown stage of an individual test (the first or last one in a suite), so i think think supporting it would be difficult, and it would also cause issues if i add support for xdist in the future (#98), since the contents of the "setup" keyword would appear to be duplicated if a suite is split across multiple runners.
i'll keep this issue open for now but i'm not sure if it's feasible

when I use setup_module, it has been executed before each test case, My hopes is it execute only once before the module.

@fixture(scope="session")
def setup():
logging.info("1")
the fixture did't  execute. when I and autouse=True, It also executed before each test case.

what version of the plugin are you using? i suspect that's the same issue as #161 which was fixed in the latest version (2.5.1)

it's working now, after upgrade to 2.5.1


Lazy docs building.

Since the @conclude macro only starts processing docstrings once the rest of a module is loaded, this allows the docs to be built (using builddocs!) any time between using MyModule and the first call to Lexicon's query methods for module MyModule. This might cut down module load times slightly.

Closed by b9d6b68cc7a17b383c5c1d64167665aa5a1a5a08. Using @document macro the included files are tracked, but no parsing of docstrings is done when a package is loaded. builddocs!(::Module) shall then be used from Lexicon to generate the documentation when it's actually needed.


Format selection inconsistencies

VSCode Version: 1.7.1 (2016-11-03T13:53:14.822Z)
OS Version: Windows 10 - Version 1607

Steps to Reproduce:

Within a javascript file create three lines that have incorrect indentation.

The first should be a code line
The second should be a comment line
The third should be another code line.

Highlight the top two lines and press Ctrl + K, Ctrl + F to format the selection.
Notice that the comment line isn't indented along with the code line
Undo the changes and highlight all three lines. Once again press Ctrl + K, Ctrl + F to format the selection
Notice that the comment line is now indented correctly.
Undo the changes and use Shift + Alt + F to format the document. The comment line is now indented as with (3).

It seems like if the last line of a selection is a comment it doesn't correctly pick up the indentation settings.
An example file is this one.
d3.tsv("/test.tsv", (err, data) => {
    data.forEach(function (element) {
        console.log("test");
        //this is a comment
        console.log("Hello world");
    }, this);
});

This looks like a duplicate of https://github.com/Microsoft/TypeScript/issues/11500
@mhegazy can you confirm?

The commment is indented with the line that follows it. So this sounds right to me.

Hmm.. I agree with OP that the behavior seems strange. I did a quick check to see what other editors do.
Atom (using Beautifier plugin) - Will indent the comment to the line above (in OP's scenario 1)
WebStorm - Will indent the comment to the line above (in OP's scenario 1)
Sublime Text (using JS Format plugin) - Will indent the comment to the line above (in OP's scenario 1)
Do we have a reason to not have the same behavior?

Moving to TS repo to continue discussion.

This issue was moved to Microsoft/TypeScript#12327


feat: SHAP value support for XGBoost's binary classification models

Add SHAP value calculation for XGBoost binary classification taskss.

/intelci: run

/intelci: run

/intelci: run

This hopefully should work,  they try exception-catching style matches other implemenations in the file, but I think a daal_check_version at instantiation implementation of this functionality would be more straightforward and waste fewer cycles with older versions.

/intelci: run

manually run since the bot seems to be down: http://intel-ci.intel.com/ef6c54a3-946a-f152-a360-a4bf010d0e2e


Razor 代码块，使用标记将本地函数声明为用作模板化方法

Description
原文
在代码块中，使用标记将本地函数声明为用作模板化方法：
@{
    void RenderName(string name)
    {

Name: @name

    }

    RenderName("Mahatma Gandhi");
    RenderName("Martin Luther King, Jr.");
}

该代码呈现以下 HTML：

Name: Mahatma Gandhi

Name: Martin Luther King, Jr.

代码效果

Page URL
https://learn.microsoft.com/zh-cn/aspnet/core/mvc/views/razor?view=aspnetcore-8.0
Content source URL
https://github.com/dotnet/AspNetCore.Docs/blob/main/aspnetcore/mvc/views/razor.md
Document ID
a0b3b70a-3b39-1b5f-a4ce-c41bd2d6b044
Article author
@Rick-Anderson

好吧，这是asp.net core的文章...

Hello! Thanks for contacting us. This sounds like a general question about using ASP.NET Core. While we try to look at and respond to all issues, for questions like this we recommend posting to a community support group like Stack Overflow with the asp.net-core tag.

Stack Overflow
ASP.NET Core Slack
ASP.NET Gitter

Potential bugs in the ASP.NET Core framework and product feedback can be reported at dotnet/aspnetcore issues (include full repro steps and cross-link to a repro project in GH when appropriate). For Visual Studio, use the Report a Problem gesture or Suggest a Feature gesture within VS, which open internal issues for the VS team. For Visual Studio Code, you can open an issue at microsoft/vscode issues.


Could NOT find NUMA (missing: NUMA_LIBRARY NUMA_INCLUDE_DIR)

How to resolve this problem?

There are two things you can do: Either install libnuma (this might depend on your environment, something like apt install libnuma-dev or the equivalent for your package manager), or disable the compilation of the hwloc support or the compilation of tests (since that's the only thing we use libnuma for) by setting GINKGO_BUILD_HWLOC or GINKGO_BUILD_TESTS to OFF in your CMake configuration.

Hi @ztdepztdep, were you able to resolve the issues with libnuma? Then I will close this issue soon, otherwise please let us know what other issues you encountered.


Unable load local json files using http get service with new angular-cli 1.4.5 version  ?

with angular cli -1.0.0 there is no issue to load local json files
Yesturday i updated my cli version 1.4.5 , with that it's unabled to load local json files
getting 404 err0r in console
I tried many ways, even i put the json files in to assets, put the folder path into cli assets array
even it's not working for me

Can you setup a minimal repro please? You can read here why this is needed. A good way to make a minimal repro is to create a new app via ng new repro-app and adding the minimum possible code to show the problem. Then you can push this repository to github and link it here.

Thanks for reporting this issue. This issue is now obsolete due to changes in the recent releases. Please update to the most recent Angular CLI version.
If the problem persists after upgrading, please open a new issue, provide a simple repository reproducing the problem, and describe the difference between the expected and current behavior.


chore(deps): Upgrade golang.org/x/net and golang.org/grpc (#30)

Issues addressed:

https://github.com/kserve/rest-proxy/security/dependabot/1
https://github.com/kserve/rest-proxy/security/dependabot/2
https://github.com/kserve/rest-proxy/security/dependabot/3
https://github.com/kserve/rest-proxy/security/dependabot/4
https://github.com/kserve/rest-proxy/security/dependabot/5
https://www.cve.org/CVERecord?id=CVE-2023-37788

Description

How Has This Been Tested?

Merge criteria:

[ ] The commits are squashed in a cohesive manner and have meaningful messages.
[ ] Testing instructions have been added in the PR body (for PRs involving changes that are not immediately obvious).
[ ] The developer has manually tested the changes and verified that the changes work

ci will be fixed by https://github.com/opendatahub-io/rest-proxy/pull/30

/retest


usb_cam: 0.3.4-0 in 'lunar/distribution.yaml' [bloom]

Increasing version of package(s) in repository usb_cam to 0.3.4-0:

upstream repository: https://github.com/bosch-ros-pkg/usb_cam.git
release repository: https://github.com/tork-a/usb_cam-release.git
distro file: lunar/distribution.yaml
bloom version: 0.5.26
previous version for package: null

usb_cam
* Installs launch files
* Merge pull request #37 from tzutalin/develop
  Add a launch file for easy test
* Add a launch file for easy test
* Contributors: Russell Toris, tzu.ta.lin

Same as #14862.
See https://discourse.ros.org/t/releasing-repositories-form-other-people/1797/10


How to check for my application already started?

How to check for my application already started? And don't start more than one copy?

Duplicate of #211


Marine Quality control

Both quality control scritps marine_qc and marine_qc_hires write infos to ID_file.txt. Where do we use this file again?
The file naming convention of metoffice_qc/base data is set in the class Deck property write_qc. For release 7.0 we used the same scritps used in release 6.0. The file naming convention of the release 6.0 metoffice_qc/base differs from that of reelase 7.0. The release file naming convention is set in the class Voyage property write_qc. This class is never called in any scripts. What are the consequenzen for level1e data?

@aanderss: feel free to list your QC issues/questions here.

level1e script uses the class Deck property write_qc's file naming convention. This question should be solved.

level1e script:
if 'location_quality' == 2:
    'report_quality' == 1

see https://github.com/glamod/cdm_reader_mapper/pull/37
if 'report_time_quality' == 4 or 'report_time_quality' == 5:
    'report_quality' = 1

see https://github.com/glamod/cdm_reader_mapper/issues/36


Create a unique logo with some "Svelte" element to it

I made this logo; let me know if you like it.

Like it? I love it! That's awesome ... I'm gonna have to rethink my whole "disbelief in Santa" thing now LOL
Should I just use a crop from those images or do you have an SVG version? Or feel free to create a PR to add it but either way please include any link to any profile or portfolio site I can add as part of crediting you.
And many thanks for doing this!

Glad you like it. Created a PR for the SVGs, and added the favicon. I was thinking of polishing the UI for docs too, but that's in Astro.

Yeah, there were no great SvelteKit docs systems that I could find and the docs are very incomplete right now. I was thinking of maybe one day converting the TailwindUI Protocol ,which looks slick, to Svelte.

Thanks for the PR - I updated the docs and readme to use them.
Looks great, thanks again!


setVolume method does not work on iOS release

:beetle: Description
In my app, I have a call-ringing screen and play a ringing sound when the screen mounts. Problem: I want to set the ringing volume dynamically. For example: when the device volume is at 100% then I want to set the ringing volume to 0.5 and if the device volume is less than 50% then I want to set the system volume as a ringing sound volume.
:beetle: What is the observed behavior?
On release setVolume method does not reflect on the ringing sound.
:beetle: What is the expected behavior?
On release setVolume method should reflect the ringing sound based on the condition.
:beetle: Please post your code:
useEffect(() => {
    clearTimeout(ringingTimer);
    ringingTimer = setTimeout(() => {
      _onEndButtonPress(data.chat_id);
    }, CALL_RINGING_TIMING);

    const mainBundle = isIOS
      ? encodeURIComponent(Sound.MAIN_BUNDLE)
      : Sound.MAIN_BUNDLE;

    Sound.setCategory('Playback');
    const agoraRinging = new Sound(
      'agora_ringing.mp3',
      mainBundle,
      async error => {
        if (error) {
          return;
        }
        await SystemSetting.getVolume()
          .then(volume => {
            agoraRinging.setVolume(volume > 0.5 ? 0.5 : volume);
          })
          .catch(err => {
            console.log('err while getting system volume ===> ', err);
            agoraRinging.setVolume(1);
          });
        agoraRinging.play();
        agoraRinging.setNumberOfLoops(-1);
      },
    );

    return () => {
      clearTimeout(ringingTimer);
      agoraRinging.stop();
    };
  }, []);

:bulb: Does the problem have a test case?
Yes
:bulb: Possible solution

:bulb: Is there a workaround?
No
:bulb: If the bug is confirmed, would you be willing to create a pull request?
No
Is your issue with...

[x] iOS
[ ] Android
[ ] Windows

Are you using...

[x] React Native CLI (e.g. react-native run-android)
[ ] Expo
[ ] Other: (please specify)

Which versions are you using?

React Native Sound: 0.11.2
React Native: 0.74.6
iOS: >= 17.5
Android: N/A
Windows: N/A

Does the problem occur on...

[ ] Simulator
[x] Device

If your problem is happening on a device, which device?

Device: All iOS devices

The issue is fixed with the following code block
useEffect(() => {
    let agoraRinging: Sound;

    const setupSound = async () => {
      try {
        // Set audio category first
        Sound.setCategory('Playback');

        // Get system volume before creating sound
        const currentVolume = await SystemSetting.getVolume();
        const targetVolume = currentVolume > 0.3 ? 0.3 : currentVolume;

        // Create sound instance
        const soundPath = isIOS ? 'agora_ringing.mp3' : 'agora_ringing';

        agoraRinging = new Sound(soundPath, Sound.MAIN_BUNDLE, error => {
          if (error) {
            console.log('Failed to load sound:', error);
            return;
          }

          // Set volume before playing
          agoraRinging.setVolume(targetVolume);
          agoraRinging.setNumberOfLoops(-1);

          // Play sound
          agoraRinging.play(success => {
            if (!success) {
              console.log('Playback failed');
            }
          });
        });
      } catch (err) {
        console.log('Sound setup error:', err);
      }
    };

    // Start ringing timer
    clearTimeout(ringingTimer);
    ringingTimer = setTimeout(() => {
      _onEndButtonPress(data.chat_id);
    }, CALL_RINGING_TIMING);

    // Setup sound
    setupSound();

    // Cleanup
    return () => {
      clearTimeout(ringingTimer);
      if (agoraRinging) {
        agoraRinging.stop();
        agoraRinging.release();
      }
    };
  }, []);


New version LiveServer: 0.1.1

Registering: LiveServer
Repository: https://github.com/asprionj/LiveServer.jl
Version: v0.1.1
Commit: 4687a9b25a3b44cdd30bc3d129caf4d6ce757cd7
Proposed by: @tlienart
Reviewed by: @tlienart
Reference: https://github.com/asprionj/LiveServer.jl/issues/66

Can you add some compatibility constraints? At least for julia, e.g.
[compat]
julia = "1"

Done, thanks!

Consider enabling TagBot to make sure the release is persistent in your repo, see https://discourse.julialang.org/t/ann-tagbot-creates-tags-and-releases-for-your-julia-packages-when-theyre-registered/23084


[name] Fix issues with name.addMultilingualName()

Fixes https://github.com/fonttools/fonttools/issues/931.

Should this use format 1 name table when there is no language code for Windows?

Should this use format 1 name table when there is no language code for Windows?

See the TODO comment in the patch. Actually it depends a bit on the fate of name format 1 versus ltag — I’m having hopes that MS and Apple might reconcile this difference between their respective specs, but obviously I don’t know what the outcome of that discussion will be. The advantage of ltag is that it’s implemented by existing fonts, which isn’t the case for name v1.


Handle utf8

https://github.com/lemunozm/termchat/issues/8
The math is not perfect (you can break it if you try hard enough) but it work mostly.
Maybe you can test this and improve it.

I test it and works fine :)
Thanks!!


Adjust interface to be able to see all or filtered languages beside each other

Usually in translation tools, you have several columns for each language and each user is able to select which languages he want to display, as often one translator does more than one language.
Also if some overall changes should be done, it is not so user friendly when you have to switch the language all the time.
Would be nice to have that feature in the interface.

I concur. I don't think anyone is going to have a 10+ different locale app, so it should be possible to have all key translations in just one page instead of going through all by selecting on the top right dropdown at the interface.
Suggestion:

reduce the input space
let all possible languages have their own input field one after the other
have just one save button for them all

Thanks, I understand the problem. The current UI was my first shot on the complex landscape of localization.  I will definitely consider this for V3.


Message JSON impls

Task summary

Signed and unsigned json impls. Should be pretty straightforward as they are somewhat done within the serialization vectors. This needs to be done for UnsignedMessage and SignedMessage (might as well do together)
probably makes sense to just have json modules for the unsigned and signed modules, kinda like:
pub mod json {
    pub fn serialize<S>(c: &UnsignedMessage, serializer: S) -> Result<S::Ok, S::Error>
    where
        S: Serializer,
    {
        // impl
    }

    pub fn deserialize<'de, D>(deserializer: D) -> Result<UnsignedMessage, D::Error>
    where
        D: Deserializer<'de>,
    {
        //impl
    }
}

and just change how everything is exported instead of just exporting the wildcard as it is. (usage would be to tag with #[serde(with = "unsigned_message::json")]
Examples pulled from (https://documenter.getpostman.com/view/4872192/SWLh5mUd?version=latest) I would verify these as they don't seem consistent
Format for signed message looks like:
{
	"Message":{
		"To":"t1hvuzpfdycc6z6mjgbiyaiojikd6wk2vwy7muuei",
		"From":"t1t5gdjfb6jojpivbl5uek6vf6svlct7dph5q2jwa",
		"Nonce":0,
		"Value":"1000",
		"GasPrice":"1000",
		"GasLimit":"0",
		"Method":0,
		"Params":""
	},
	"Signature":{"Type":"secp256k1","Data":"CGZgFHeA5g38txFq6ojwh63wlFGKhNl/ZUZPgTGfNB1IStobmY4VucPa/KteaxJjhFlfm/DBCjTqzhzFK+tKuwE="}
}

(note that the signature type is an integer in the serialization vectors, not sure if one of the two are outdated)
and for unsigned:
{
	"To": "t1hvuzpfdycc6z6mjgbiyaiojikd6wk2vwy7muuei",
	"From": "t3wsspmzh7rbetvblpe6opqnz2bomubibuygg234xdpnb7eqdokrnhy4yto2cl4x5czezc3mz5xl4gz524vh7a",
	"Nonce": 0,
	"Value": "1000",
	"Method": 0,
	"GasPrice": "1",
	"GasLimit": 1000,
	"Params": []
}

(Again params and gas limit are in different format, so verify these)
Specification reference

Other information and links

According to this doc: https://ipfs.io/ipfs/QmZqAv7Rj6rLv9EC5ho8S1JYYGZBnF3M8dnnsok2GzrSjU, the signature type should be an int as done before.


[Bug] Issue downloading from SonyLIV

FDM Version: <IP_ADDRESS>39
Elephant Version: 1.0.12
The SonyLIV links works fine while I download it using standalone yt-dlp. However, it fails with this addon. Is this an issue with FDM?
FDM:

CMD:

This is an issue of FDM. I've reported it to its developers. Hope they will manage to fix it.


fix: Create typed services

Move to typescript typed services

@sedghi - this is just switching to typescript to make it more consistent.  No functional changes.


Viewer stuck "loading"

I follwed the instructions in the README.md and ran on the Berlin data set.  It seems to have finished without issue and created a number of files including reconstruction.meshed.json.
I ran
$sudo python -m SimpleHTTPServer
from the main OpenSfM folder and then used Mozilla to browse
http://localhost:8000/viewer/reconstruction.html#file=/data/berlin/reconstruction.meshed.json
However, it is stuck at the loading animation.
I am on Ubuntu 14.04.  Any ideas?  Thanks.

you can make sure that the file data/berlin/reconstruction.meshed.json
exists.
If it does, check the javascript console for errors
Also, no need to use sudo here

After updating from cv2 3.10 to 3.2.0 as discussed in my issue #138 seemed to fix things.  I guess it wasn't fully completing the SfM operations.  Now the viewer works.  Thanks.

glad to hear, thanks for reporting @mattbrown11


nc_get_vars incredibly slow in Windows compared to Linux

OS: Windows 10
NetCDF version: 4.9.1
I am trying to read a 3D double variable (2000 x 512 x 512) from a netCDF4 file with the following parameters:
start = {0,0,0}
count[] = {1000, 256, 256};
stride[] = {2, 2, 2};
chunk size: {20, 10, 10}
shuffle: no
deflate : yes
deflate_level : 6
I time the call to nc_get_vars.
On Debian 11, it takes ~25 seconds.
On Windows 10, it takes ~130 seconds.
I would expect Windows to be slightly slower, but >5x slowdown is unexpected.
I see similar slowdowns with 'nc_get_vars_double'
On the contrary, using 'nc_get_var_double' or 'nc_get_var' to read the whole variable is significantly faster (~3 sec on Linux, and ~1 sec on Windows)

Is there a way to optimize the performance of 'nc_get_vars' or 'nc_get_vars_double' so that Windows performance is closer to Linux performance?

Is reading the whole variable using 'nc_get_var' to memory and then slicing it later an option? I have seen that there were some discussions regarding this (https://github.com/Unidata/netcdf-c/issues/908) and that a submission was made to make strided reads faster. But for my variable, reading the whole variable still seems to be significantly faster than strided reads (especially on Windows)

Please find the link to the nc file here.
Here is my code:
#include <stdio.h>
#include <string.h>
#include <netcdf.h>
#include <cstdlib>
#include <iostream>
#include <chrono>

int
main()
{
    int status;
    int ncid;
    int varid;

    int elems_x = 256;
	int elems_y = 256;
	int elems_z = 1000;
    double* outData = (double*)malloc (elems_x*elems_y*elems_z*sizeof(double));

    size_t start[] = {0, 0, 0};
    size_t count[] = {1000, 256, 256};
    ptrdiff_t stride[] = {2, 2, 2};

    // open the NetCDF-4 file
    status = nc_open("repro_nc4file.nc", NC_NOWRITE, &ncid);
    if(status != NC_NOERR) {
         printf("Could not open file.\n");
    }

    // get the varid
    status = nc_inq_varid(ncid, "my_var", &varid);
    printf("status after inq var = %d\n", status);
    printf("varid = %d\n", varid);

    // get the strided subset
	auto timestart = std::chrono::high_resolution_clock::now();
    status = nc_get_vars(ncid, varid, start, count, stride, outData);
	auto timeend = std::chrono::high_resolution_clock::now();
	auto duration = std::chrono::duration_cast<std::chrono::seconds>(timeend - timestart);
	std::cout << "Execution time: " << duration.count() << " seconds" << std::endl;
    printf("status after getting strided subset = %d\n", status);

    // close the file
    status = nc_close(ncid);
    printf("status after close = %d\n", status);

    printf("End of test.\n\n");

    return 0;
}

I would rewrite the code to try to use vara to see if the speed problem goes away.

Hello Ed,
I tried your recommendation. The issue is that for using 'nc_get_vara', I ll have to read twice as many elements now (since for my original case, the stride is 2). So, instead of<PHONE_NUMBER> elements, I have to read<PHONE_NUMBER> elements.
Even with nc_get_vara, I still find that Windows is considerable slower:
Windows time: 102 seconds
Linux time: 19 seconds
The only change I made to the previous code is to replace
status = nc_get_vars(ncid, varid, start, count, stride, outData);
with
status = nc_get_vara(ncid, varid, start, count, (void*) outData);
And
int elems_x = 512;
int elems_y = 512;
int elems_z = 2000;

I am taking a look at this to see if I can determine if the slowdown is in libnetcdf, or if it is something in libhdf5.
@abhibaruah a couple questions, if I may, to ensure I'm on the same page.

When you say Windows, you mean Visual Studio, correct? Or a gcc/variant on Windows
What version of libhdf5 are you linking against?

Since we're using libhdf5 for file access, my fear is that this is an issue in libhdf5; that may limit our ability to address this.  But it's not necessarily the case.  I'll start by reproducing the issue, and go from there :).

Thanks @WardF for taking a look.

Yes, I am using Visual Studio (VS2019v16.11.7)
I am linking against HDF5 v1.10.10

I recall that this issue was raised some time ago. If memory serves, we proposed to convert vars code to use the corresponding HDF5 operations (I assume we are talking netcdf-4 and not netcdf-3). But apparently this proposal never got implemented.

Was the proposed change to use the corresponding HDF5 operations only for Windows?
Because for my use case Linux time is reasonable (~20 sec) vs (>100 sec) for Windows.

I'm making some progress on this; I haven't narrowed it down to a solution, yet, but I'm able to replicate the observed issue using netCDF v4.9.1 and HDF5 1.10.10.  Testing with netCDF main and HDF5 1.14.1, I see performance in line with what's observed in your linux environment.  I'm still trying to determine if the culprit is a change in the netCDF code, or if it's a change in the HDF5 code.

@abhibaruah I'm seeing some mostly consistent results; out of curiosity, can you give it a try with v4.9.2?

Hello @WardF ,
When you say 'consistent' results, you mean consistent with the slow speeds I saw or similar to the speed on Linux?
Currently, we do not have v4.9.2 in our harness, and hence it will be difficult for me to build v4.9.2 with HDF5 v1.10.10 (will have to go through legal and administrative hoops for that).
I can download the Windows binaries from here (https://downloads.unidata.ucar.edu/netcdf/) and give it a try but I am guessing that you must have already tried it.

Let me clarify, thanks :).  I'm seeing results consistent with what you've described, and I'm seeing them in a way I've been able to reproduce them.  I'm not certain what the underlying issue is, but I am seeing much faster speeds using netCDF-C v4.9.2 (still slightly slower than on Linux, but that could be because of the VM I'm using, etc.  But around 45 seconds instead of > 100).
I'm at a loss as to why this is only happening in Linux, and will continue trying to figure that out.  I've tested with HDF5 1.10.10 as well as HDF5 1.14.1; the results are the same when using v4.9.1 (> 100 seconds), and faster when using netCDF v4.9.2 ( < 50 seconds), regardless of which version of HDF5 I'm using.

Just a note to follow up, HDF5 1.14.2 is out, I'm going to try to test this on Windows. I understand there are hoops to jump through, but the issue does appear to be related to the underlying HDF5 library.

@WardF
I tried the repro with netCDF 4.9.2 and HDF5 1.10.11. Unfortunately, I am still seeing the same performance difference between Windows 11 and Debian 11.
Windows 11 : ~130s
Debian 11: ~11s
I am not sure why I am still seeing the slowness on WIndows.
I created an HDF5 script to mimic my repro above (but with an H5 file), and the reading of the dataset is much faster (~30s).

@abhibaruah thank you, that is good to know at least, the HDF5 script does suggest it is something in netCDF, although why it would be Windows specific is puzzling.  I'll pop this back to the top of the stack and see what I can sort out.

Hello @WardF
Hope you are doing well. I tried the repro steps for this issue with netCCDF 4.9.2 + HDF5 <IP_ADDRESS> and I could still see the slowdown.
Windows time - ~123 s
Debian 12 time - ~15 s
Let me know if you find any new information regarding the same.
Thanks,
Abhi

I also tried the netCDF repro steps with older versions of netCDF. Here are the results (in seconds).
        Windows            Linux

4.6.1        284.1              228
4.8.1         17.8              10.51
4.9.1         115.55            12.25
4.9.2        140                23
Looks like the Windows regression was introduced sometime between 4.8.1 and 4.9.1.

Thank you @abhibaruah, that certainly narrows it down. Thank you for bringing this back to the top of the stack, I will see what I can do to dial it in.  If I can come up with a test on Windows to replicate this (I should be able to), I can do a git bisect to narrow it down even further.  To answer a question I see you asked separately (while I was out of the office on PTO last week), I'm hoping to have rc2 for 4.9.3 out by the end of next week, and then moving forward with the full release barring any feedback which would prevent that.  Thanks!


Performance testing of batch writer batch sizes

Test the batch size for streaming from Neo4j while writing admin import CSVs. Needs to balance Python object size and disk writing speed.

The sweet spot appears to be at 100000 (1e5) entries per batch.


Look into Lens

lens.xyz

Can you detail this out more?

@har777 will do when I've done a deeper dive into lens. If you already have thoughts feel free to share them :-)


When I set the page.window_width and page.window_height , it will show default window with default size and pos first!!!

As the title say:

This is the first open init window attr debug info.It will run before my main function.
This will cause a bad experience, how can i avoid this issue?

Hide window on start: https://github.com/flet-dev/examples/blob/0b0c25be1947637751ce85ca0f134a974b9beed5/python/controls/page/window-hidden-on-start.py#L14
Set window size and position and then make it visible.

Hacky!


How does safe-exit compare to pyterminate?

How does safe-exit compare to pyterminate?

Looks like pyterminate has similar goals of safe-exit. however, I noticed pyterminate lacks some feature that safe-exit have.

safe-exit support Windows platform, The Windows platform has different mechanisms to catch process exit events.
safe-exit has functions to help safe kill other processes, let them have the opportunity to run clean-up code.


This project is abandoned?

It wasn't updated since fall 2016

I stopped working on it because I felt like it was better to work on Flarum itself. I may continue it after Flarum reaches stable, but that's unlikely.
You can see more information about why in the Flarum Community discussion

Thank you very much for explaination