std::wstring_convert memory leak

Question

I have a true memory leak originating in the following function.

// Convert a UTF-8-encoded byte string to a wstring.
std::wstring Utf8ToWideString(const std::string& utf8str) {
  std::wstring_convert<std::codecvt_utf8<wchar_t>, wchar_t> conv;
  return conv.from_bytes(utf8str);
}

I understand that locale-specific function may allocate some memory once per thread, and keep it for the lifetime of the thread or even the whole process (as apparently happens here). This is not my case; in fact, I have about 2GB of extra memory in the process, and most of these apparently leaked heap blocks come in one of 2 sizes, and contain (each respective to each size) one the day of week names (...:Mon:Monday:Thu:...), and another some time formats. These are leaked apparently per call. The allocations, according to WPA (a tool tracking allocations, the Windows-land cousin of valgrind), occur from inside a call to CRT function std::setlocale. Also, there is not a big churn of threads, and absolute majority if not all of the conversion calls come from the same pool of threads.

My main question is: Am I using std::wstring_convert correctly?

A secondary question, if there is not an obvious bug or uncommon pattern in my code, is this something of a known issue? My compiler is MSVS 2015, and the issue occurs with both Update 2 and Update 3 versions.

Answer 1

There does not seem to be anything wrong with your usage of std::wstring_convert, according to http://en.cppreference.com/w/cpp/locale/wstring_convert. Certainly, these facilities are supposed to handle their memory appropriately, without needing the user to know anything about it.

Whether this is a bug in the standard library implementation of Visual Studio, I don't know. However, one possible scenario I can envision is that they are caching the conversions as some form of optimization. To see if this is the case, you should try converting the same strings repeatedly and see if the allocations are performed only for the first conversion.

On a final note, as long as you are not running out of memory or using excessive amounts of memory, I would not worry about it. Though you might want to do a "conversion stress test", i.e. perform many allocations, to see if the memory usage does or does not significantly increase.