Seg fault in call to InitAPI

[csimmons0]

As soon as my code calls InitAPI, it hits a seg fault. This is my code, which just tries to call InitAPI and ShutdownAPI with default options:

    std::shared_ptr<LoginExecutive>
    LoginExecutive::create(
        const LoginExecutiveContext & context
        )
    {
        Aws::SDKOptions options;
        Aws::InitAPI(options);
        Aws::ShutdownAPI(options);
        return std::make_shared<LoginExecutiveImpl>(context);
    }

This is the stack trace of the crash:

(lldb) bt
* thread #1: tid = 378, 0xf76c0d33 libc.so`pthread_mutex_lock + 35, name = 'doclily.doclily', stop reason = signal SIGSEGV: invalid address (fault address: 0x4)
    frame #0: 0xf76c0d33 libc.so`pthread_mutex_lock + 35
    frame #1: 0xe1a5cbb1 libc++_shared.so`std::__ndk1::mutex::lock() + 33
    frame #2: 0xe1624af8 libaws-cpp-sdk-core.so`Aws::Utils::Crypto::OpenSSL::locking_fn(int, int, char const*, int) + 88
    frame #3: 0xe17af9ba libaws-cpp-sdk-core.so`CRYPTO_lock + 266
    frame #4: 0xe1805735 libaws-cpp-sdk-core.so`___lldb_unnamed_symbol1057$$libaws-cpp-sdk-core.so + 101
    frame #5: 0xe1805944 libaws-cpp-sdk-core.so`___lldb_unnamed_symbol1059$$libaws-cpp-sdk-core.so + 68
    frame #6: 0xe1804db8 libaws-cpp-sdk-core.so`ERR_func_error_string + 120
    frame #7: 0xe17b4bd6 libaws-cpp-sdk-core.so`ERR_load_CRYPTO_strings + 38
    frame #8: 0xe16248fd libaws-cpp-sdk-core.so`Aws::Utils::Crypto::OpenSSL::init_static_state() + 29
    frame #9: 0xe16747b2 libaws-cpp-sdk-core.so`void std::__ndk1::__invoke_void_return_wrapper<void>::__call<void (*&)()>(void (*&&&)()) + 50
    frame #10: 0xe1674695 libaws-cpp-sdk-core.so`std::__ndk1::__function::__func<void (*)(), std::__ndk1::allocator<void (*)()>, void ()>::operator()() + 53
    frame #11: 0xe1611b19 libaws-cpp-sdk-core.so`std::__ndk1::function<void ()>::operator()() const + 41
    frame #12: 0xe1689876 libaws-cpp-sdk-core.so`Aws::Utils::GetTheLights::EnterRoom(std::__ndk1::function<void ()>&&) + 294
    frame #13: 0xe1672e2b libaws-cpp-sdk-core.so`DefaultMD5Factory::InitStaticState() + 107
    frame #14: 0xe166ecd1 libaws-cpp-sdk-core.so`Aws::Utils::Crypto::InitCrypto() + 705
    frame #15: 0xe15a765f libaws-cpp-sdk-core.so`Aws::InitAPI(Aws::SDKOptions const&) + 1231
  * frame #16: 0xe3f9013e libnative-lib.so`helloworld::LoginExecutive::create(context=0xfff92ec8) + 110 at LoginExecutiveImpl.cpp:18
    frame #17: 0xe3f8a618 libnative-lib.so`::Java_com_doclily_doclily_LoginExecutive_create(jniEnv=0xf434e2b0, (null)=0xfff92f0c, j_context=0xfff92f10) + 104 at NativeLoginExecutive.cpp:28
    frame #18: 0xe30633e7

[JonathanHenson]

Does your code initialize OpenSSL or libcurl anywhere else?

Sent from my iPhone

On Nov 18, 2016, at 2:28 AM, Chris Simmons notifications@github.com wrote:

As soon as my code calls InitAPI, it hits a seg fault. This is my code, which just tries to call InitAPI and ShutdownAPI with default options:

std::shared_ptr<LoginExecutive>
LoginExecutive::create(
    const LoginExecutiveContext & context
    )
{
    Aws::SDKOptions options;
    Aws::InitAPI(options);
    Aws::ShutdownAPI(options);
    return std::make_shared<LoginExecutiveImpl>(context);
}

