SIGSEGV when any S3CRT async request object gets destructed after queuing request

[Climax777]

Describe the bug

Even a minimal example where PutObjectAsync is used, where the original request object gets destructed, now segfaults ever since a94edca.

Internally, it seems mostly that the original request is copied to outlive the request object, except for the storage of the original request. This has never been an issue until a94edca

Now the original request object has to be kept alive, and even the minimal example provided crashes: https://docs.aws.amazon.com/sdk-for-cpp/v1/developer-guide/async-methods.html with enough network latency (in other words, where it doesn't complete before the end of the return).

Regression Issue

• Select this option if this issue appears to be a regression.

Expected Behavior

Given the example code one would expect the request to copy the request object.

Current Behavior

The original request object has to be kept alive, since a pointer to it is stored and accessed asynchronously.

Reproduction Steps

Minimal example as provided breaks, given that the process doesn't succeed/fail before returning and destructing. Also seems that adding a std::cout << std::endl; aggravates it. Not sure if it somehow does some flushing.

Possible Solution

Instead of storing the & of the request, just copy it?

Additional Information/Context

No response

AWS CPP SDK version used

1.11.621

Compiler and Version used

gcc (Ubuntu 14.2.0-19ubuntu2) 14.2.0

Operating System and version

Ubuntu 25.04

[Climax777]

bool putObjectAsync(const Aws::S3Crt::S3CrtClient& client,
                    const Aws::String& bucketName,                                      
                    const Aws::String& key) {

    Aws::S3Crt::Model::PutObjectRequest* originalRequest;  
    {                                           
            Aws::S3Crt::Model::PutObjectRequest request;           
            originalRequest = &request;        
            request.SetBucket(bucketName);                                                      
            request.SetKey(key);                                                                
        
            auto stream = Aws::MakeShared<Aws::StringStream>("");  
            *stream << "Hello from CRT async client!";                                          
            request.SetBody(stream);
        
            auto context = Aws::MakeShared<Aws::Client::AsyncCallerContext>("PutObjectContext");
            context->SetUUID(key);                                                              
        
            client.PutObjectAsync(request, putObjectAsyncFinished, context);
    }
     // this will definitely cause the crash, which shouldn't since the request is supposed to be copied.          
     memset(originalRequest, 0, sizeof(Aws::S3Crt::Model::PutObjectRequest));          
     return true;                                                                        
}                                                                                       

[sbiscigl]

Hey thanks for reaching out, looking at the method signature for PutObject

virtual Model::PutObjectOutcome PutObject(const Model::PutObjectRequest& request) const;

we accept request by const ref which means you do have to keep request alive during the operation. Since it is effectively a borrow from the parent scope. which is alluded to in the docs

The resources directly associated with an asynchronous operation must continue to exist until the operation finishes. For example, the client object used to invoke an asynchronous SDK method must exist until the application receives notification that the operation has finished. Similarly, the application itself cannot terminate until the asynchronous operation completes.

which doesn't directly say the request object must live longer than the the request completion, but it will need to.

you are right that code is incorrect, it will destroy the request and enter undefined behavior, likely a segfault.

let me go ahead and fix that documentation, thanks for pointing that out.

Expected Behavior
Given the example code one would expect the request to copy the request object.

i dont think we'll add a copy API i.e.

virtual Model::PutObjectOutcome PutObject(Model::PutObjectRequest request) const;

at this point in time, but you are right the documentation is wrong and we're sorry about that, let me fix it.

[Climax777]

Thanks, @sbiscigl, that makes sense. We will adjust our implementations to keep the request alive until the handler is called.

[sbiscigl]

developer guide has been updated to reflect this, closing this issue out, give a shout if you have any other questions.

[github-actions]

This issue is now closed. Comments on closed issues are hard for our team to see.
If you need more assistance, please open a new issue that references this one.