[jira] [Closed] (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:all-tabpanel ] Liviu Nicoara closed STDCXX-1056. - Resolution: Duplicate Closing and continuing work on STDCXX-1071. > 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 >Assignee: Liviu Nicoara > 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 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] [Closed] (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:all-tabpanel ] Stefan Teleman closed STDCXX-1056. -- Resolution: Won't Fix Bug will not be fixed. Upstream refuses to acknowledge the existence of the bug in spite of objective evidence to the contrary. > 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 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