This is the stack trace of the crash:

(lldb) bt

• thread CodeDeploy generated client capitilization inconsistency breaks builds for case-sensitive operating systems. #1: tid = 378, 0xf76c0d33 libc.sopthread_mutex_lock + 35, name = 'doclily.doclily', stop reason = signal SIGSEGV: invalid address (fault address: 0x4) frame #0: 0xf76c0d33 libc.sopthread_mutex_lock + 35
  frame CodeDeploy generated client capitilization inconsistency breaks builds for case-sensitive operating systems. #1: 0xe1a5cbb1 libc++shared.sostd::__ndk1::mutex::lock() + 33 frame #2: 0xe1624af8 libaws-cpp-sdk-core.soAws::Utils::Crypto::OpenSSL::locking_fn(int, int, char const, int) + 88
  frame CodeDeployClient.h: No such file or directory while bulilding on Ubuntu 14.10 #3: 0xe17af9ba libaws-cpp-sdk-core.soCRYPTO_lock + 266 frame #4: 0xe1805735 libaws-cpp-sdk-core.so__lldb_unnamed_symbol1057$$libaws-cpp-sdk-core.so + 101
  frame [Question] Default Executor #5: 0xe1805944 libaws-cpp-sdk-core.so___lldb_unnamed_symbol1059$$libaws-cpp-sdk-core.so + 68 frame #6: 0xe1804db8 libaws-cpp-sdk-core.soERR_func_error_string + 120
  frame Error compiling: fatal error: curl/curl.h: No such file or directory #7: 0xe17b4bd6 libaws-cpp-sdk-core.soERR_load_CRYPTO_strings + 38 frame #8: 0xe16248fd libaws-cpp-sdk-core.soAws::Utils::Crypto::OpenSSL::init_static_state() + 29
  frame Iterator-based APIs #9: 0xe16747b2 libaws-cpp-sdk-core.sovoid std::__ndk1::__invoke_void_return_wrapper<void>::__call<void (_&)()>(void (_&&&)()) + 50 frame #10: 0xe1674695 libaws-cpp-sdk-core.sostd::__ndk1::__function::__func<void ()(), std::__ndk1::allocator<void (*)()>, void ()>::operator()() + 53
  frame Fixed build errors and failed unit tests with MSVC 2015 #11: 0xe1611b19 libaws-cpp-sdk-core.sostd::__ndk1::function<void ()>::operator()() const + 41 frame #12: 0xe1689876 libaws-cpp-sdk-core.soAws::Utils::GetTheLights::EnterRoom(std::__ndk1::function<void ()>&&) + 294
  frame Amazon is wrong namespace name, Replaced to Aws #13: 0xe1672e2b libaws-cpp-sdk-core.soDefaultMD5Factory::InitStaticState() + 107 frame #14: 0xe166ecd1 libaws-cpp-sdk-core.soAws::Utils::Crypto::InitCrypto() + 705
  frame How to build the SDK with debugging symbols ? #15: 0xe15a765f libaws-cpp-sdk-core.so`Aws::InitAPI(Aws::SDKOptions const&) + 1231
  • frame Random Segmentation Fault in the SDK on first S3 request #16: 0xe3f9013e libnative-lib.sohelloworld::LoginExecutive::create(context=0xfff92ec8) + 110 at LoginExecutiveImpl.cpp:18 frame #17: 0xe3f8a618 libnative-lib.so::Java_com_doclily_doclily_LoginExecutive_create(jniEnv=0xf434e2b0, (null)=0xfff92f0c, j_context=0xfff92f10) + 104 at NativeLoginExecutive.cpp:28
    frame erase useless line #18: 0xe30633e7
    —
    You are receiving this because you are subscribed to this thread.
    Reply to this email directly, view it on GitHub, or mute the thread.

[csimmons0]

Not to my knowledge. Should it?

[csimmons0]

Actually, I now see that my code is getting called twice, which means that those libraries are getting initialized elsewhere, in the first call to InitAPI, which does succeed. I didn't expect my code to get called twice; there may be a bug on my end.

[bretambrose]

