Quantcast
Channel: WE MOVED to github.com/microsoft/cpprestsdk. This site is not monitored!
Viewing all 4845 articles
Browse latest View live
↧

Commented Unassigned: defect in lazy initialization of static in windows_category() [391]

June 10, 2015, 9:25 am
$
0
0
The instance object in the code below races on construction during multi-threaded use of the API when generating errors. The generated code on Windows/VS2013 is not thread safe. The actual error is generated in (http_client_winhttp.cpp) build_error_message while trying to access the object via windows_category(). I have not created a minimal reproduction scenario...

Simple fix, call the function somewhere safe (i.e. single threaded) to instantiate the object:
```c++
utility::details::windows_category();
```

```c++
const std::error_category & __cdecl windows_category()
{
static details::windows_category_impl instance;
return instance;
}
```

another:

```c++
const web::json::details::json_error_category_impl& web::json::details::json_error_category()
{
static web::json::details::json_error_category_impl instance;
return instance;
}
```
Comments: Hi bolts, Yes, you are absolutely right. VS 2013 didn't implement [concurrent initialize for local statics](http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2660.htm). It is implemented in VS 2015. I'll put together a fix today. Thanks for this report and investigating. Steve
↧
Search

New Post: IIS support

June 10, 2015, 9:33 am
$
0
0
Correct there isn't any IIS integration. If you are hosting a serious service you probably want to integrate with IIS, Apache, etc... we didn't do any of this work.

Steve
↧
↧

Edited Issue: defect in lazy initialization of static in windows_category() [391]

June 10, 2015, 9:34 am
$
0
0
The instance object in the code below races on construction during multi-threaded use of the API when generating errors. The generated code on Windows/VS2013 is not thread safe. The actual error is generated in (http_client_winhttp.cpp) build_error_message while trying to access the object via windows_category(). I have not created a minimal reproduction scenario...

Simple fix, call the function somewhere safe (i.e. single threaded) to instantiate the object:
```c++
utility::details::windows_category();
```

```c++
const std::error_category & __cdecl windows_category()
{
static details::windows_category_impl instance;
return instance;
}
```

another:

```c++
const web::json::details::json_error_category_impl& web::json::details::json_error_category()
{
static web::json::details::json_error_category_impl instance;
return instance;
}
```
↧

New Post: Assert with request in http_client_impl.h on iOS

June 10, 2015, 10:09 am
$
0
0
I am attempting to use the SDK in iOS 8, and it is failing an assert in http_client_impl.h upon the second attempt to connect.
I create a, http_client as a class member, and use it to issue a single request per class instance. The second time I create an instance of this class and issue a request, the assertion fails. Below is the assertion (line 172, http_client_impl.h):
virtual concurrency::streams::streambuf<uint8_t> _get_readbuffer()
    {
        auto instream = m_request.body();

        _ASSERTE((bool)instream);
        return instream.streambuf();
    }
Here is an example of the code making the request:
using namespace web;
using namespace web::http;
using namespace web::http::client;
using namespace std;


pplx::task<http_response>
Request::connect()
{

    //Should be set to GET, POST, PUT, or DELETE
    if (HTTPMethod.length() == 0)
    {
        HTTPMethod = methods::GET;
    }
    
    http_request req(HTTPMethod);
    
    if (HTTPBody.length() > 0)
    {
        std::string val;
        formatString(val, "%zd",HTTPBody.length());
        req.headers().add(header_names::content_length,val);
    }
    
    map<string,string>::const_iterator it;
    for (it = HTTPHeaders.begin(); it != HTTPHeaders.end(); it++) {
        const std::string header = (*it).first;
        const std::string value = (*it).second;
        req.headers().add(header,value);
    }

    //client is set with the URI
    req.set_request_uri("");
    return client.request(req);
    
}


void
Request::connectSync(Response& response)
{

    logInfo("connectSync: url (%s)", URL.c_str());

    try {
    
        http_response resp;
        
        connect().then([&](pplx::task<http_response> prevTask)
        {
        
            auto res = prevTask.get();
            logInfo("Result (%s) Requested URL (%s)", res.reason_phrase().c_str(), URL.c_str());
            resp = res;

        }).wait();
        
        response.body = resp.extract_string().get().c_str();
        response.httpCode = resp.status_code();

    } catch (http_exception &e) {
    
        logError("Error (%s) Requested URL (%s)", e.what(), URL.c_str());
        throw e;

    }
    
}
I am new to this, but based on the examples and documentation I have read, this should work. Any ideas??
↧

Commented Issue: defect in lazy initialization of static in windows_category() [391]

