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 http://danmey.org