Would you mind sharing your build, execution, and debug (for the android app itself) setup? Android debugging is something I've struggled with (pretty much log-only so far) and the fact that you're sitting in LLDB has me very jealous.

[JonathanHenson]

No, if you are, you have to tell the SDK not to via the SDKOptions.

Sent from my iPhone

On Nov 18, 2016, at 9:04 AM, Chris Simmons notifications@github.com wrote:

Actually, I now see that my code is getting called twice, which means that those libraries are getting initialized elsewhere, in the first call to InitAPI, which does succeed. I didn't expect my code to get called twice; there may be a bug on my end.

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub, or mute the thread.

[csimmons0]

I now see that the documentation for ShutdownAPI states, "Do not call any other SDK methods after calling ShutdownAPI." I'm calling InitAPI after a call to ShutdownAPI; I think this is my bug.

@bretambrose I'm not sure exactly what information you're looking for regarding my development setup, but here's some info: My OS is OS X El Capitan. Android Studio 2.2.2 and the default tools it uses (Gradle, LLDB) handle most things related to build, execution, and debug. I'm running the app on a Genymotion 2.8.0 emulator.

[JonathanHenson]

It's complicated. As long as you can guarantee that all memory and modules are deleted before calling shutdownAPI, it should be fine. The other day, I actually accidentally had a segfault in my own code due to this.

In general non-trivial statics and long lived memory on the heap is your enemy, and will cause results like this.

Sent from my iPhone

On Nov 18, 2016, at 9:39 AM, Chris Simmons notifications@github.com wrote:

I now see that the documentation for ShutdownAPI states, "Do not call any other SDK methods after calling ShutdownAPI." I'm calling InitAPI after a call to ShutdownAPI; I think this is my bug.

@bretambrose I'm not sure exactly what information you're looking for regarding my development setup, but here's some info: My OS is OS X El Capitan. Android Studio 2.2.2 and the default tools it uses (Gradle, LLDB) handle most things related to build, execution, and debug. I'm running the app on a Genymotion 2.8.0 emulator.

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub, or mute the thread.

[pchen66]

I have a similar situation but only happen in a specific context. I'm trying to hook up S3 uploading feature in Unreal Engine 4 but segmentation fault always comes to me when executing Aws::InitAPI call. What confuses me is that the exact same code works on Unreal Engine 4 for Mac and Linux (using aws-doc-sdk-examples) except for Unreal Engine 4 for Linux. Also, when I compiled for -DNO_ENCRYPTION=ON, the unit test for sdk fails at AWSAuthV4SignerTest. Is there something you can point me that I should look into? Thanks in advance. @JonathanHenson

My configurations:

• Ubuntu 16.04 LTS
• libssl-dev: 1.0.2g-1ubuntu4.5
• Unreal Engine 4.14

gdb output with backtrace

Thread 1 "UE4Editor" received signal SIGSEGV, Segmentation fault.
0x00000000029ccea0 in ?? ()
(gdb) 
(gdb) bt
#0  0x00000000029ccea0 in ?? ()
#1  0x00007fff8468e39d in std::function<std::shared_ptr<Aws::Utils::Crypto::SymmetricCipherFactory> ()>::operator()() const ()
   from /usr/local/lib/libaws-cpp-sdk-core.so
#2  0x00007fff8468de04 in Aws::InitAPI(Aws::SDKOptions const&) ()
   from /usr/local/lib/libaws-cpp-sdk-core.so
#3  0x00007fff849c6edd in UAWSClient::UploadFileToS3 (FileName=..., 
    FileAbsolutePath=...)
    at /home/ray/YSProjects/TestBed/Source/TestBed/Private/AWSClient.cpp:25
#4  0x00007fff849ca169 in UAWSClient::execUploadFileToS3 (
    this=<optimized out>, Stack=..., Z_Param__Result=<optimized out>)
    at ../../../YSProjects/TestBed/Source/TestBed/Public/AWSClient.h:19
#5  0x00007ffff66ecf22 in UFunction::Invoke (this=<optimized out>, 
    Obj=<optimized out>, Stack=..., Z_Param__Result=<optimized out>)
    at /home/ray/UnrealEngine/Engine/Source/Runtime/CoreUObject/Private/UObject/Class.cpp:4474
