[jira] [Updated] (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 updated STDCXX-1056: --- Attachment: punct.cpp.diff punct.cpp patch for STDCXX-1056 based on stdcxx 4.2.1. > 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
[jira] [Updated] (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 updated STDCXX-1056: --- Attachment: facet.cpp.diff facet.cpp patch for STDCXX-1056 based on 4.2.1. > 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, 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] [Updated] (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 updated STDCXX-1056: --- Attachment: locale_body.cpp.diff locale_body.cpp patch for STDCXX-1056 based on stdcxx 4.2.1. > 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, 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] [Updated] (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 updated STDCXX-1056: -- Attachment: stdcxx-4.3.x-numpunct-perfect-forwarding.patch stdcxx-4.2.x-numpunct-perfect-forwarding.patch > 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] [Updated] (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 updated STDCXX-1056: -- Attachment: STDCXX-1056-additional-timings.tgz > 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 > > > 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] [Updated] (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 updated STDCXX-1056: -- Attachment: stdcxx-1056-timings.tgz > 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] [Updated] (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 updated STDCXX-1056: --- Attachment: runtests-linux64-all.out # COMPILER: gcc 4.5.0, __VERSION__ = "4.5.0 20100604 [gcc-4_5-branch revision 160292]" # ENVIRONMENT: x86_64/LP64 running linux-elf (openSUSE 11.3 (x86_64)) with glibc 2.11 # COMPILED: Feb 7 2012, 21:25:22 > 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 > > > 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] [Updated] (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 updated STDCXX-1056: --- Attachment: runtests-linux32-all.out Full build of test harness on OpenSuSE 11.3 with GCC 4.3.0 (32-bit). The first runtest.out is missing two test programs (which didn't compile), now fixed. > 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.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] [Updated] (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 updated STDCXX-1056: --- Attachment: runtests.out Output capture from running all the tests in build/tests (32-bit). Environment: - Linux darthvader 2.6.34.10-0.4-desktop #1 SMP PREEMPT 2011-10-19 22:16:41 +0200 x86_64 x86_64 x86_64 GNU/Linux - g++ (SUSE Linux) 4.5.0 20100604 [gcc-4_5-branch revision 160292] > 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] [Updated] (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
]
Martin Sebor updated STDCXX-1056:
-
Attachment: 22.locale.numpunct.mt.out
Debugger output of a 15d build of {{22.locale.numpunct.mt}} crashed on 32-bit
Ubuntu 11.10 with {{SIGABRT}}.
> 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 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] [Updated] (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 updated STDCXX-1056: --- Attachment: stdcxx-1056.patch > 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: 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] [Updated] (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 updated STDCXX-1056: --- Patch Info: Patch Available > 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: 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
