Crash while using HttpClient in CentOS

[MyCADDev]

Hi,
I get a crash in CentOS but same application code works perfectly in Windows 7.

I compiled the aws-cpp-sdk-core and aws-cpp-sdk-s3 in CentOS 6.5 GCC 4.9.2 and cmake 3.8.1

cmake -DCMAKE_BUILD_TYPE=Debug /AWSLIB/aws-sdk-cpp -DBUILD_ONLY="s3" -DCUSTOM_MEMORY_MANAGEMENT=1 -DTARGET_ARCH=LINUX

I read the README several times and made sure that the calling code has the AWS_CUSTOM_MEMORY_MANAGEMEN=1 during compile.

I made sure I call Aws::Utils::Memory::InitializeAWSMemorySystem at the start of the program

In the below code I get a NULL HttpResponse

	ClientConfiguration clientConfiguration;
	std::shared_ptr<HttpClient> MyHttpClient = CreateHttpClient(clientConfiguration);
	std::shared_ptr<HttpRequest> req(
		CreateHttpRequest(uri,
			HttpMethod::HTTP_GET,
			Utils::Stream::DefaultResponseStreamFactoryMethod));
	std::shared_ptr<HttpResponse> res = MyHttpClient->MakeRequest(*req);
	if (res == NULL)
	{
		std::cout << "Get:Response is NULL" << std::endl;
		return hr;
	}

And the program crashes when I return after doing cout.

The call stack is below.

Could you please help me find what is going wrong.

#0 0x00000037a9632925 in raise () from /lib64/libc.so.6
#1 0x00000037a9634105 in abort () from /lib64/libc.so.6
#2 0x00000037a9670837 in __libc_message () from /lib64/libc.so.6
#3 0x00000037a9676166 in malloc_printerr () from /lib64/libc.so.6
#4 0x00007fffba9265c2 in XXXDDMemoryAllocator::FreeMemory (this=0xdad390, memoryPtr=0x7fffba7110e0)
at /home/xxx/xxxyyyyyyyy/XXXLLLLLLLLLLLL/XXXOOOOOOO/src/XXXDDMemoryAllocator.cpp:43
#5 0x00007fffba4231cb in Aws::Free (memoryPtr=0x7fffba7110e0) at /zzzzzzzz/aws-sdk-cpp/aws-cpp-sdk-core/source/utils/memory/AWSMemory.cpp:102
#6 0x00007fffba71b1b0 in Aws::Allocator::deallocate (this=0x7fff9fffe207, p=0x7fffba7110e0 "", n=25)
at /home/xxx/xxxyyyyyyyy/./XXXLLLLLLLLLLLL/MMMMMMMM/aws/core/utils/memory/stl/AWSAllocator.h:74
#7 0x00007fffba71ad21 in std::basic_string<char, std::char_traits, Aws::Allocator >::_Rep::_M_destroy (this=0x7fffba7110e0, __a=...)
at /opt/rh/devtoolset-3/root/usr/include/c++/4.9.2/bits/basic_string.tcc:449
#8 0x00007fffba71a69c in std::basic_string<char, std::char_traits, Aws::Allocator >::_Rep::_M_dispose (this=0x7fffba7110e0, __a=...)
at /opt/rh/devtoolset-3/root/usr/include/c++/4.9.2/bits/basic_string.h:249
#9 0x00007fffba719f53 in std::basic_string<char, std::char_traits, Aws::Allocator >::~basic_string (this=0x7fff9fffe368, __in_chrg=)
at /opt/rh/devtoolset-3/root/usr/include/c++/4.9.2/bits/basic_string.h:547
#10 0x00007fffba719b9e in Aws::Client::ClientConfiguration::~ClientConfiguration (this=0x7fff9fffe2e0, __in_chrg=)
at /home/xxx/xxxyyyyyyyy/./XXXLLLLLLLLLLLL/MMMMMMMM/aws/core/client/ClientConfiguration.h:48

[singku]

Looks like you are generating your own httpClient. What memory management library are you using? what is the hr here？

[MyCADDev]

hr is just an enum OK / FAILED. We are not having our own HttpClient. We are using the base implementation in aws-sdk-cpp-core.

Is this an acceptable way to use? The same code works in Windows.

[MyCADDev]

We are not using any special memory management library. we just do malloc and free in the class XXXDDMemoryAllocator

[JonathanHenson]

"I made sure I call Aws::Utils::Memory::InitializeAWSMemorySystem at the start of the program"

Makes me think you are having problems because you aren't using:

Aws::SDKOptions options;
Aws::InitAPI(options);
{
//do your stuff using the lib here
}
Aws::ShutdownAPI(options);

On windows, you can get away with not doing it since there is no global state that needs to be setup. +1 for the Win32 API. However, on linux this sets up libcurl and libssl. So nothing will work if you don't do that.

[JonathanHenson]

For more info see this blog post:

https://aws.amazon.com/blogs/developer/aws-sdk-for-c-simplified-configuration-and-initialization/

[MyCADDev]

Thanks for the tips.
I am initializing the SDKOptions but I did set the memory manager in the SDKOptions.

I'm on vacation this week. I will have feedback next Monday.

[MyCADDev]

Oops typo - please read above comment as "I did NOT set the memory manager in SDKOptions".

[PoundKey]

Please let me know if you can use the CurlHttpClient making request to HTTPS required server.

[MyCADDev]

I added this code in the Memory Allocator. And I'm hitting the "Illegal pointer in FreeMemory". So clearly there is some issue.

I'll investigate further where the call is coming from

class XXXXXMemoryAllocator: public Aws::Utils::Memory::MemorySystemInterface
{
	std::set<void*> mMemorySet;
public:
	void* AllocateMemory(std::size_t blockSize, std::size_t alignment, const char* allocationTag = nullptr) override;
	void FreeMemory(void* memoryPtr) override;
};

void* XXXXXMemoryAllocator::AllocateMemory(std::size_t blockSize, std::size_t alignment, const char* allocationTag) {
	void* ptr = malloc(blockSize);
	// std::cout << "Alloc - " << ptr << std::endl;
	mMemorySet.insert(ptr);
	return ptr;
}

void XXXXXMemoryAllocator::FreeMemory(void* memoryPtr) {
	// std::cout << "Free - " << memoryPtr << std::endl;
	std::set<void*>::iterator it = mMemorySet.find(memoryPtr);
	if (it != mMemorySet.end()) {
		free(memoryPtr);
	}
	else {
		std::cout << "Illegal pointer in FreeMemory" << std::endl;
	}
}

[MyCADDev]

An update: We could avoid the corruption by not using custom memory management in CentOS.

[crusader-mike]

I was intellectually bored and checked few issues looking for low hanging fruits. This one could be closed -- his FreeMemory call never removes pointer from mMemorySet, thus triggering alert when malloc implementation reuses memory block.

[MyCADDev]

The problem is not that a dead pointer is in mMemorySet bu that a pointer which was not inserted in mMemorySet is coming for deletion in FreeMemory function.

In the scenario you describe the reused Block would have added the same previously dead Pointer into mMemorySet in the AllocateMemory function.

[crusader-mike]

Yes, you are right. I didn't pay enough attention. But I got a thumbs up! :-)

[marcomagdy]

@MyCADDev do you still need help with this issue? if not, can you close it?

@crusader-mike thanks for helping clean up our issue list.