#6  0x00007ffff6842237 in UObject::CallFunction (this=0x7fff89218fc0, 
    Stack=..., Z_Param__Result=0x7fffffffa830, Function=<optimized out>)
    at /home/ray/UnrealEngine/Engine/Source/Runtime/CoreUObject/Private/UObject/ScriptCore.cpp:700
#7  0x00007ffff684b3f5 in FFrame::Step (this=0x7fffffffa950, 
    Z_Param__Result=0x7fffffffa830, Context=<optimized out>)
    at /home/ray/UnrealEngine/Engine/Source/Runtime/CoreUObject/Private/UObject/---Typ------Type <return> to continu-----Type <r---Type <return> to continue, or q <return> to quit---

[JonathanHenson]

NO_ENCRYPTION means you are supplying your own crypto code via the factories in Aws::CryptoOptions and we will not attempt to compile the platform defaults (this is largely for playstation and xbox or other embedded platforms where they may want to do hardware level crypto). If libcrypto, commoncrypto or msft cng, are on the platform you are building against, leave that option on unless you have a very special use case. If you do turn it off, you are responsible for providing your own implementation via the CryptoOptions.

…

Sent from my iPhone

On Jan 29, 2017, at 11:03 AM, Ray Chen ***@***.***> wrote: I have a similar situation but only happen in a specific context. I'm trying to hook up S3 uploading feature in Unreal Engine 4 but segmentation fault always comes to me when executing Aws::InitAPI call. What confuses me is that the exact same code works on Unreal Engine 4 for Mac and Linux (using aws-doc-sdk-examples) except for Unreal Engine 4 for Linux. Also, when I compiled for -DNO_ENCRYPTION=ON, the unit test for sdk fails at AWSAuthV4SignerTest. Is there something you can point me that I should look into? Thanks in advance. @JonathanHenson My configurations: Ubuntu 16.04 LTS libssl-dev: 1.0.2g-1ubuntu4.5 Unreal Engine 4.14 gdb output with backtrace Thread 1 "UE4Editor" received signal SIGSEGV, Segmentation fault. 0x00000000029ccea0 in ?? () (gdb) (gdb) bt #0 0x00000000029ccea0 in ?? () #1 0x00007fff8468e39d in std::function<std::shared_ptr<Aws::Utils::Crypto::SymmetricCipherFactory> ()>::operator()() const () from /usr/local/lib/libaws-cpp-sdk-core.so #2 0x00007fff8468de04 in Aws::InitAPI(Aws::SDKOptions const&) () from /usr/local/lib/libaws-cpp-sdk-core.so #3 0x00007fff849c6edd in UAWSClient::UploadFileToS3 (FileName=..., FileAbsolutePath=...) at /home/ray/YSProjects/TestBed/Source/TestBed/Private/AWSClient.cpp:25 #4 0x00007fff849ca169 in UAWSClient::execUploadFileToS3 ( this=<optimized out>, Stack=..., Z_Param__Result=<optimized out>) at ../../../YSProjects/TestBed/Source/TestBed/Public/AWSClient.h:19 #5 0x00007ffff66ecf22 in UFunction::Invoke (this=<optimized out>, Obj=<optimized out>, Stack=..., Z_Param__Result=<optimized out>) at /home/ray/UnrealEngine/Engine/Source/Runtime/CoreUObject/Private/UObject/Class.cpp:4474 #6 0x00007ffff6842237 in UObject::CallFunction (this=0x7fff89218fc0, Stack=..., Z_Param__Result=0x7fffffffa830, Function=<optimized out>) at /home/ray/UnrealEngine/Engine/Source/Runtime/CoreUObject/Private/UObject/ScriptCore.cpp:700 #7 0x00007ffff684b3f5 in FFrame::Step (this=0x7fffffffa950, Z_Param__Result=0x7fffffffa830, Context=<optimized out>) at /home/ray/UnrealEngine/Engine/Source/Runtime/CoreUObject/Private/UObject/---Typ------Type <return> to continu-----Type <r---Type <return> to continue, or q <return> to quit--- — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or mute the thread.

[JonathanHenson]

as for your segfault, is anywhere else in your application using libcurl or openssl?

…

Sent from my iPhone

On Jan 29, 2017, at 11:03 AM, Ray Chen ***@***.***> wrote: I have a similar situation but only happen in a specific context. I'm trying to hook up S3 uploading feature in Unreal Engine 4 but segmentation fault always comes to me when executing Aws::InitAPI call. What confuses me is that the exact same code works on Unreal Engine 4 for Mac and Linux (using aws-doc-sdk-examples) except for Unreal Engine 4 for Linux. Also, when I compiled for -DNO_ENCRYPTION=ON, the unit test for sdk fails at AWSAuthV4SignerTest. Is there something you can point me that I should look into? Thanks in advance. @JonathanHenson My configurations: Ubuntu 16.04 LTS libssl-dev: 1.0.2g-1ubuntu4.5 Unreal Engine 4.14 gdb output with backtrace Thread 1 "UE4Editor" received signal SIGSEGV, Segmentation fault. 0x00000000029ccea0 in ?? () (gdb) (gdb) bt #0 0x00000000029ccea0 in ?? () #1 0x00007fff8468e39d in std::function<std::shared_ptr<Aws::Utils::Crypto::SymmetricCipherFactory> ()>::operator()() const () from /usr/local/lib/libaws-cpp-sdk-core.so #2 0x00007fff8468de04 in Aws::InitAPI(Aws::SDKOptions const&) () from /usr/local/lib/libaws-cpp-sdk-core.so #3 0x00007fff849c6edd in UAWSClient::UploadFileToS3 (FileName=..., FileAbsolutePath=...) at /home/ray/YSProjects/TestBed/Source/TestBed/Private/AWSClient.cpp:25 #4 0x00007fff849ca169 in UAWSClient::execUploadFileToS3 ( this=<optimized out>, Stack=..., Z_Param__Result=<optimized out>) at ../../../YSProjects/TestBed/Source/TestBed/Public/AWSClient.h:19 #5 0x00007ffff66ecf22 in UFunction::Invoke (this=<optimized out>, Obj=<optimized out>, Stack=..., Z_Param__Result=<optimized out>) at /home/ray/UnrealEngine/Engine/Source/Runtime/CoreUObject/Private/UObject/Class.cpp:4474 #6 0x00007ffff6842237 in UObject::CallFunction (this=0x7fff89218fc0, Stack=..., Z_Param__Result=0x7fffffffa830, Function=<optimized out>) at /home/ray/UnrealEngine/Engine/Source/Runtime/CoreUObject/Private/UObject/ScriptCore.cpp:700 #7 0x00007ffff684b3f5 in FFrame::Step (this=0x7fffffffa950, Z_Param__Result=0x7fffffffa830, Context=<optimized out>) at /home/ray/UnrealEngine/Engine/Source/Runtime/CoreUObject/Private/UObject/---Typ------Type <return> to continu-----Type <r---Type <return> to continue, or q <return> to quit--- — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or mute the thread.

[pchen66]

Not that I'm aware of. The AWS part is the only place from my application that uses libcurl and openssl.

[JonathanHenson]

looks like you are segfaulting in initialization because you have not built the crypto layer. Is this running on a build that has NO_ENCRYPTION turned on? If so, that's your problem.

…

Sent from my iPhone

On Jan 29, 2017, at 11:36 AM, Ray Chen ***@***.***> wrote: Not that I'm aware of. The AWS part is the only place that needs libcurl and openssl. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or mute the thread.

[pchen66]

Sorry I should have clarify that. The segfault wasn't resulting from enabling NO_ENCRYPTION. I was using cmake -DBUILD_ONLY="s3" <path-to-sdk-source> across platforms, which works for all the other except Unreal Linux. NO_ENCRYPTION is what I experiment to see if that's related.

[JonathanHenson]

any chance you can upload some valgrind output?

…

Sent from my iPhone

On Jan 29, 2017, at 12:40 PM, Ray Chen ***@***.***> wrote: Sorry I should have clarify that. The segfault wasn't resulting from enabling NO_ENCRYPTION. I was using cmake -DBUILD_ONLY="s3" <path-to-sdk-source> across platforms, which works for all the other except Unreal Linux. NO_ENCRYPTION is what I experiment to see if that's related. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or mute the thread.