June 10, 2015, 11:10 am
$
0
0
The instance object in the code below races on construction during multi-threaded use of the API when generating errors. The generated code on Windows/VS2013 is not thread safe. The actual error is generated in (http_client_winhttp.cpp) build_error_message while trying to access the object via windows_category(). I have not created a minimal reproduction scenario...

Simple fix, call the function somewhere safe (i.e. single threaded) to instantiate the object:
```c++
utility::details::windows_category();
```

```c++
const std::error_category & __cdecl windows_category()
{
static details::windows_category_impl instance;
return instance;
}
```

another:

```c++
const web::json::details::json_error_category_impl& web::json::details::json_error_category()
{
static web::json::details::json_error_category_impl instance;
return instance;
}
```
Comments: I found there is a warning in Visual Studio to complain about these which is off by default. Unfortunately turning it on also finds issues in Boost and WebSocket++. https://msdn.microsoft.com/en-us/library/4f5c8560.aspx To make sure to fix all the locations in our library I'll turn it on temporarily while making the fix, but won't be able to permanently leave it on.
↧
↧

New Post: Assert with request in http_client_impl.h on iOS

June 10, 2015, 1:15 pm
$
0
0
This is solved. I found out my issue-- I was setting the Content-Length for a POST but not setting the body for the request. For reference here are the updated lines:
    if (HTTPBody.length() > 0)
    {
        std::string val;
        formatString(val, "%zd",HTTPBody.length());
        req.headers().add(header_names::content_length,val);
        if (contentType.length() > 0)
            req.set_body(HTTPBody,contentType);
        else
            req.set_body(HTTPBody);
    }
↧

Updated Release: C++ REST SDK 2.7.0

June 10, 2015, 4:18 pm
$
0
0
websockets
  • Merged pull request allowing through CMake to use an external version of Websocket++. #294

miscellaneous
  • Merged a couple of pull requests (here, here, and here) fixing several issues with arm64. #312, #291
  • Merged pull request fixing double include issues when building with CMake.
  • Merged pull request fixing cast issue on FreeBSD.

Windows
  • Removed some unnecessary MSCVER macro checks as Visual Studio 2012 is no longer supported.
  • Fixed several incorrect assumptions of thread safe function local static initialization with Visual Studio 2013. #391
↧

Commented Issue: defect in lazy initialization of static in windows_category() [391]

June 10, 2015, 4:18 pm
$
0
0
The instance object in the code below races on construction during multi-threaded use of the API when generating errors. The generated code on Windows/VS2013 is not thread safe. The actual error is generated in (http_client_winhttp.cpp) build_error_message while trying to access the object via windows_category(). I have not created a minimal reproduction scenario...

Simple fix, call the function somewhere safe (i.e. single threaded) to instantiate the object:
```c++
utility::details::windows_category();
```

```c++
const std::error_category & __cdecl windows_category()
{
static details::windows_category_impl instance;
return instance;
}
```

another:

```c++
const web::json::details::json_error_category_impl& web::json::details::json_error_category()
{
static web::json::details::json_error_category_impl instance;
return instance;
}
```
Comments: Ok I've fixed this in the development branch. Thanks again. Steve
↧
Search

Closed Issue: defect in lazy initialization of static in windows_category() [391]

June 10, 2015, 4:21 pm
$
0
0
The instance object in the code below races on construction during multi-threaded use of the API when generating errors. The generated code on Windows/VS2013 is not thread safe. The actual error is generated in (http_client_winhttp.cpp) build_error_message while trying to access the object via windows_category(). I have not created a minimal reproduction scenario...

Simple fix, call the function somewhere safe (i.e. single threaded) to instantiate the object:
```c++
utility::details::windows_category();
```

```c++
const std::error_category & __cdecl windows_category()
{
static details::windows_category_impl instance;
return instance;
}
```

another:

```c++
const web::json::details::json_error_category_impl& web::json::details::json_error_category()
{
static web::json::details::json_error_category_impl instance;
return instance;
}
```
Comments: Will be in 3.7.0.
↧
↧

New Post: Assert with request in http_client_impl.h on iOS

June 10, 2015, 4:32 pm
$
0
0
Hi navysparks,

Glad you figured it out. Yes that assert was checking to see if the stream body was valid.

I can't quite tell exactly what type HTTPBody is, but you shouldn't need to explicitly sent the content length header here with calling set_body(...) it will automatically be take care of. You could collapse all those lines into:
req.set_body(HTTPBody);
Steve
↧

New Post: Many memory leaks with MFC based application

June 10, 2015, 6:16 pm
$
0
0

problem

Please give me hints to fix memory leaks.
Here's step by step procedure to reproduce problem.

Environment

Visual Studio 2013 Update 4

