[jira] [Commented] (STDCXX-1056) std::moneypunct and std::numpunct implementations are not thread-safe
[ https://issues.apache.org/jira/browse/STDCXX-1056?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13461452#comment-13461452 ] Liviu Nicoara commented on STDCXX-1056: --- This summarizes the findings that occurred during the long (!) discussion on the mailing list: 1. Data caching in the facet object, and the access to it, was improperly guarded 2. Concurrent modification of the same string member (via same handle) occurs 3. Stefan identified race conditions in the locale/facet code, beyond caching 4. Stefan provided a clean, race-free patch (although its scope is contested) 5. Alternatively, the simple elimination of locale data caching eliminates test suite failures Besides the obvious defect in caching, DCII occurs in the facet initialization code which would make it thread unsafe although we don't currently have a failing test case. The patch from Stefan eliminates all race conditions and effectively synchronizes all access to facet data. Performance data is not available. It is very possible that this strict synchronization matters very little in the overall picture of the localization library performance. Alternatively, the simplest and least invasive solution at the moment is to just eliminate the caching code. This keeps the fast, unguarded reads of the facet data and relies on the (disputed) thread-safety of the facet initialization code. Timings showed better performance on SMP than the cached facet, and way worse in ST. It also plays in future development with a non-reference counted std::string. The DCII is a serious matter even though there is no failing test case yet. A memory barrier API, recognized by the compiler, would allow us to preserve the fast, unguarded reads of facet data (and even caching). std::moneypunct and std::numpunct implementations are not thread-safe - Key: STDCXX-1056 URL: https://issues.apache.org/jira/browse/STDCXX-1056 Project: C++ Standard Library Issue Type: Bug Components: 22. Localization Affects Versions: 4.2.1, 4.2.x, 4.3.x, 5.0.0 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. Reporter: Stefan Teleman Labels: thread-safety Fix For: 4.2.x, 4.3.x, 5.0.0 Attachments: 22.locale.numpunct.mt.out, runtests-linux32-all.out, runtests-linux64-all.out, runtests.out, STDCXX-1056-additional-timings.tgz, stdcxx-1056.patch, stdcxx-1056-timings.tgz, stdcxx-4.2.x-numpunct-perfect-forwarding.patch, stdcxx-4.3.x-numpunct-perfect-forwarding.patch 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. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (STDCXX-1056) std::moneypunct and std::numpunct implementations are not thread-safe
[ https://issues.apache.org/jira/browse/STDCXX-1056?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13461490#comment-13461490 ] Stefan Teleman commented on STDCXX-1056: The thing I *don't* like about my patch set at all is that it doesn't really and completely eliminate the cache resize problem, which I strongly suspect is the root cause of the race conditions, although I do not have a bull's eye proof for it yet. I have plenty of circumstantial evidence. ;-) Regardless of the initial cache size we start with, it is still possible that the cache will have to be resized. Right now, the fix relies on the fact that it is *unlikely* that a program will ever need more than 32 locales, and the cache never needs to be resized. The reason the perfect forwarding patch appears to solve the problem is: the instantiation of the std::string returned-by-value by the facet member functions is now different: the do_*() functions return a (cast-to) _CharT* pointer. Because of this, the std::string returned by value is now constructed as a deep copy (see the string::string(const _CharT*) 21.3.1/P9 constructor), which effectively gives ownership of this string to the caller - this constructor calls traits_type::copy (_C_data, __s, __n);. For one, the timing difference caused by having to copy the bits (in the constructor) is enough to alter the run-time behavior. Second, by owning a deep copy of the returned string, the caller will still have the bits, although the facet object itself may have long disappeared. Latest files, diffs and test results are available here: http://s247136804.onlinehome.us/stdcxx-1056-20120922/ In this latest version I also fixed a bug I had in my original patchset. The diffs are next-to-impossible to read. It is much easier to just read the complete files. The changes I made are in: locale_body.cpp: __rw_locale* __rw_locale::_C_manage ( ... ); facet.cpp: __rw_facet* __rw_facet::_C_manage ( ... ); punct.cpp: static const void* __rw_get_numpunct ( ... ); static const void* __rw_get_moneypunct ( ... ); In punct.cpp there are two new static inline functions: static inline const void* __rw_numpunct_switch ( ... ); static inline const void* __rw_moneypunct_switch ( ... ); These two functions are used in replacing the recursive calls present in the original implementation of __rw_get_numpunct() and __rw_get_moneypunct(). Their names are horrible. Recursion is extremely expensive on SPARC (and I strongly suspect on other RISC machines as well). I will provide performance data next week. To produce relevant performance data, I need to do optimized builds. Instrumentation requires non-optimized debug builds, and the instrumentation part is what I've been focusing on for the past week. std::moneypunct and std::numpunct implementations are not thread-safe - Key: STDCXX-1056 URL: https://issues.apache.org/jira/browse/STDCXX-1056 Project: C++ Standard Library Issue Type: Bug Components: 22. Localization Affects Versions: 4.2.1, 4.2.x, 4.3.x, 5.0.0 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. Reporter: Stefan Teleman Labels: thread-safety Fix For: 4.2.x, 4.3.x, 5.0.0 Attachments: 22.locale.numpunct.mt.out, facet.cpp.diff, locale_body.cpp.diff, punct.cpp.diff, runtests-linux32-all.out, runtests-linux64-all.out, runtests.out, STDCXX-1056-additional-timings.tgz, stdcxx-1056.patch, stdcxx-1056-timings.tgz, stdcxx-4.2.x-numpunct-perfect-forwarding.patch, stdcxx-4.3.x-numpunct-perfect-forwarding.patch 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
[jira] [Commented] (STDCXX-1056) std::moneypunct and std::numpunct implementations are not thread-safe
[ https://issues.apache.org/jira/browse/STDCXX-1056?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13461253#comment-13461253 ] Liviu Nicoara commented on STDCXX-1056: --- FWIW, I attached two simple patches which eliminate caching of facet data, one binary compatible, for 4.2.x, the other for 4.3.x and later. The current locale MT tests pass with gcc and SUNPro on Linux. std::moneypunct and std::numpunct implementations are not thread-safe - Key: STDCXX-1056 URL: https://issues.apache.org/jira/browse/STDCXX-1056 Project: C++ Standard Library Issue Type: Bug Components: 22. Localization Affects Versions: 4.2.1, 4.2.x, 4.3.x, 5.0.0 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. Reporter: Stefan Teleman Labels: thread-safety Fix For: 4.2.x, 4.3.x, 5.0.0 Attachments: 22.locale.numpunct.mt.out, runtests-linux32-all.out, runtests-linux64-all.out, runtests.out, STDCXX-1056-additional-timings.tgz, stdcxx-1056.patch, stdcxx-1056-timings.tgz, stdcxx-4.2.x-numpunct-perfect-forwarding.patch, stdcxx-4.3.x-numpunct-perfect-forwarding.patch 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. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (STDCXX-1056) std::moneypunct and std::numpunct implementations are not thread-safe
[ https://issues.apache.org/jira/browse/STDCXX-1056?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13453628#comment-13453628 ] Liviu Nicoara commented on STDCXX-1056: --- I have attached stdcxx-1056-timings.tgz -- it contains an implementation of numpunct::grouping with a non caching alternative to the current implementation, t.cpp, a multi-threaded test program, s.cpp, a single-threaded test program, and a text file with timing results of test runs. This goes towards the performance of the existing code. It neglects the correctness of the caching algorithm which, we now know, it's broken. The results indicate that, in multi-threaded builds, the caching implementation is less performing than a non-caching implementation. IMO, this occurs because of the atomic ops synchronization that occurs upon the copying of the cached std::string member in the facet. The operation that synchronizes the std::string reference counting triggers a memory update, just like a cache miss, along with the invalidation of the relevant cache lines for all processors, etc. In the single-threaded builds, the caching version fares better, consistently. There is no locking in std::string, no contention, and grouping makes not trips in __rw_get_numpunct. std::moneypunct and std::numpunct implementations are not thread-safe - Key: STDCXX-1056 URL: https://issues.apache.org/jira/browse/STDCXX-1056 Project: C++ Standard Library Issue Type: Bug Components: 22. Localization Affects Versions: 4.2.1, 4.2.x, 4.3.x, 5.0.0 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. Reporter: Stefan Teleman Labels: thread-safety Fix For: 4.2.x, 4.3.x, 5.0.0 Attachments: 22.locale.numpunct.mt.out, runtests-linux32-all.out, runtests-linux64-all.out, runtests.out, stdcxx-1056.patch, stdcxx-1056-timings.tgz 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. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (STDCXX-1056) std::moneypunct and std::numpunct implementations are not thread-safe
[
https://issues.apache.org/jira/browse/STDCXX-1056?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13202723#comment-13202723
]
Stefan Teleman commented on STDCXX-1056:
{noformat}
[steleman@darthvader][/src/steleman/programming/stdcxx-gcc/stdcxx-4.2.1-thread-safe/build/tests][02/07/2012
15:09:44][2249] ./22.locale.numpunct.mt --nthreads=4 --nloops=100
# INFO (S1) (10 lines):
# TEXT:
# COMPILER: gcc 4.5.0, __VERSION__ = 4.5.0 20100604 [gcc-4_5-branch revision
160292]
# ENVIRONMENT: pentium running linux-elf (openSUSE 11.3 (x86_64)) with glibc
2.11
# FILE: 22.locale.numpunct.mt.cpp
# COMPILED: Feb 7 2012, 14:31:03
# COMMENT: thread safety
# CLAUSE: lib.locale.numpunct
# NOTE (S2) (5 lines):
# TEXT: executing locale -a /tmp/tmpfile-i3QHMP
# CLAUSE: lib.locale.numpunct
# FILE: process.cpp
# LINE: 276
# INFO (S1) (3 lines):
# TEXT: testing std::numpunctcharT with 4 threads, 100 iterations each, in 32
locales { C aa_DJ aa_DJ.utf8 aa_ER aa_ER@saaho aa_ER.utf8 aa_ET
aa_ET.utf8 af_ZA af_ZA.utf8 am_ET am_ET.utf8 an_ES an_ES.utf8
ar_AE ar_AE.utf8 ar_BH ar_BH.utf8 ar_DZ ar_DZ.utf8 ar_EG
ar_EG.utf8 ar_IN ar_IN.utf8 ar_IQ ar_IQ.utf8 ar_JO ar_JO.utf8
ar_KW ar_KW.utf8 ar_LB ar_LB.utf8 }
# CLAUSE: lib.locale.numpunct
# INFO (S1) (3 lines):
# TEXT: exercising std::numpunctchar
# CLAUSE: lib.locale.numpunct
# INFO (S1) (4 lines):
# TEXT: requesting a thread pool with 4 threads
# CLAUSE: lib.locale.numpunct
# LINE: 503
# INFO (S1) (4 lines):
# TEXT: creating a thread pool with 4 threads
# CLAUSE: lib.locale.numpunct
# LINE: 548
# INFO (S1) (3 lines):
# TEXT: exercising std::numpunctwchar_t
# CLAUSE: lib.locale.numpunct
# INFO (S1) (4 lines):
# TEXT: requesting a thread pool with 4 threads
# CLAUSE: lib.locale.numpunct
# LINE: 503
# INFO (S1) (4 lines):
# TEXT: creating a thread pool with 4 threads
# CLAUSE: lib.locale.numpunct
# LINE: 548
# INFO (S1) (3 lines):
# TEXT: exercising both std::numpunctchar and std::numpunctwchar_t
# CLAUSE: lib.locale.numpunct
# INFO (S1) (4 lines):
# TEXT: requesting a thread pool with 4 threads
# CLAUSE: lib.locale.numpunct
# LINE: 503
# INFO (S1) (4 lines):
# TEXT: creating a thread pool with 4 threads
# CLAUSE: lib.locale.numpunct
# LINE: 548
# +---+--+--+--+
# | DIAGNOSTIC| ACTIVE | TOTAL | INACTIVE |
# +---+--+--+--+
# | (S1) INFO | 11 | 11 | 0% |
# | (S2) NOTE |1 |1 | 0% |
# | (S8) ERROR|0 |3 | 100% |
# | (S9) FATAL|0 |1 | 100% |
# +---+--+--+--+
[steleman@darthvader][/src/steleman/programming/stdcxx-gcc/stdcxx-4.2.1-thread-safe/build/tests][02/07/2012
15:09:54][2250]
{noformat}
std::moneypunct and std::numpunct implementations are not thread-safe
-
Key: STDCXX-1056
URL: https://issues.apache.org/jira/browse/STDCXX-1056
Project: C++ Standard Library
Issue Type: Bug
Components: 22. Localization
Affects Versions: 4.2.1, 4.2.x, 4.3.x, 5.0.0
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.
Reporter: Stefan Teleman
Labels: thread-safety
Fix For: 4.2.x, 4.3.x, 5.0.0
Attachments: 22.locale.numpunct.mt.out, stdcxx-1056.patch
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.
--
This
[jira] [Commented] (STDCXX-1056) std::moneypunct and std::numpunct implementations are not thread-safe
[ https://issues.apache.org/jira/browse/STDCXX-1056?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13202809#comment-13202809 ] Stefan Teleman commented on STDCXX-1056: Attached output from running all the tests (32-bit) on OpenSuSE Linux 11.3 with GCC 4.5.0. std::moneypunct and std::numpunct implementations are not thread-safe - Key: STDCXX-1056 URL: https://issues.apache.org/jira/browse/STDCXX-1056 Project: C++ Standard Library Issue Type: Bug Components: 22. Localization Affects Versions: 4.2.1, 4.2.x, 4.3.x, 5.0.0 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. Reporter: Stefan Teleman Labels: thread-safety Fix For: 4.2.x, 4.3.x, 5.0.0 Attachments: 22.locale.numpunct.mt.out, runtests.out, stdcxx-1056.patch 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. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (STDCXX-1056) std::moneypunct and std::numpunct implementations are not thread-safe
[ https://issues.apache.org/jira/browse/STDCXX-1056?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13200645#comment-13200645 ] Martin Sebor commented on STDCXX-1056: -- What you describe sounds like a bug in the implementation of std::string (it could also be a bug in the thread safety of the facets) which is supposed to be thread safe. We have pretty thorough tests for the thread safety of the string classes but it's certainly possible that there's a bug. I suspect the thread safety tests for facets are much weaker. FYI: the plan for stdcxx 5.0 has been to change the default configuration of basic_string to not be reference counted for efficiency on SMP systems. We can't make this change in 4.x because of binary compatibility, although I think there's a macro that lets you control it if you don't care about binary compatibility. If there's a bug in the thread safety of the facet classes (which is quite possible, especially with their lazy initialization), we should be able to fix it without breaking compatibility. std::moneypunct and std::numpunct implementations are not thread-safe - Key: STDCXX-1056 URL: https://issues.apache.org/jira/browse/STDCXX-1056 Project: C++ Standard Library Issue Type: Bug Components: 22. Localization Affects Versions: 4.2.1, 4.2.x, 4.3.x, 5.0.0 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. Reporter: Stefan Teleman Labels: thread-safety Fix For: 4.2.x, 4.3.x, 5.0.0 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. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (STDCXX-1056) std::moneypunct and std::numpunct implementations are not thread-safe
[ https://issues.apache.org/jira/browse/STDCXX-1056?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13200663#comment-13200663 ] Stefan Teleman commented on STDCXX-1056: Test cases for this defect are: 22.locale.moneypunct.mt and 22.locale.numpunct.mt. See also STDCXX-839: https://issues.apache.org/jira/browse/STDCXX-839 std::moneypunct and std::numpunct implementations are not thread-safe - Key: STDCXX-1056 URL: https://issues.apache.org/jira/browse/STDCXX-1056 Project: C++ Standard Library Issue Type: Bug Components: 22. Localization Affects Versions: 4.2.1, 4.2.x, 4.3.x, 5.0.0 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. Reporter: Stefan Teleman Labels: thread-safety Fix For: 4.2.x, 4.3.x, 5.0.0 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. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
