Hi guys,

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:
>>       [ 
>> https://issues.apache.org/jira/browse/STDCXX-1056?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
>>  ]
> Stefan,
> 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.
> Liviu
>> 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

Wojciech Meyer

Reply via email to