Create new application

  • MFC based application
  • Dialog base
  • Use MFC Shared library
  • Unicode chaset

Add latest "C++ REST SDK" from NuGet console.

Install-Package cpprestsdk.v120.windesktop.msvcstl.dyn.rt-dyn
Added package is "cpprestsdk.v120.windesktop.msvcstl.dyn.rt-dyn.2.6.0"

Add 3 files to project.

  • ClientInfo.h
  • ServerClientPackets.h
  • ServerClientPackets.cpp
These files are in ChatClientServer.zip attached at below page.
http://blogs.msdn.com/b/vcblog/archive/2014/06/25/c-rest-sdk-websocket-client.aspx

Then build and run with DEBUG configration,

Dialog will appear, so close it.

We found so many memory leaks on output pane.
↧

New Post: Many memory leaks with MFC based application

June 10, 2015, 6:31 pm
$
0
0
Detected memory leaks! Dumping objects -> {3808} normal block at 0x005CE710, 48 bytes long. Data: <S e c - W e b S > 53 00 65 00 63 00 2D 00 57 00 65 00 62 00 53 00 {3807} normal block at 0x005CE6C8, 8 bytes long. Data: < e > E0 65 05 10 00 00 00 00 {3806} normal block at 0x005CE678, 16 bytes long. Data: < > 00 00 00 00 07 00 00 00 08 00 00 00 0D 00 00 00 {3805} normal block at 0x005CE630, 8 bytes long. Data: < e > D0 65 05 10 00 00 00 00 {3804} normal block at 0x005CE5A0, 80 bytes long. Data: <ABCDEFGHIJKLMNOP> 41 42 43 44 45 46 47 48 49 4A 4B 4C 4D 4E 4F 50 {3803} normal block at 0x005CE558, 8 bytes long. Data: < e > 98 65 05 10 00 00 00 00 {3802} normal block at 0x005CE510, 8 bytes long. Data: <|e > 7C 65 05 10 00 00 00 00 {3801} normal block at 0x005CE4A0, 48 bytes long. Data: <R e s p o n s e > 52 00 65 00 73 00 70 00 6F 00 6E 00 73 00 65 00 {3800} normal block at 0x005CE458, 8 bytes long. Data: < d > 10 64 05 10 00 00 00 00 {3799} normal block at 0x005CE3E8, 48 bytes long. Data: <W w w - A u t h > 57 00 77 00 77 00 2D 00 41 00 75 00 74 00 68 00
↧

New Post: Many memory leaks with MFC based application

June 11, 2015, 9:37 am
$
0
0
Hi qt6hy,

There are no actual memory leaks going on here, this has to do with how MFC decides to measure and report leaks. When the MFC dll unloads it reports on all the remaining objects that haven't been deallocated yet. The C++ REST SDK dll contains some global objects that get destructed when the dll unloads. Unfortunately if the MFC dll unloads before the C++ REST SDK, or any other dll containing global objects, these will be reported as memory leaks. When in fact they are destructed and freed right after when the C++ REST SDK dll is unloaded.

Long story short the dll unload ordering has an impact on whether or not MFC reports leaks on global objects that are about the be freed. Here is a prior issue/discussion about this problem that you can take a look at for more information.

Steve
↧
↧

Commented Issue: defect in lazy initialization of static in windows_category() [391]

June 11, 2015, 10:52 am
$
0
0
The instance object in the code below races on construction during multi-threaded use of the API when generating errors. The generated code on Windows/VS2013 is not thread safe. The actual error is generated in (http_client_winhttp.cpp) build_error_message while trying to access the object via windows_category(). I have not created a minimal reproduction scenario...

Simple fix, call the function somewhere safe (i.e. single threaded) to instantiate the object:
```c++
utility::details::windows_category();
```

```c++
const std::error_category & __cdecl windows_category()
{
static details::windows_category_impl instance;
return instance;
}
```

another:

```c++
const web::json::details::json_error_category_impl& web::json::details::json_error_category()
{
static web::json::details::json_error_category_impl instance;
return instance;
}
```
Comments: Thanks for the quick turnaround and the link to the compiler warning. I found a few in one of our projects also flipping on /we4640.
↧

New Post: Many memory leaks with MFC based application

June 11, 2015, 5:00 pm
$
0
0
Thank you Steve.
I know the background of the problem.
↧
Search

New Post: Reusing existing io_service for websocket client?

June 12, 2015, 1:43 am
$
0
0
I already have an io_service in my application used to receive data from a different system. Is it possible to reuse this io_service for the Casablanca websocket client so that I get all callbacks in the same thread thus won't need to protect my data from simultaneous access?
↧

