VS2012: std::locale constructor throws bad locale runtime_error exception using debug runtime - by Fozzy29

Status : 

  Fixed<br /><br />
		This item has been fixed in the current or upcoming version of this product.<br /><br />
		A more detailed explanation for the resolution of this particular item may have been provided in the comments section.

Sign in
to vote
ID 766648 Comments
Status Closed Workarounds
Type Bug Repros 1
Opened 10/8/2012 3:53:22 PM
Access Restriction Public


A simple testcase that instantiates a std::locale with the locale name obtained from a setlocale() call throws a bad locale runtime_error exception when compiled/linked with the /MDd runtime flag or /MTd runtime flag.

Note, this does not appear to occur with /MD or /MT
Sign in to post a comment.
Posted by Deon [MSFT] on 4/29/2014 at 12:31 PM
Thank you for reporting this issue. This issue has been fixed in Visual Studio 2013. You can install a trial version of Visual Studio 2013 with the fix from: http://go.microsoft.com/?linkid=9832436
Posted by Stephan [MSFT] on 2/11/2013 at 5:06 PM
Hi again,

Thanks for reporting this bug. We've fixed it, and the fix will be available in VC12. (Our version numbers are: VC8 = VS 2005, VC9 = VS 2008, VC10 = VS 2010, VC11 = VS 2012.)

The problem here was triggered by your code calling setlocale(), then passing that const char * to std::locale's constructor. Internally, our implementation of std::locale's constructor calls setlocale(), invalidating your const char *. This is apparently extremely sensitive to how aggressively the Windows heap implementation scribbles over freed memory, explaining the Win8 x64 dependency although nothing here is OS or architecture dependent. (In fact, just attaching the debugger was enough to make the issue vanish; I had to enable _NO_DEBUG_HEAP in order to be able to debug the issue.) According to the Standard, we are not supposed to observably call setlocale() here, so your code is correct.

You can work around this bug by storing setlocale's return value in a std::string, which cannot be invalidated by further calls to setlocale(). I fixed this in the library's implementation by doing essentially the same thing - we now have a helper function that takes const string&, and everything goes through that. We're still calling setlocale(), but that should be unobservable now.

As a reminder, Connect doesn't notify me about comments. If you have any further questions, please E-mail me.

Stephan T. Lavavej
Senior Developer - Visual C++ Libraries
Posted by Stephan [MSFT] on 12/14/2012 at 10:47 AM
I've reactivated this bug - it repros with VC11 RTM x64 (but not x86) on Win8.

Posted by Fozzy29 on 12/14/2012 at 9:16 AM
Did you build/run the test case on Windows 8?

That was the only platform I observed this issue on. I could not re-produce it using VS2012 on Windows 7.

Thank you for looking into this.
Posted by Stephan [MSFT] on 12/13/2012 at 6:55 PM

Thanks for reporting this issue. I've resolved it as Not Reproducible because I observe that this works correctly with VC11 RTM:

C:\Temp>type meow.cpp
#include <locale>
#include <iostream>

int main() {
    const char* localeName = setlocale (LC_ALL, 0);
    try {
        std::cout << "using locale name " << localeName << std::endl;
        const std::locale loc (localeName);
        loc.name(); // avoid unused locale
    } catch (const std::runtime_error& e) {
        std::cout << e.what() << " " << localeName << std::endl;

C:\Temp>cl /EHsc /nologo /W4 /MDd meow.cpp

using locale name C

Microsoft (R) C/C++ Optimizing Compiler Version 17.00.50727.1 for x86
Copyright (C) Microsoft Corporation. All rights reserved.

usage: cl [ option... ] filename... [ /link linkoption... ]

Note: Connect doesn't notify me about comments. If you have any further questions, please E-mail me.

Stephan T. Lavavej
Senior Developer - Visual C++ Libraries
Posted by Microsoft on 10/8/2012 at 11:10 PM
Thanks for your feedback.

We are rerouting this issue to the appropriate group within the Visual Studio Product Team for triage and resolution. These specialized experts will follow-up with your issue.
Posted by Microsoft on 10/8/2012 at 4:51 PM
Thank you for your feedback, we are currently reviewing the issue you have submitted. If this issue is urgent, please contact support directly(http://support.microsoft.com)