call client.request(methods::GET) in vs2012 exception

Jun 14, 2013 at 9:34 AM
the following code copy from msdn, run it in release is ok, but in debug mode throw an exception(0x50954F98 (msvcr110d.dll) ), in vs2012, please help me.thank you
__
// Creates an HTTP request and prints the length of the response stream.
pplx::task<void> HTTPStreamingAsync()
{
http_client client(L"http://www.fourthcoffee.com");

// Make the request and asynchronously process the response. 
return client.request(methods::GET).then([](http_response response)
{
    // Print the status code.
   /* std::wostringstream ss;
    ss << L"Server returned returned status code " << response.status_code() << L'.' << std::endl;
    std::wcout << ss.str();*/

    //// TODO: Perform actions here reading from the response stream.
    //auto bodyStream = response.body();

    //// In this example, we print the length of the response to the console.
    //ss.str(std::wstring());
    //ss << L"Content length is " << response.headers().content_length() << L" bytes." << std::endl;
    //std::wcout << ss.str();
});
}


int _tmain(int argc, _TCHAR* argv[])
{
HTTPStreamingAsync().wait();
return 0;
}
Coordinator
Jun 14, 2013 at 7:44 PM
We fixed a similar issue in our development branch and I suspect that you are also running into the same issue.

To confirm, can you please paste the Call Stack when you hit the exception?

Thanks,
Kavya.
Jun 15, 2013 at 2:52 AM
abort position:
_ASSERTE(_BLOCK_TYPE_IS_VALID(pHead->nBlockUse));

stack:
msvcr110d.dll!operator delete(void * pUserData) line 52 C++
httprest.exe!std::allocator<wchar_t>::deallocate(wchar_t * _Ptr, unsigned int __formal) line 586    C++
httprest.exe!std::_Wrap_alloc<std::allocator<wchar_t> >::deallocate(wchar_t * _Ptr, unsigned int _Count) line 888   C++
httprest.exe!std::basic_string<wchar_t,std::char_traits<wchar_t>,std::allocator<wchar_t> >::_Tidy(bool _Built, unsigned int _Newsize) line 2265 C++
httprest.exe!std::basic_string<wchar_t,std::char_traits<wchar_t>,std::allocator<wchar_t> >::~basic_string<wchar_t,std::char_traits<wchar_t>,std::allocator<wchar_t> >() line 965    C++
httprest.exe!web::http::details::_uri_components::~_uri_components()    C++
httprest.exe!web::http::uri::~uri() C++
httprest.exe!HTTPStreamingAsync() line 33   C++
httprest.exe!wmain(int argc, wchar_t * * argv) line 40  C++
httprest.exe!__tmainCRTStartup() line 533   C

Coordinator
Jun 17, 2013 at 7:44 PM
From the stack, it looks like the issue that we fixed might be a different one.
However, I am not able to repro this assert, even with the binaries on codeplex.
Since the code in the continuation is commented out, this is effectively same as sending a HTTP GET request and doing nothing with the response. We have been testing this for a while now and never ran into this assert.

I will need some more information to narrow down the root cause:
  1. Does this repro consistently with debug builds, with the same stack every time?
  2. Can you try this with some other URL and let me know if you hit this assert with other URL's too?
  3. One of the samples, BingRequest demonstrates how to make a HTTP GET request and download the response body into a file. Please do try that out and let us know if it fails too, with the URL "http://www.fourthcoffee.com".
Jun 18, 2013 at 5:32 AM
kavyako wrote:
From the stack, it looks like the issue that we fixed might be a different one.
However, I am not able to repro this assert, even with the binaries on codeplex.
Since the code in the continuation is commented out, this is effectively same as sending a HTTP GET request and doing nothing with the response. We have been testing this for a while now and never ran into this assert.

I will need some more information to narrow down the root cause:
  1. Does this repro consistently with debug builds, with the same stack every time?
  2. Can you try this with some other URL and let me know if you hit this assert with other URL's too?
  3. One of the samples, BingRequest demonstrates how to make a HTTP GET request and download the response body into a file. Please do try that out and let us know if it fails too, with the URL "http://www.fourthcoffee.com".

every time execution the following code throw an exception in debug mode.

http_client client(L"http://www.microsoft.com");

Unhandled exception at : 0xC0000005 , Access violation reading location 0xCCCCCCC0.

thanks
Jun 20, 2013 at 8:12 PM
Edited Jun 20, 2013 at 8:13 PM
If you see weird issues that happens where code has no bug check your runtime linking setting. I filed a bug on this. You need to use dynamically linked library which is by default. Also check if MFC DLL is also dynamic not statically linked.

Some people say it can work, I am not sure how to work around it when we encounter them other than changing the linking option.

Also in rare cases make sure release/debug binaries are not mixed, I doubt that's your issue.
Jun 20, 2013 at 8:53 PM
If you haven't figured this out you need to use try...catch for almost everything related to this library. Anywhere you can .get() or .wait() or anywhere you use http_client/request/uri (winhttp error throws, bad URI throws, etc; if you don't catch it crashes your app) they all can throw on error. This is another aspect of this design that I find intrusive because it just force you to use try/catch almost everywhere and if you don't know what exception handler it is you could be left with no error code (usually you can figure out based on source code but that makes coding more inconvenient). In your case it doesn't look that's the problem but just let you know.
Jun 21, 2013 at 4:15 AM
c2c wrote:
If you see weird issues that happens where code has no bug check your runtime linking setting. I filed a bug on this. You need to use dynamically linked library which is by default. Also check if MFC DLL is also dynamic not statically linked.

Some people say it can work, I am not sure how to work around it when we encounter them other than changing the linking option.

Also in rare cases make sure release/debug binaries are not mixed, I doubt that's your issue.
thank you for you help , i figure out the problem it is release/debug binaries being mixed. because i don't want to copy casablanca.dll to everywhere , so i set all the difference casablanca.dll directory to the path environment variable. but the exe program only used the first been found dll . so lead to this problem.

thank eveybody.