-
Notifications
You must be signed in to change notification settings - Fork 1.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Shutdown API Segfault and Valgrind Issues: Aws::Utils::Crypto::CleanupCrypto() + CleanupHttp() #1550
Comments
hi @afowles , |
Any updates? We are hitting the same issue after aws-sdk update. The issue seems to have appeared between 1.7.311 and 1.8.159 releases |
Hello, I am using 1.7.108 and am getting the same issue. Here is what I am seeing in valgrind.
And later on:
Still later:
|
Hello! We're facing the same problem on CentOS 7. Any update? |
Same issue in 1.9.220 with CentOS7-- gcc 7.3.1 -- believe issue is do to static shared_ptr in HttpClientFactory potentially being cleaned up before other statiic cleanup that can call ShutdownAPI. Probably should avoid statically initialized shared_ptr to avoid these kinds of errors. |
Hello all in this issue, Please note that this use is discouraged and not recommended. The reason you observe memory issues by following this design idea
is that the order of static object destruction is not determined by the C++ standard, and the SDK and it's dependencies are also using static global objects. After your We know that the usage of static global variables including std:: smart pointers and data classes is considered a bad design and we are considering different ways of improving on this aspect. Best regards, |
@SergeyRyabinin - Can you add to the documentation for ShutdownAPI that calls to it from within the destructor of a static is specifically unsupported (maybe that's already there?) |
It is encouraging that you are moving in that direction and I hope you can get there. I work on Apache Arrow which uses S3. We have our own static state challenges 😰 and have been moving singletons from static global variables to static local variables that are initialized the first time they are accessed as this gives us a predictable creation (and thus destruction) order. If this is fixed then we don't have to require users to call |
Same problem here trying to call the Any updates on this? Does someone know any workaround? |
Summary: Add finalizeS3FileSystem to explicitly teardown the AWS SDK C++. Velox users need to manually invoke this before exiting an application. This is because Velox uses a static object to hold the S3 FileSystem instance. AWS C++ SDK library also uses static global objects in its code. The order of static object destruction is not defined by the C++ standard. This could lead to a segmentation fault during the program exit. Reference: aws/aws-sdk-cpp#1550 (comment) Remove intializeClient() as this can be done during S3FileSystem construction. Clarify AWS SDK log level is set during the S3 initialization. Fix test. Refactor S3FileSystem tests to separate filesystem tests and registration tests. Pull Request resolved: #6398 Reviewed By: kgpai Differential Revision: D49114381 Pulled By: pedroerp fbshipit-source-id: e124d5d5e74ac60f73df729c2deff2392eef6efe
The basic usage of the sdk should look like this, with all of the sdk calls between #include <aws/core/Aws.h>
int main(int argc, char** argv)
{
Aws::SDKOptions options;
Aws::InitAPI(options);
{
// make your SDK calls here.
}
Aws::ShutdownAPI(options);
return 0;
} Please let us know if you run into anymore problems with this sdk. |
|
Summary: Add finalizeS3FileSystem to explicitly teardown the AWS SDK C++. Velox users need to manually invoke this before exiting an application. This is because Velox uses a static object to hold the S3 FileSystem instance. AWS C++ SDK library also uses static global objects in its code. The order of static object destruction is not defined by the C++ standard. This could lead to a segmentation fault during the program exit. Reference: aws/aws-sdk-cpp#1550 (comment) Remove intializeClient() as this can be done during S3FileSystem construction. Clarify AWS SDK log level is set during the S3 initialization. Fix test. Refactor S3FileSystem tests to separate filesystem tests and registration tests. Pull Request resolved: facebookincubator#6398 Reviewed By: kgpai Differential Revision: D49114381 Pulled By: pedroerp fbshipit-source-id: e124d5d5e74ac60f73df729c2deff2392eef6efe
Summary: Add finalizeS3FileSystem to explicitly teardown the AWS SDK C++. Velox users need to manually invoke this before exiting an application. This is because Velox uses a static object to hold the S3 FileSystem instance. AWS C++ SDK library also uses static global objects in its code. The order of static object destruction is not defined by the C++ standard. This could lead to a segmentation fault during the program exit. Reference: aws/aws-sdk-cpp#1550 (comment) Remove intializeClient() as this can be done during S3FileSystem construction. Clarify AWS SDK log level is set during the S3 initialization. Fix test. Refactor S3FileSystem tests to separate filesystem tests and registration tests. Pull Request resolved: facebookincubator#6398 Reviewed By: kgpai Differential Revision: D49114381 Pulled By: pedroerp fbshipit-source-id: e124d5d5e74ac60f73df729c2deff2392eef6efe
Summary: Add finalizeS3FileSystem to explicitly teardown the AWS SDK C++. Velox users need to manually invoke this before exiting an application. This is because Velox uses a static object to hold the S3 FileSystem instance. AWS C++ SDK library also uses static global objects in its code. The order of static object destruction is not defined by the C++ standard. This could lead to a segmentation fault during the program exit. Reference: aws/aws-sdk-cpp#1550 (comment) Remove intializeClient() as this can be done during S3FileSystem construction. Clarify AWS SDK log level is set during the S3 initialization. Fix test. Refactor S3FileSystem tests to separate filesystem tests and registration tests. Pull Request resolved: facebookincubator#6398 Reviewed By: kgpai Differential Revision: D49114381 Pulled By: pedroerp fbshipit-source-id: e124d5d5e74ac60f73df729c2deff2392eef6efe
Summary: Add finalizeS3FileSystem to explicitly teardown the AWS SDK C++. Velox users need to manually invoke this before exiting an application. This is because Velox uses a static object to hold the S3 FileSystem instance. AWS C++ SDK library also uses static global objects in its code. The order of static object destruction is not defined by the C++ standard. This could lead to a segmentation fault during the program exit. Reference: aws/aws-sdk-cpp#1550 (comment) Remove intializeClient() as this can be done during S3FileSystem construction. Clarify AWS SDK log level is set during the S3 initialization. Fix test. Refactor S3FileSystem tests to separate filesystem tests and registration tests. Pull Request resolved: facebookincubator#6398 Reviewed By: kgpai Differential Revision: D49114381 Pulled By: pedroerp fbshipit-source-id: e124d5d5e74ac60f73df729c2deff2392eef6efe
Describe the bug
SDK Shutdown segfaults and has valgrind memory issues, apparently around CleanupHttp / CleanupCrypto. This issue only seems to happen if a static pointer to a class which inits and cleans up the SDK is used. Curious why this would be the case.
SDK version number
1.8.113
Platform/OS/Hardware/Device
Fedora 33, (GCC) 10.2.1 20201125
To Reproduce (observed behavior)
Expected behavior
Runs, clean valgrind output. With SDK version 1.7.323, (GCC) 10.1.1 20200507 Fedora 32
Logs/output
On Fedora 33 with versions described above
First invalid read:
Additional context
With Logging on simply running the program
Any insights would be appreciated
The text was updated successfully, but these errors were encountered: