[jira] [Commented] (STDCXX-1056) std::moneypunct and std::numpunct implementations are not thread-safe

[Stefan Teleman (JIRA)]

[ 
https://issues.apache.org/jira/browse/STDCXX-1056?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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 
> cop

[jira] [Commented] (STDCXX-1056) std::moneypunct and std::numpunct implementations are not thread-safe

[Liviu Nicoara (JIRA)]

[ 
https://issues.apache.org/jira/browse/STDCXX-1056?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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

[Liviu Nicoara (JIRA)]

[ 
https://issues.apache.org/jira/browse/STDCXX-1056?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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

[Liviu Nicoara (JIRA)]

[ 
https://issues.apache.org/jira/browse/STDCXX-1056?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13456626#comment-13456626
 ] 

Liviu Nicoara commented on STDCXX-1056:
---

Have attached a new archive, STDCXX-1056-additional-timings.tgz, which contains 
a new set of measurements. They continue to idicate that a non-caching 
implementation of the numpunct facet may outperform the current implementation 
(in addition to correcting the thread safety issues of the current code). 
Please see the results.txt file for a thorough explanation of the method and 
its results.

> 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] [Commented] (STDCXX-1056) std::moneypunct and std::numpunct implementations are not thread-safe

[Liviu Nicoara (JIRA)]

[ 
https://issues.apache.org/jira/browse/STDCXX-1056?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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

[Stefan Teleman (Commented) (JIRA)]

[ 
https://issues.apache.org/jira/browse/STDCXX-1056?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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

[Stefan Teleman (Commented) (JIRA)]

[ 
https://issues.apache.org/jira/browse/STDCXX-1056?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13202730#comment-13202730
 ] 

Stefan Teleman commented on STDCXX-1056:


I had to resurrect all my linux patches, and because I hadn't worked on the 
Linux stdcxx for a while I had forgotten a bunch of things:

1. makefile.in:
{noformat}
TOPDIR = /src/steleman/programming/stdcxx-gcc/stdcxx-4.2.1-thread-safe
BUILDDIR   = /src/steleman/programming/stdcxx-gcc/stdcxx-4.2.1-thread-safe/build
CONFIG = $(TOPDIR)/etc/config/gcc.config
CONFIG_H   = /usr/bin/g++ -m32 -g -O2 -fno-strict-aliasing -frtti 
-fkeep-inline-functions -D_REENTRANT -D_RWSTD_REENTRANT
BUILDTYPE  = 8d
BUILDMODE  = shared,pthreads
CXX= /usr/bin/g++ -m32 -g -O2 -fno-strict-aliasing -frtti 
-fkeep-inline-functions -D_REENTRANT -D_RWSTD_REENTRANT 
-D_RWSTD_NO_EXT_OPERATOR_NEW -D_RWSTD_NO_OPERATOR_NEW_ARRAY 
-D_RWSTD_NO_REPLACEABLE_NEW_DELETE
CXXFLAGS   = -pedantic -nostdinc++
PRELINKFLAGS =
PICFLAGS   = -fPIC
CPPFLAGS   = 
-I/src/steleman/programming/stdcxx-gcc/stdcxx-4.2.1-thread-safe/include/ansi 
-I/src/steleman/programming/stdcxx-gcc/stdcxx-4.2.1-thread-safe/include/tr1 
-I/src/steleman/programming/stdcxx-gcc/stdcxx-4.2.1-thread-safe/include 
-nostdinc++ -pthread
WARNFLAGS  = -W -Wall -Wcast-qual -Winline -Wshadow -Wwrite-strings 
-Wno-long-long -Wcast-align
DEPENDFLAGS = -M
DEPENDFLAGS.cpp =
DEPENDFLAGS.S =
AS_EXT = .S
LD = /usr/bin/g++ -m32 -g -O2 -fno-strict-aliasing -frtti 
-fkeep-inline-functions -D_REENTRANT -D_RWSTD_REENTRANT -nodefaultlibs 
--allow-shlib-undefined
LDFLAGS= -lc -lm -lpthread
LDLIBS = /usr/lib64/gcc/x86_64-suse-linux/4.5/32/libgcc_eh.a 
/usr/lib64/gcc/x86_64-suse-linux/4.5/32/libsupc++.a
LDSOFLAGS  = -shared
MAPFLAGS   =
RPATH  = -Wl,-R
RUNFLAGS   = -t 300
DEPENDDIR  = .depend
PHDIR  =
PHWARNFLAGS =
LIBSUFFIX  = .so
LIBBASE= std$(BUILDTYPE)
LIBVER = 4.2.1
LIBNAME= lib$(LIBBASE)$(LIBSUFFIX)
AR = ar
ARFLAGS= rv
CCVER  = 4.5
SHARED =
CATFILE=
OMIT_EXM_SRCS =
OMIT_TST_SRCS =
BUILDTAG   =
PLATFORM   = linux-2.6.34.10-0.4-desktop-x86_64
DEFAULT_SHROBJ =
WITH_CADVISE =
CADVISEFLAGS =
WITH_PURIFY =
PURIFYFLAGS =
CXX_REPOSITORY =
{noformat}

Make sure libstd8d.so.4.2.1 does *NOT* link with libstdc++.so. It needs to 
statically link with libsupc++.a and libgcc_eh.a.


> 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] [Commented] (STDCXX-1056) std::moneypunct and std::numpunct implementations are not thread-safe

[Stefan Teleman (Commented) (JIRA)]

[ 
https://issues.apache.org/jira/browse/STDCXX-1056?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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::numpunct 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::numpunct
# 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::numpunct
# 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::numpunct and std::numpunct
# 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 

[jira] [Commented] (STDCXX-1056) std::moneypunct and std::numpunct implementations are not thread-safe

[Stefan Teleman (Commented) (JIRA)]

[ 
https://issues.apache.org/jira/browse/STDCXX-1056?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13202721#comment-13202721
 ] 

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:06:19][2241]>> ./22.locale.messages.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.messages.mt.cpp
# COMPILED: Feb  7 2012, 14:31:03
# COMMENT: thread safety


# CLAUSE: lib.locale.messages

# NOTE (S2) (5 lines):
# TEXT: executing "gencat rwstdmessages.cat rwstdmessages.msg"
# CLAUSE: lib.locale.messages
# FILE: process.cpp
# LINE: 276

# INFO (S1) (3 lines):
# TEXT: testing std::messages with 4 threads, 100 iterations each
# CLAUSE: lib.locale.messages

# INFO (S1) (3 lines):
# TEXT: exercising std::messages
# CLAUSE: lib.locale.messages

# INFO (S1) (4 lines):
# TEXT: requesting a thread pool with 4 threads
# CLAUSE: lib.locale.messages
# LINE: 503

# INFO (S1) (4 lines):
# TEXT: creating a thread pool with 4 threads
# CLAUSE: lib.locale.messages
# LINE: 548

# INFO (S1) (3 lines):
# TEXT: exercising std::messages
# CLAUSE: lib.locale.messages

# INFO (S1) (4 lines):
# TEXT: requesting a thread pool with 4 threads
# CLAUSE: lib.locale.messages
# LINE: 503

# INFO (S1) (4 lines):
# TEXT: creating a thread pool with 4 threads
# CLAUSE: lib.locale.messages
# LINE: 548

# INFO (S1) (3 lines):
# TEXT: exercising std::messages and std::messages
# CLAUSE: lib.locale.messages

# INFO (S1) (4 lines):
# TEXT: requesting a thread pool with 4 threads
# CLAUSE: lib.locale.messages
# LINE: 503

# INFO (S1) (4 lines):
# TEXT: creating a thread pool with 4 threads
# CLAUSE: lib.locale.messages
# LINE: 548

# +---+--+--+--+
# | DIAGNOSTIC|  ACTIVE  |   TOTAL  | INACTIVE |
# +---+--+--+--+
# | (S1) INFO |   11 |   11 |   0% |
# | (S2) NOTE |1 |1 |   0% |
# | (S8) ERROR|0 |3 | 100% |
# +---+--+--+--+
[steleman@darthvader][/src/steleman/programming/stdcxx-gcc/stdcxx-4.2.1-thread-safe/build/tests][02/07/2012
 15:06:22][2241]>> uname -a
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
[steleman@darthvader][/src/steleman/programming/stdcxx-gcc/stdcxx-4.2.1-thread-safe/build/tests][02/07/2012
 15:06:25][2242]>> ldd 22.locale.messages.mt
linux-gate.so.1 =>  (0xe000)
libpthread.so.0 => /lib/libpthread.so.0 (0xf7705000)

/src/steleman/programming/stdcxx-gcc/stdcxx-4.2.1-thread-safe/build/lib/libstd8d.so
 (0xf75f8000)
libm.so.6 => /lib/libm.so.6 (0xf75ce000)
libstdc++.so.6 => /usr/lib/libstdc++.so.6 (0xf74dd000)
libc.so.6 => /lib/libc.so.6 (0xf7373000)
libgcc_s.so.1 => /lib/libgcc_s.so.1 (0xf7355000)
/lib/ld-linux.so.2 (0xf7775000)
[steleman@darthvader][/src/steleman/programming/stdcxx-gcc/stdcxx-4.2.1-thread-safe/build/tests][02/07/2012
 15:07:40][2243]>> ldd ../lib/libstd
libstd8d.so@   libstd8d.so.4.2.1* 
[steleman@darthvader][/src/steleman/programming/stdcxx-gcc/stdcxx-4.2.1-thread-safe/build/tests][02/07/2012
 15:07:40][2243]>> ldd ../lib/libstd8d.so.4.2.1 
linux-gate.so.1 =>  (0xe000)
libc.so.6 => /lib/libc.so.6 (0xf756)
libm.so.6 => /lib/libm.so.6 (0xf7536000)
libpthread.so.0 => /lib/libpthread.so.0 (0xf751b000)
/lib/ld-linux.so.2 (0xf77d9000)
[steleman@darthvader][/src/steleman/programming/stdcxx-gcc/stdcxx-4.2.1-thread-safe/build/tests][02/07/2012
 15:08:06][2244]>>
{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 imp

[jira] [Commented] (STDCXX-1056) std::moneypunct and std::numpunct implementations are not thread-safe

[Stefan Teleman (Commented) (JIRA)]

[ 
https://issues.apache.org/jira/browse/STDCXX-1056?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13201653#comment-13201653
 ] 

Stefan Teleman commented on STDCXX-1056:


I understand the need for writing small and efficient methods, but I don't 
agree that the problem reported in STDCXX-839 relates to the test running for 
too long. The fact that the test program doesn't terminate or abends with 
SIGHUP is a symptom of undefined run-time behavior.

{noformat}
[steleman@darthvader][/src/steleman/programming/stdcxx-ss122/stdcxx-4.2.1/build/tests][02/06/2012
 16:49:50][1512]>> /usr/bin/time -p ./22.locale.numpunct.mt --nthreads=4 
--nloops=100 >& t.out
[steleman@darthvader][/src/steleman/programming/stdcxx-ss122/stdcxx-4.2.1/build/tests][02/06/2012
 16:50:13][1513]>> tail -17 t.out

# 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% |
# +---+--+--+--+
real 4.95
user 1.07
sys 0.22
{noformat}

This test case (and the corresponding 22.locale.moneypunct.mt) consistently 
exhibit run-time crashes or insane behavior (CPU being pinned at 99% forever) 
without the serialization fix.

The interesting part is where this race condition actually happens: it's in 
include/loc/_num_put.cc:

{code title=_num_put.cc|borderStyle=solid}

template  */>
_TYPENAME num_put<_CharT, _OutputIter>::iter_type
num_put<_CharT, _OutputIter>::
_C_put (iter_type __it, ios_base &__flags, char_type __fill, int __type,
const void *__pval) const
{
const numpunct &__np =
_RWSTD_USE_FACET (numpunct, __flags.getloc ());

char __buf [_RWSTD_DBL_MAX_10_EXP];

// will grow as necessary and may need to be deleted
char *__pbuf = __buf;

const string__grouping = __np.grouping (); // <- !!
const char* const   __grp  = __grouping.c_str (); // <- !!
const _RWSTD_STREAMSIZE __prec = __flags.precision ();
// [ ... ]
{code}



> 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] [Commented] (STDCXX-1056) std::moneypunct and std::numpunct implementations are not thread-safe

[Martin Sebor (Commented) (JIRA)]

[ 
https://issues.apache.org/jira/browse/STDCXX-1056?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13201603#comment-13201603
 ] 

Martin Sebor commented on STDCXX-1056:
--

I think the problem in STDCXX-839 is that the tests run too long, not that they 
deadlock or suffer from some other kind of data race.

The {{std::numpunct}} inline members were designed to be as small and as 
efficient as possible to minimize code bloat and maximize iostream performance. 
 Adding locks to them would very likely defeat both of these goals. If we do 
need additional locking it should do in one of the out-of-line implementation 
functions (I think {{\_\_rw::__rw_get_punct()}} is one such function). In any 
case, before we change anything in this area we need a test case to see what's 
broken first, and we should also put together one that verifies that what we 
change doesn't adversely affect performance.

> 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] [Commented] (STDCXX-1056) std::moneypunct and std::numpunct implementations are not thread-safe

[Stefan Teleman (Commented) (JIRA)]

[ 
https://issues.apache.org/jira/browse/STDCXX-1056?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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

[jira] [Commented] (STDCXX-1056) std::moneypunct and std::numpunct implementations are not thread-safe

[Martin Sebor (Commented) (JIRA)]

[ 
https://issues.apache.org/jira/browse/STDCXX-1056?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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