[STDCXX-1056] std::moneypunct and std::numpunct implementations are not thread-safe

• Type: Bug
• Status: Closed
• Priority: Major
• Resolution: Duplicate
• Affects Version/s: 4.2.1, 4.2.x, 4.3.x, 5.0.0
• Fix Version/s: 4.2.x, 4.3.x, 5.0.0
• Component/s: 22. Localization
• Labels: thread-safety

Environment

Solaris 10 and 11, RedHat and OpenSuSE Linux, Sun C++ Compilers 12.1, 12.2, 12.3
Issue is independent of platform and/or compiler.

• Patch Info: Patch Available
• Regression: Unit Test Broken
• Severity: Incorrect Behavior
• Assignee: Liviu Nicoara
• Reporter: Stefan Teleman
• Created: 05/Feb/12 00:25
• Updated: 28/Sep/12 22:16
• Resolved: 28/Sep/12 22:16

Description

several member functions in std::moneypunct<> and std::numpunct<> return
a std::string by value (as required by the Standard). The implication of return-by-value
being that the caller "owns" the returned object.

In the stdcxx implementation, the std::basic_string copy constructor uses a shared
underlying buffer implementation. This shared buffer creates the first problem for
these classes: although the std::string object returned by value appears to be owned
by the caller, it is, in fact, not.

In a mult-threaded environment, this underlying shared buffer can be subsequently modified by a different thread than the one who made the initial call. Furthermore, two or more different threads can access the same shared buffer at the same time, and modify it, resulting in undefined run-time behavior.

The cure for this defect has two parts:

1. the member functions in question must truly return a copy by avoiding a call to the copy constructor, and using a constructor which creates a deep copy of the std::string.

2. access to these member functions must be serialized, in order to guarantee atomicity
of the creation of the std::string being returned by value.

Patch for 4.2.1 to follow.

Issue Links

• is related to: STDCXX-1071 numpunct facet cache initialization is not thread -safe