BadAlloc when creating http_client passing http_client_config

Sep 17, 2015 at 1:09 AM
Hi!

I am writing code to talk to a web server using http_client. As I use certificate authentication, I need to pass a http_client_config to the http_client constructor.

When I create my http_client without passing the config, it works
m_pHttpClient = new http_client(uri);
However, when I pass a config, even if it is an empty config, the http_client constructor fails. This is the failing code:
http_client_config config;
m_pHttpClient = new http_client(uri, config); 
The problem I'm getting is a bad_alloc. When I pass a config, some internal piece of code is trying to allocate a huge string, as shown in the screen below.

Image

The stack trace looks like this. I'm curious why there is credential in the stack trace, as we are not using credentials.

Image

I am using this version: cpprestsdk.v120.windesktop.msvcstl.dyn.rt-dyn.2.6.0

The reason I need to pass the config is to call set_native_handle to add a certificate to the native handle.

Is this a known issue? Can I workaround it somehow or am I using the library wrong?

Please let me know if there is information I can collect to make the diagnostics easier.

Thanks!
Sep 17, 2015 at 2:01 AM
Extra info: I debugged and observed that when I make the call to construct http_client and pass the http_client_config, the config instance state looks like this

Image

However, after drilling into the rest sdk with the debugger, when the execution reaches http_network_handler::propagate, the http_client_config instance seems to be corrupt in some way, see the image:

Image

Any clues what is going on here and how to fix it?
Sep 17, 2015 at 11:32 AM
I had a similar problem. I couldn't work out why I was getting an access violation when passing config into the http_client constructor especially as the http_client constructor sets up an empty config file anyway. When I checked the raw view in the debugger I found my calling code http_client_config was different to the casablanca version.

The problem was a missing preprocessor directive in my code. I was using the XP version of rest library but forgot to add a CPPREST_TARGET_XP to my preprocessor definitions.

Not sure if this is what's happening with you but this may be of help.
Sep 17, 2015 at 7:00 PM
Thanks DevDave44!

In my case, I'm using the windows desktop version of the rest library, debugging on Windows Server 2012 currently. I did not add any preprocessor directive. It seems like our issues were extremely similar though. Maybe I am missing some preprocessor directive? I didn't see any directive needed in the quick start for my scenario.
Sep 17, 2015 at 7:46 PM
hey carlosscastro

We have not come across this crash before. We do have test cases that exercise the scenario of passing http_client_config to the client.
Do you mind sharing the source code where this crash happens so we can try this at our end?

Thanks
Kavya
Sep 17, 2015 at 7:53 PM
Edited Sep 17, 2015 at 8:17 PM
Additional info: In case it helps, this is a very big project and has a lot of preprocessor definitions. They are listed below, in case you identify some of it that might be interfering with the proper functioning.
NDEBUG;_WIN64;_AMD64_;AMD64;CONDITION_HANDLING=1;NT_UP=1;NT_INST=0;WIN32=100;_NT1X_=100;WINNT=1;_WIN32_WINNT=0x0601;WINVER=0x0601;_WIN32_IE=0x0603;WIN32_LEAN_AND_MEAN=1;DEVL=1;DBG=1;_DLL=1;_MT=1;NOMINMAX;INLINE_HRESULT_FROM_WIN32;_HAS_ITERATOR_DEBUGGING=0;CRYPT_OID_INFO_HAS_EXTRA_FIELDS;UNICODE;_UNICODE;_BIND_TO_CURRENT_ATL_VERSION=1;_BIND_TO_CURRENT_CRT_VERSION=1;_HAS_CPP0X=1;_ITERATOR_DEBUG_LEVEL=0;CRYPT_VERIFY_MESSAGE_PARA_HAS_EXTRA_FIELDS;_WINSOCK_DEPRECATED_NO_WARNINGS;NO_WCHAR_T=1;
Any ideas? Thanks!
Sep 17, 2015 at 8:16 PM
Thanks a lot kavyako!

I can't actually share my code due to business reasons. Maybe I can try to run your tests and then add my preprocessor directives above to see if that brakes them? If that seems to be reasonable, could you send me instructions to run your tests that exercise this path?

Alternatively, you could try the same tests that pass adding the directives above to see if any of my preprocessor directives is changing things.

Thanks a lot for your help! This is a very important project with huge impact and we'd really like to use this library, hope we can get it to work!
Sep 17, 2015 at 8:31 PM
A bit more info. Actually, when I inspect the http_client_config object before constructing the http_client it looks good. Then when I debug it in http_client_impl.h header in the http_client constructor, it is already transformed, i.e. crazy timeout, etc. So that leads me to understand that my code and casablanca's code are interpreting data types differently, which definitely suggests an issue due to extra or missing preprocessor directives.

See the 'before' in my code when I create the http_client_config

Image

But then right in the http_client constructor in http_client_impl.h below. Observe, for example, the different timeout value which is clearly being misinterpreted in the library.

Image

Any clues on why this happens? Thanks a lot!
Sep 17, 2015 at 10:35 PM
Something like mixing of debug/release builds or mixing static and dynamic linking can cause a crash like this.
For instance, I see the same crash if I create a debug X64 project and add the preprocessor flag: _ITERATOR_DEBUG_LEVEL=0; to it.
Could you please check and ensure that such a thing is not happening in your setup.

Also, regarding a testcase that runs successfully, take a look at this sample testcase:
TEST_FIXTURE(uri_address, BaseURI_test)
{
http_client baseclient1(m_uri);
VERIFY_ARE_EQUAL(baseclient1.base_uri(), m_uri);

http_client_config config;
http_client baseclient2(m_uri, config);
VERIFY_ARE_EQUAL(baseclient2.base_uri(), m_uri);
}
Steps to run the testcase is in the "How to setup, build, and run tests on Windows" section.
Sep 23, 2015 at 6:22 PM
Removing the _ITERATOR_DEBUG_LEVEL preprocessor directive fixed the issue. Thanks a lot kavyako!