I think the consensus about this bug is that everybody wants to fix it.
Stefan has a patch but I got completely lost what is the exact reason of
not applying it. It would be a shame to stop at this point.
Liviu Nicoara <nikko...@hates.ms> writes:
> On 9/25/12 7:56 PM, Stefan Teleman (JIRA) wrote:
> I don't think it's ok to close this bug. The race conditions are there
> and we have not come to a completely satisfactory conclusion on how to
> deal with them, or even if we should deal with them. Whichever it is
> we gotta keep this discussion open. I sure hope you want to be a part
> of it.
> FWIW, I have spent quite some time looking at your proposed patch and
> I am going to reopen the incident. If I can.
>> 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,
>>> several member functions in std::moneypunct<> and std::numpunct<> return
>>> a std::string by value (as required by the Standard). The implication of
>>> being that the caller "owns" the returned object.
>>> In the stdcxx implementation, the std::basic_string copy constructor uses a
>>> 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