Created Unassigned: Round tripping utf conversion fails for some surrogate pairs [392]

June 12, 2015, 5:59 am
$
0
0
Round tripping utf conversions fails for some surrogate pairs (below test). Starting with 0xD840, 0xDC00 which returns 0xD800, 0xDC00 after the converstions back and forth.

```
#include "stdafx.h"
#include "CppUnitTest.h"
#include <cpprest/json.h>

using namespace Microsoft::VisualStudio::CppUnitTestFramework;

namespace UnitTest
{
TEST_CLASS(UtfConversionTest)
{
void IsConvertedCharacterEqualToOriginal(const std::wstring& original)
{
using namespace utility::conversions;
const auto converted = to_utf16string(to_utf8string(original));
Assert::IsTrue(original == converted);
}
public:

TEST_METHOD(UtfConversionExhaustiveTest)
{
// This test is crude -- it covers all potential Unicode code points,
// without regard to semantics, if they are even defined, or anything.
for (wchar_t c = 1; c < 0xd800u; ++c)
{
IsConvertedCharacterEqualToOriginal(std::wstring(1, c));
}
for (wchar_t c = 0xe000u; c < 0xfffeu; ++c)
{
IsConvertedCharacterEqualToOriginal(std::wstring(1, c));
}
// surrogate pairs
for (wchar_t highSurrogate = 0xd800; highSurrogate <= 0xdbff; ++highSurrogate)
{
for (wchar_t lowSurrogate = 0xdc00; lowSurrogate <= 0xdfff; ++lowSurrogate)
{
std::wstring c;
c.push_back(highSurrogate);
c.push_back(lowSurrogate);
IsConvertedCharacterEqualToOriginal(c);
}
}
}
};
}
```
↧
↧

Edited Unassigned: Round tripping utf conversion fails for some surrogate pairs [392]

June 12, 2015, 6:16 am
$
0
0
Round tripping utf conversions fails for some surrogate pairs (below test). Starting with 0xD840, 0xDC00 which returns 0xD800, 0xDC00 after the converstions back and forth. Using version 2.6 on Windows. The test passed through on version 2.3

```
#include "stdafx.h"
#include "CppUnitTest.h"
#include <cpprest/json.h>

using namespace Microsoft::VisualStudio::CppUnitTestFramework;

namespace UnitTest
{
TEST_CLASS(UtfConversionTest)
{
void IsConvertedCharacterEqualToOriginal(const std::wstring& original)
{
using namespace utility::conversions;
const auto converted = to_utf16string(to_utf8string(original));
Assert::IsTrue(original == converted);
}
public:

TEST_METHOD(UtfConversionExhaustiveTest)
{
// This test is crude -- it covers all potential Unicode code points,
// without regard to semantics, if they are even defined, or anything.
for (wchar_t c = 1; c < 0xd800u; ++c)
{
IsConvertedCharacterEqualToOriginal(std::wstring(1, c));
}
for (wchar_t c = 0xe000u; c < 0xfffeu; ++c)
{
IsConvertedCharacterEqualToOriginal(std::wstring(1, c));
}
// surrogate pairs
for (wchar_t highSurrogate = 0xd800; highSurrogate <= 0xdbff; ++highSurrogate)
{
for (wchar_t lowSurrogate = 0xdc00; lowSurrogate <= 0xdfff; ++lowSurrogate)
{
std::wstring c;
c.push_back(highSurrogate);
c.push_back(lowSurrogate);
IsConvertedCharacterEqualToOriginal(c);
}
}
}
};
}
```
↧

New Post: Reusing existing io_service for websocket client?

June 12, 2015, 12:38 pm
$
0
0
Hi DesktopMan,

No there isn't anything exposed in our public API about Boost with the websocket client, so I don't think you will be able to do this. We don't use Boost to power our websocket client on all platforms. For Windows store and phone we use a Windows Runtime API. You could take a look at the code and see if you wanted to try and expose something to make this possible.

All the websocket client code for the Boost based implementation is in ws_client.cpp and ws_client_wspp.cpp.

Steve
↧

New Post: Having boost problems on Linux during build

June 12, 2015, 8:36 pm
$
0
0
I'm using Boost-1.58.0, and g++-4.8.2 (Ubuntu 14.04), and having the same issue.

The solution is to remove "-Werror" (treat warning as error) in Release/src/CMakelist.txt:53 into:
set (CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} ${WARNINGS} -pedantic")

Just posting this to let anyone who stumbles on the same issue knows
↧
Viewing all 4845 articles
Browse latest View live
Search
<script src="https://jsc.adskeeper.com/r/s/rssing.com.1596347.js" async> </script>