[prev in list] [next in list] [prev in thread] [next in thread] 

List:       apache-stdcxx-issues
Subject:    [jira] [Reopened] (STDCXX-1056) std::moneypunct and std::numpunct implementations are not thread-saf
From:       "Liviu Nicoara (JIRA)" <jira () apache ! org>
Date:       2012-09-28 22:15:08
Message-ID: 1653437830.141196.1348870508698.JavaMail.jiratomcat () arcas
[Download RAW message or body]


     [ https://issues.apache.org/jira/browse/STDCXX-1056?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel \
]

Liviu Nicoara reopened STDCXX-1056:
-----------------------------------

      Assignee: Liviu Nicoara
    Regression: Unit Test Broken  (was: Unit Test Broken,Regression)

The issue is real, although we have differences of opinion on why it happens and how \
it should be solved. One thing we agree on is that we should fix the defects in this \
area.  
> 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
> Assignee: Liviu Nicoara
> 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


[prev in list] [next in list] [prev in thread] [next in thread]