starred/s3fs-fuse
1
0
Fork 0
mirror of https://github.com/s3fs-fuse/s3fs-fuse.git synced 2026-04-25 21:35:58 +03:00
Code Issues 305 Projects Releases 5 Packages Wiki Activity

[GH-ISSUE #2220] ThreadSanitizer data race at OPENSSL_sk_dup/free in test_concurrent_directory_updates test #1126

New issue
Closed
opened 2026-03-04 01:51:36 +03:00 by kerem · 2 comments
kerem commented 2026-03-04 01:51:36 +03:00
Owner
Copy link

Originally created by @ggtakec on GitHub (Jul 16, 2023).
Original GitHub issue: https://github.com/s3fs-fuse/s3fs-fuse/issues/2220

Related Issues / PRs

#1997 #2211 #2209

Version of s3fs being used (s3fs --version)

v1.92

Detail

We've fixed the errors detected by the ThreadSanitizer test in #2211, #2209, but it still doesn't seem to be resolved.

But I'm still getting errors like this:

WARNING: ThreadSanitizer: data race (pid=22217)
  Write of size 8 at 0x7b08000337e0 by thread T39 (mutexes: write M0):
    #0 free ??:? (s3fs+0x4b0379) (BuildId: 6d80a8edfc4480614810fd72431a71242e80022b)
    #1 OPENSSL_sk_free ??:? (libcrypto.so.3+0x205cfa) (BuildId: 3273586fcac67f861ec301429787310dc38b9e7e)
    #2 S3fsCurl::HeadRequest(char const*, std::map<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >, header_nocase_cmp, std::allocator<std::pair<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > > > >&) /__w/s3fs-fuse/s3fs-fuse/src/curl.cpp:3302 (s3fs+0x58756e) (BuildId: 6d80a8edfc4480614810fd72431a71242e80022b)
    #3 get_object_attribute(char const*, stat*, std::map<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >, header_nocase_cmp, std::allocator<std::pair<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > > > >*, bool, bool*, bool) /__w/s3fs-fuse/s3fs-fuse/src/s3fs.cpp:596 (s3fs+0x53c472) (BuildId: 6d80a8edfc4480614810fd72431a71242e80022b)
    #4 check_object_access(char const*, int, stat*) /__w/s3fs-fuse/s3fs-fuse/src/s3fs.cpp:777 (s3fs+0x5538b4) (BuildId: 6d80a8edfc4480614810fd72431a71242e80022b)
    #5 s3fs_getattr(char const*, stat*) /__w/s3fs-fuse/s3fs-fuse/src/s3fs.cpp:1032 (s3fs+0x545b8b) (BuildId: 6d80a8edfc4480614810fd72431a71242e80022b)
    #6 fuse_reply_attr ??:? (libfuse.so.2+0x168a7) (BuildId: 4db3553f25db655fdcad5600bb328da5dc18736b)

  Previous read of size 8 at 0x7b08000337e0 by thread T45:
    #0 memcpy ??:? (s3fs+0x4bdbd4) (BuildId: 6d80a8edfc4480614810fd72431a71242e80022b)
    #1 OPENSSL_sk_dup ??:? (libcrypto.so.3+0x207433) (BuildId: 3273586fcac67f861ec301429787310dc38b9e7e)
    #2 S3fsCurl::HeadRequest(char const*, std::map<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >, header_nocase_cmp, std::allocator<std::pair<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > > > >&) /__w/s3fs-fuse/s3fs-fuse/src/curl.cpp:3302 (s3fs+0x58756e) (BuildId: 6d80a8edfc4480614810fd72431a71242e80022b)
    #3 get_object_attribute(char const*, stat*, std::map<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >, header_nocase_cmp, std::allocator<std::pair<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > > > >*, bool, bool*, bool) /__w/s3fs-fuse/s3fs-fuse/src/s3fs.cpp:596 (s3fs+0x53c472) (BuildId: 6d80a8edfc4480614810fd72431a71242e80022b)
    #4 check_object_access(char const*, int, stat*) /__w/s3fs-fuse/s3fs-fuse/src/s3fs.cpp:777 (s3fs+0x5538b4) (BuildId: 6d80a8edfc4480614810fd72431a71242e80022b)
    #5 s3fs_getattr(char const*, stat*) /__w/s3fs-fuse/s3fs-fuse/src/s3fs.cpp:1032 (s3fs+0x545b8b) (BuildId: 6d80a8edfc4480614810fd72431a71242e80022b)
    #6 fuse_reply_attr ??:? (libfuse.so.2+0x168a7) (BuildId: 4db3553f25db655fdcad5600bb328da5dc18736b)

  Mutex M0 (0x000001a63030) created at:
    #0 pthread_mutex_init ??:? (s3fs+0x4b3354) (BuildId: 6d80a8edfc4480614810fd72431a71242e80022b)
    #1 S3fsCurl::InitS3fsCurl() /__w/s3fs-fuse/s3fs-fuse/src/curl.cpp:149 (s3fs+0x572586) (BuildId: 6d80a8edfc4480614810fd72431a71242e80022b)
    #2 main /__w/s3fs-fuse/s3fs-fuse/src/s3fs.cpp:5584 (s3fs+0x53e4b6) (BuildId: 6d80a8edfc4480614810fd72431a71242e80022b)

  Thread T39 (tid=22730, running) created by thread T38 at:
    #0 pthread_create ??:? (s3fs+0x4b198f) (BuildId: 6d80a8edfc4480614810fd72431a71242e80022b)
    #1 <null> <null> (libfuse.so.2+0xc4e0) (BuildId: 4db3553f25db655fdcad5600bb328da5dc18736b)

  Thread T45 (tid=23371, running) created by thread T11 at:
    #0 pthread_create ??:? (s3fs+0x4b198f) (BuildId: 6d80a8edfc4480614810fd72431a71242e80022b)
    #1 <null> <null> (libfuse.so.2+0xc4e0) (BuildId: 4db3553f25db655fdcad5600bb328da5dc18736b)

SUMMARY: ThreadSanitizer: data race ??:? in __interceptor_free

Similar to the above error, Previous read has also detected:

  Previous read of size 8 at 0x7b0800017440 by thread T12:
    #0 memcpy ??:? (s3fs+0x4bdbd4) (BuildId: 5062d1b3a193897fe2065c0185fa8609c6fb2fde)
    #1 OPENSSL_sk_dup ??:? (libcrypto.so.3+0x207433) (BuildId: 3273586fcac67f861ec301429787310dc38b9e7e)
    #2 S3fsCurl::DeleteRequest(char const*) /__w/s3fs-fuse/s3fs-fuse/src/curl.cpp:3001 (s3fs+0x5859d6) (BuildId: 5062d1b3a193897fe2065c0185fa8609c6fb2fde)
    #3 s3fs_unlink(char const*) /__w/s3fs-fuse/s3fs-fuse/src/s3fs.cpp:1320 (s3fs+0x546ae8) (BuildId: 5062d1b3a193897fe2065c0185fa8609c6fb2fde)
    #4 fuse_reply_err ??:? (libfuse.so.2+0x126a8) (BuildId: 4db3553f25db655fdcad5600bb328da5dc18736b)

From this error message there is a conflict in a function of libcrypto.
OpenSSL's multithreading support for this we already implemented in the s3fs_init_crypt_mutex function.

A hint about this error is that it appears to be occurring on data access that should be protected by Mutex M0.
(It is S3fsCurl::callback_locks.ssl_session that initialized in the S3fsCurl::InitS3fsCurl method)

So the above error seems to be related to CURL_LOCK_DATA_SSL_SESSION which is one of CURLSHOPT_SHARE.
However, Already the lock and unlock functions are also registered, so I still don't understand why this error occurs.

Reproduce

This error occurs infrequently in the ThreadSanitizer test in test_concurrent_directory_updates.

Note

@gaul
I will merge #1997 into this issue.
Please allow me to discuss, investigate and report on this matter here.

Originally created by @ggtakec on GitHub (Jul 16, 2023). Original GitHub issue: https://github.com/s3fs-fuse/s3fs-fuse/issues/2220 ### Related Issues / PRs #1997 #2211 #2209 ### Version of s3fs being used (`s3fs --version`) v1.92 ### Detail We've fixed the errors detected by the ThreadSanitizer test in #2211, #2209, but it still doesn't seem to be resolved. But I'm still getting errors like this: ``` WARNING: ThreadSanitizer: data race (pid=22217) Write of size 8 at 0x7b08000337e0 by thread T39 (mutexes: write M0): #0 free ??:? (s3fs+0x4b0379) (BuildId: 6d80a8edfc4480614810fd72431a71242e80022b) #1 OPENSSL_sk_free ??:? (libcrypto.so.3+0x205cfa) (BuildId: 3273586fcac67f861ec301429787310dc38b9e7e) #2 S3fsCurl::HeadRequest(char const*, std::map<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >, header_nocase_cmp, std::allocator<std::pair<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > > > >&) /__w/s3fs-fuse/s3fs-fuse/src/curl.cpp:3302 (s3fs+0x58756e) (BuildId: 6d80a8edfc4480614810fd72431a71242e80022b) #3 get_object_attribute(char const*, stat*, std::map<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >, header_nocase_cmp, std::allocator<std::pair<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > > > >*, bool, bool*, bool) /__w/s3fs-fuse/s3fs-fuse/src/s3fs.cpp:596 (s3fs+0x53c472) (BuildId: 6d80a8edfc4480614810fd72431a71242e80022b) #4 check_object_access(char const*, int, stat*) /__w/s3fs-fuse/s3fs-fuse/src/s3fs.cpp:777 (s3fs+0x5538b4) (BuildId: 6d80a8edfc4480614810fd72431a71242e80022b) #5 s3fs_getattr(char const*, stat*) /__w/s3fs-fuse/s3fs-fuse/src/s3fs.cpp:1032 (s3fs+0x545b8b) (BuildId: 6d80a8edfc4480614810fd72431a71242e80022b) #6 fuse_reply_attr ??:? (libfuse.so.2+0x168a7) (BuildId: 4db3553f25db655fdcad5600bb328da5dc18736b) Previous read of size 8 at 0x7b08000337e0 by thread T45: #0 memcpy ??:? (s3fs+0x4bdbd4) (BuildId: 6d80a8edfc4480614810fd72431a71242e80022b) #1 OPENSSL_sk_dup ??:? (libcrypto.so.3+0x207433) (BuildId: 3273586fcac67f861ec301429787310dc38b9e7e) #2 S3fsCurl::HeadRequest(char const*, std::map<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >, header_nocase_cmp, std::allocator<std::pair<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > > > >&) /__w/s3fs-fuse/s3fs-fuse/src/curl.cpp:3302 (s3fs+0x58756e) (BuildId: 6d80a8edfc4480614810fd72431a71242e80022b) #3 get_object_attribute(char const*, stat*, std::map<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >, header_nocase_cmp, std::allocator<std::pair<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > > > >*, bool, bool*, bool) /__w/s3fs-fuse/s3fs-fuse/src/s3fs.cpp:596 (s3fs+0x53c472) (BuildId: 6d80a8edfc4480614810fd72431a71242e80022b) #4 check_object_access(char const*, int, stat*) /__w/s3fs-fuse/s3fs-fuse/src/s3fs.cpp:777 (s3fs+0x5538b4) (BuildId: 6d80a8edfc4480614810fd72431a71242e80022b) #5 s3fs_getattr(char const*, stat*) /__w/s3fs-fuse/s3fs-fuse/src/s3fs.cpp:1032 (s3fs+0x545b8b) (BuildId: 6d80a8edfc4480614810fd72431a71242e80022b) #6 fuse_reply_attr ??:? (libfuse.so.2+0x168a7) (BuildId: 4db3553f25db655fdcad5600bb328da5dc18736b) Mutex M0 (0x000001a63030) created at: #0 pthread_mutex_init ??:? (s3fs+0x4b3354) (BuildId: 6d80a8edfc4480614810fd72431a71242e80022b) #1 S3fsCurl::InitS3fsCurl() /__w/s3fs-fuse/s3fs-fuse/src/curl.cpp:149 (s3fs+0x572586) (BuildId: 6d80a8edfc4480614810fd72431a71242e80022b) #2 main /__w/s3fs-fuse/s3fs-fuse/src/s3fs.cpp:5584 (s3fs+0x53e4b6) (BuildId: 6d80a8edfc4480614810fd72431a71242e80022b) Thread T39 (tid=22730, running) created by thread T38 at: #0 pthread_create ??:? (s3fs+0x4b198f) (BuildId: 6d80a8edfc4480614810fd72431a71242e80022b) #1 <null> <null> (libfuse.so.2+0xc4e0) (BuildId: 4db3553f25db655fdcad5600bb328da5dc18736b) Thread T45 (tid=23371, running) created by thread T11 at: #0 pthread_create ??:? (s3fs+0x4b198f) (BuildId: 6d80a8edfc4480614810fd72431a71242e80022b) #1 <null> <null> (libfuse.so.2+0xc4e0) (BuildId: 4db3553f25db655fdcad5600bb328da5dc18736b) SUMMARY: ThreadSanitizer: data race ??:? in __interceptor_free ``` Similar to the above error, `Previous read` has also detected: ``` Previous read of size 8 at 0x7b0800017440 by thread T12: #0 memcpy ??:? (s3fs+0x4bdbd4) (BuildId: 5062d1b3a193897fe2065c0185fa8609c6fb2fde) #1 OPENSSL_sk_dup ??:? (libcrypto.so.3+0x207433) (BuildId: 3273586fcac67f861ec301429787310dc38b9e7e) #2 S3fsCurl::DeleteRequest(char const*) /__w/s3fs-fuse/s3fs-fuse/src/curl.cpp:3001 (s3fs+0x5859d6) (BuildId: 5062d1b3a193897fe2065c0185fa8609c6fb2fde) #3 s3fs_unlink(char const*) /__w/s3fs-fuse/s3fs-fuse/src/s3fs.cpp:1320 (s3fs+0x546ae8) (BuildId: 5062d1b3a193897fe2065c0185fa8609c6fb2fde) #4 fuse_reply_err ??:? (libfuse.so.2+0x126a8) (BuildId: 4db3553f25db655fdcad5600bb328da5dc18736b) ``` From this error message there is a conflict in a function of libcrypto. OpenSSL's multithreading support for this we already implemented in the `s3fs_init_crypt_mutex` function. A hint about this error is that it appears to be occurring on data access that should be protected by `Mutex M0`. (It is `S3fsCurl::callback_locks.ssl_session` that initialized in the `S3fsCurl::InitS3fsCurl` method) So the above error seems to be related to `CURL_LOCK_DATA_SSL_SESSION` which is one of `CURLSHOPT_SHARE`. However, Already the lock and unlock functions are also registered, so I still don't understand why this error occurs. #### Reproduce This error occurs infrequently in the ThreadSanitizer test in test_concurrent_directory_updates. #### Note @gaul I will merge #1997 into this issue. Please allow me to discuss, investigate and report on this matter here.
kerem 2026-03-04 01:51:36 +03:00
  • closed this issue
  • added the
    testing
         label
kerem commented 2026-03-04 01:51:37 +03:00
Author
Owner
Copy link

@ggtakec commented on GitHub (May 27, 2024):

This my bug research is still in progress, but I would like to share the results.

We added support for fedora:40 in PR #2451, but the Sanitize Thread check now always(almost) fails.

The failure is mainly by the following Data Race:

WARNING: ThreadSanitizer: data race (pid=4583)
  Write of size 8 at 0x72080002b800 by thread T10:
    #0 free ??:? (s3fs+0x462b33) (BuildId: 2db34d3bfdcda9123c6b6d4cc06892bd4ef4b252)
    #1 OPENSSL_sk_free ??:? (libcrypto.so.3+0x1c3caa) (BuildId: 36d9244c0d9ad35ed1005bed7e0690677c1b32d0)
    #2 S3fsCurl::HeadRequest(char const*, std::map<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >, header_nocase_cmp, std::allocator<std::pair<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > > > >&) /__w/s3fs-fuse/s3fs-fuse/src/curl.cpp:3387 (s3fs+0x53c18e) (BuildId: 2db34d3bfdcda9123c6b6d4cc06892bd4ef4b252)
    ...

  Previous read of size 8 at 0x72080002b800 by thread T73:
    #0 memcpy ??:? (s3fs+0x45f95f) (BuildId: 2db34d3bfdcda9123c6b6d4cc06892bd4ef4b252)
    #1 OPENSSL_sk_dup ??:? (libcrypto.so.3+0x1c3d83) (BuildId: 36d9244c0d9ad35ed1005bed7e0690677c1b32d0)
    #2 S3fsCurl::HeadRequest(char const*, std::map<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >, header_nocase_cmp, std::allocator<std::pair<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > > > >&) /__w/s3fs-fuse/s3fs-fuse/src/curl.cpp:3387 (s3fs+0x53c18e) (BuildId: 2db34d3bfdcda9123c6b6d4cc06892bd4ef4b252)
    ...

The above is a call from S3fsCurl::HeadRequest, which reports that OPENSSL_sk_dup has accessed the freed area.
(S3fsCurl::HeadRequest is one example, and we have also confirmed cases such as S3fsCurl::GetObjectRequest.)

There seemed to be two possibilities for this:
(1) s3fs_sha256 called from S3fsCurl::insertV4Headers
(2) CURLSHOPT_SHARE

When the error occurs, it occurs after calling curl_easy_perform in one of the threads.
Therefore, (1) is not considered to be the cause.

s3fs specifies CURL_LOCK_DATA_SSL_SESSION in curl option CURLSHOPT_SHARE as default.
This error seems likely to be accessing data from an SSL session that has been updated or destroyed.
I tried starting s3fs with the nosscache (and nodnscache) options and the error no longer occurs.
(NOTE: However, the number of tests may not be sufficient yet)

I believe that the LOCK function related to CURLSHOPT_SHARE is set correctly, but it seems that exclusive control of the internally shared data of the SSL session is not possible.

  • Supplementary information
    The Sanitize Thread check (fedra:40) uses OpenSSL 3.2.1 30 Jan 2024 (Library: OpenSSL 3.2.1 30 Jan 2024).
<!-- gh-comment-id:2133669018 --> @ggtakec commented on GitHub (May 27, 2024): This my bug research is still in progress, but I would like to share the results. We added support for `fedora:40` in PR #2451, but the `Sanitize Thread` check now always(almost) fails. The failure is mainly by the following `Data Race`: ``` WARNING: ThreadSanitizer: data race (pid=4583) Write of size 8 at 0x72080002b800 by thread T10: #0 free ??:? (s3fs+0x462b33) (BuildId: 2db34d3bfdcda9123c6b6d4cc06892bd4ef4b252) #1 OPENSSL_sk_free ??:? (libcrypto.so.3+0x1c3caa) (BuildId: 36d9244c0d9ad35ed1005bed7e0690677c1b32d0) #2 S3fsCurl::HeadRequest(char const*, std::map<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >, header_nocase_cmp, std::allocator<std::pair<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > > > >&) /__w/s3fs-fuse/s3fs-fuse/src/curl.cpp:3387 (s3fs+0x53c18e) (BuildId: 2db34d3bfdcda9123c6b6d4cc06892bd4ef4b252) ... Previous read of size 8 at 0x72080002b800 by thread T73: #0 memcpy ??:? (s3fs+0x45f95f) (BuildId: 2db34d3bfdcda9123c6b6d4cc06892bd4ef4b252) #1 OPENSSL_sk_dup ??:? (libcrypto.so.3+0x1c3d83) (BuildId: 36d9244c0d9ad35ed1005bed7e0690677c1b32d0) #2 S3fsCurl::HeadRequest(char const*, std::map<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >, header_nocase_cmp, std::allocator<std::pair<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > > > >&) /__w/s3fs-fuse/s3fs-fuse/src/curl.cpp:3387 (s3fs+0x53c18e) (BuildId: 2db34d3bfdcda9123c6b6d4cc06892bd4ef4b252) ... ``` The above is a call from `S3fsCurl::HeadRequest`, which reports that `OPENSSL_sk_dup` has accessed the freed area. _(`S3fsCurl::HeadRequest` is one example, and we have also confirmed cases such as `S3fsCurl::GetObjectRequest`.)_ There seemed to be two possibilities for this: (1) `s3fs_sha256` called from `S3fsCurl::insertV4Headers` (2) `CURLSHOPT_SHARE` When the error occurs, it occurs after calling `curl_easy_perform` in one of the threads. Therefore, (1) is not considered to be the cause. s3fs specifies `CURL_LOCK_DATA_SSL_SESSION` in curl option `CURLSHOPT_SHARE` as default. This error seems likely to be accessing data from an SSL session that has been updated or destroyed. I tried starting s3fs with the `nosscache` (and `nodnscache`) options and the error no longer occurs. _(NOTE: However, the number of tests may not be sufficient yet)_ I believe that the LOCK function related to `CURLSHOPT_SHARE` is set correctly, but it seems that exclusive control of the internally shared data of the SSL session is not possible. - Supplementary information The Sanitize Thread check (fedra:40) uses `OpenSSL 3.2.1 30 Jan 2024 (Library: OpenSSL 3.2.1 30 Jan 2024)`.
kerem commented 2026-03-04 01:51:37 +03:00
Author
Owner
Copy link

@ggtakec commented on GitHub (Nov 30, 2024):

This issue was resolved by PR #2608 (final refactoring of #2600).

<!-- gh-comment-id:2508883684 --> @ggtakec commented on GitHub (Nov 30, 2024): This issue was resolved by PR #2608 (final refactoring of #2600).
Sign in to join this conversation.
No Branch/Tag specified
Branches Tags
master
v1.97
v1.96
v1.95
v1.94
v1.93
v1.92
v1.91
v1.90
v1.89
v1.88
v1.87
v1.86
v1.85
v1.84
v1.83
v1.82
v1.81
v1.80
v1.79
v1.78
Pre-v1.78
v1.77
v1.76
v1.75
v1.74
Labels
Clear labels   
bug

   
bug

   
dataloss

   
duplicate

   
enhancement

   
feature request

   
help wanted

   
invalid

   
need info

   
performance

   
pull-request

Mirrored from GitHub Pull Request

  
question

   
question

   
testing
No labels
bug
bug
dataloss
duplicate
enhancement
feature request
help wanted
invalid
need info
performance
pull-request
question
question
testing
Milestone
Clear milestone
No items
No milestone
Projects
Clear projects
No items
No project
Assignees
Clear assignees
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
starred/s3fs-fuse#1126
No description provided.