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
